Operations Practical
The reputation of an address you did not choose
The address you rent carries a history you did not write, and blocklists judge the range rather than the address. What each of the six judges actually blocks, why mail is the harshest and the only honest one, and the single decision that matters more than every DNS record put together.
15 min read Published 28 August 2026 Checked today
Nobody chooses an IP address. You are handed one, and it arrives with a decade of other people’s behaviour already attached to it. On an offshore range that history is worse than average, for a reason that is structural rather than accidental — and the honest version of that sentence is one no provider puts on a product page. Here is what the address actually decides, who is judging it, and the one decision that outranks every DNS record you could set.
The history you rent along with the address
There have been no new IPv4 addresses since 2011. Every address handed out today has been handed out before, often several times, and the block it sits in has been carrying reputation data since before you had the idea for your service. When a provider assigns you an address, it is not minting one — it is recycling one, and the receipt comes with the previous tenants attached.
The part that surprises people is the granularity. Almost nothing on the internet judges a single address. Blocklists, mail providers and fraud scoring systems work on ranges — a /24, sometimes a whole autonomous system — because that is the unit an operator controls, and because an abuser who burns one address simply moves to the next one in the block. Three consequences follow, and all three are outside your control:
- Your neighbours are your reputation. The other 253 machines in your /24 are making decisions that land on you, and you cannot see who they are, what they run, or how much mail they send. You inherit their average.
- Listings outlive tenants. A range can carry an entry long after the customer who earned it has been terminated, because the list has no way to know a customer changed and no incentive to guess.
- Offshore ranges start lower. A provider that asks for no identity attracts, among honest customers, exactly the customers who get listed — and lists respond to that by widening from a single address to the /24 to the whole network. This is a genuine cost of the jurisdiction decision. It belongs in the decision, not in a surprise after the first invoice.
Two further things move underneath you while the address stays the same. Addresses are now leased and transferred between organisations, so the registry record for a block can change hands without a single packet changing course — and reputation data, which lives with the addresses rather than with the registry, does not follow the paperwork. And geolocation databases lag by months. An address moved to Chișinău can go on resolving to Amsterdam in half the commercial databases for a quarter or more, which shows up as a fraud engine seeing a Dutch address on a Moldovan connection and scoring the mismatch. Neither of these is a defect. Both are the ordinary friction of an address market that ran out of stock fifteen years ago.
Our own acceptable use policy names the mechanism rather than hiding it: unsolicited bulk mail gets the whole range blacklisted within hours, and the range is shared. That is why the rule exists, and why the sanction is the port rather than the account. Mail servers and bulk mail you have consent for are explicitly permitted — the line is consent, not volume.
Six judges, and they do not agree
“Blacklisted” is used as if it were one condition. It is at least six, decided by six parties who use different data, publish different amounts of it, and in two cases will never tell you they made a decision at all.
| Who is judging | How you find out | Can you fix it | What it actually blocks |
|---|---|---|---|
| Mail providers | A bounce, or silence | Partly | Your message, into the spam folder or out of the door entirely. Reputation here is scored per address and per sending domain, and the two are tracked separately. |
| Spamhaus and the major public lists | A bounce naming the list | Yes | The SMTP connection, at the door, before your message is read. This is the one that produces a bounce with a reason in it, which makes it the most useful failure you can have. |
| Lists that charge to be removed | A bounce, rarely | No | In practice, very little. Some list an entire /24 or a whole network on the strength of one sender, then offer an express removal for a fee. Operators of any size do not consult them. |
| CDNs and web firewalls | A challenge page | No | Your visitors, with a challenge page — or your own outbound requests to sites sitting behind one. The decision is made about your network, not about your machine. |
| Fraud and payment scoring | You do not | No | Nothing visibly. It raises a risk score at somebody else’s checkout, silently, as one input among dozens. You will never see the rule and there is no appeal desk. |
| Sites that block data centres wholesale | A refusal in your own logs | No | Requests your server makes outward — scrapers, API calls, health checks. This is not a reputation problem at all. It is a category problem: you are a data centre, and they wanted people. |
Read the third column downward and the shape of the problem appears. One of six is genuinely fixable by you, one is partly, and four are decisions taken elsewhere about a category you belong to. That ratio is the argument for designing around the address rather than fighting it — which is what the last section is about.
Why mail judges hardest, and most honestly
Mail is the only one of the six that will tell you, in writing, at the moment of failure, exactly why it refused you. A challenge page does not explain itself. A fraud score never surfaces. A bounce message contains a code, a list name and often a URL. Mail is the harshest judge on this page and the only honest one, and that combination makes it the right place to spend your configuration effort.
Reverse DNS, and the half of it everyone forgets
A PTR record maps your address back to a name. Setting one is the easy half, and it is the half most people stop at. The requirement is forward-confirmed: the name your PTR returns must itself resolve back to the same address. Google states this as a condition for bulk senders in those words — valid forward and reverse records, with the sending address matching the address of the hostname in the PTR. A PTR pointing at a name that resolves nowhere, or to a different machine, is worse than none, because it looks like a misconfiguration rather than an omission. On our network the reverse record is yours to set, which means it is also yours to get wrong; set it before the first message leaves, not after the first bounce.
SPF, DKIM and DMARC authenticate — they do not vouch
The three records prove that a message really came from who it claims. That is all they prove. They are not a reference, they are an identity document, and an identity document does not make you welcome anywhere. An authenticated message from a listed address is an authenticated message from a listed address — it will be refused with more confidence, not less. Set all three because they are now a floor rather than an advantage, and then understand that you have done nothing yet about reputation.
There is also a split worth understanding before you spend a week on the wrong half. Reputation is tracked against your address and against your sending domain, and the two are scored separately. That has a practical consequence in both directions: a spotless new domain sending from a clean address still has no reputation at all — no reputation is not the same as good reputation, and the first thousand messages are treated accordingly — while a domain with years of well-behaved sending behind it carries that history across a change of address. The domain half is the portable half, which is the real argument for signing with DKIM on your own domain rather than on whatever the sending tool offers you by default.
The numbers Gmail publishes, and what they imply
For senders of roughly five thousand messages a day or more, Google publishes requirements rather than hints: SPF and DKIM on the sending domain, DMARC present — a policy of none is accepted — one-click unsubscribe on marketing and subscription mail, and a spam complaint rate held under 0.30 percent, with 0.10 percent recommended. Those figures are worth converting. At five thousand messages, 0.30 percent is fifteen complaints. Fifteen people clicking a button on a day you sent a list you were not certain about is the difference between delivered and filtered, and it is not a threshold you can feel your way toward.
Outbound port 25 is blocked by default on most large clouds, which is why nobody there discovers any of this. An offshore provider often leaves it open, and that is not a gift: an open port on a shared range means the range’s reputation is being decided by whoever else is using it. Ours is rate-limited and then closed on repeat abuse, for exactly that reason and no other.
Ten minutes of checking, before you pay
Every one of these is answerable before money changes hands, and each answer is more useful than any claim on a product page. A provider’s willingness to answer them is itself the finding.
- Ask which address you will get (2 min). Not the range — the address. A provider that cannot tell you before payment cannot tell you anything about its history either, and that is the answer to the question you were really asking.
- Check the address, then check the /24 around it (3 min). The public reputation checkers accept both. A clean address inside a thoroughly listed block tells you precisely what you need to know about your next two years.
- Look up who announces the range (2 min). The network that announces a block tells you more than the block does. One network with a long history and a published abuse contact behaves differently from one that appeared last quarter.
- Test outbound port 25 before you design around it (1 min). Open a connection to a mail server you control and see what happens. Discovering the answer after migration is how a weekend disappears.
- Confirm the reverse record is yours, and how fast (1 min). Both halves matter: that you can set it at all, and that the change takes minutes rather than a ticket queue you will be waiting in on the day you launch.
- Ask what happens when an address turns out to be unusable (1 min). The answer you want is that they swap it, without an argument and without a fee. Get it in writing, because the day you need it you will not be in a position to negotiate.
What you can fix, and what you route around
Five situations, and the useful distinction between them is not how bad they look. It is whether the lever is in your hands, somebody else’s, or nobody’s.
| Situation | Who decided it | Yours to fix | The move |
|---|---|---|---|
| Listed on a policy list | Your provider | Yes | A policy listing is not an accusation. Most of those ranges are submitted by the network operator itself, saying only that addresses there should not be sending mail directly. Self-service removal exists, conditional on a static address, a real mail server and correct records both ways — and a single-address exclusion expires after a year and reverses the moment spam is seen. |
| Listed for actual spam from your address | The list | Partly | Fix the cause first, because a removal granted and re-earned is worse than the original listing. If the history belongs to a previous tenant rather than to you, the fix is a different address, not an appeal. |
| The whole /24 listed by a pay-to-remove operator | The list, alone | No | Do nothing, and specifically do not pay. Treat the listing as information about the list rather than about you, and check whether any provider you actually care about consults it. Usually none do. |
| Visitors challenged by a CDN in front of somebody else | Somebody else | No | Nothing at your machine changes this, because nothing about it is decided at your machine. It is one more thing settled a layer above you, alongside the registry and the proxy. |
| Mail refused with clean lists and correct records | Nobody, exactly | Partly | This is reputation rather than listing, and reputation is built by sending: low volume first, real recipients, and weeks rather than days. Or you stop trying to build it on this address, which is the next section. |
All five improve enormously once you stop guessing. Three instruments cost nothing and take an afternoon to wire up: a postmaster dashboard at the large providers, which shows your spam rate and your authentication pass rate against their own numbers rather than yours; feedback loops, which tell you who complained so you can stop mailing them before the rate moves; and a habit of reading bounces properly. A 4xx code is a temporary refusal and often a rate limit — slow down. A 5xx is a decision, and the text beside it usually names the list or the policy that made it. Most people delete both without reading either, then describe the result as mysterious.
A setup that survives a bad address
One decision outranks every record in this guide, and it is a decision about architecture rather than configuration: do not send your mail from the machine your application runs on. Send it through a relay whose reputation is somebody’s full-time job, maintained across a pool of addresses that are warmed, monitored and replaced. You are not outsourcing a problem you could have solved; you are declining to rebuild, on one address on a shared range, a thing that takes a dedicated team to keep working.
That leaves the offshore machine doing what the jurisdiction actually bought you — hosting the service, holding the data, staying up when a complaint arrives — and puts deliverability where it is already a product. The two concerns stop being coupled, which means a bad month for the address stops being a bad month for your password resets.
What the address decides: whether mail sent directly from it arrives, whether your outbound requests reach sites that block data centres, and how a fraud engine scores a visitor who shares it with you.
What it does not decide: whether your service is reachable, whether it is fast, or whether a complaint can take it down. Those are the questions a hosting decision is actually for — and they are the ones an address cannot touch either way.
If you are starting today, the order matters more than the list. Set the reverse record and confirm it resolves back to you before anything else, because everything downstream is judged against it. Publish SPF and DKIM, then DMARC at none so you receive reports without breaking delivery while you read them. Send a hundred real messages to real people and read the results. Only then decide whether this address will ever be a sending address, and if the answer is no, decide it now rather than after you have built a queue around the assumption that it would be.
If you must self-host mail, separate the addresses: one for the public web, one that does nothing but send. A /29 makes that trivial and costs less than a month of debugging why a password reset from your marketing IP is being filtered. Ask before you need it, not during.
The wider point is the one this site keeps making in different words. Going offshore buys a specific thing and charges for it in ecosystem friction, and this is what that friction looks like from the inside rather than as a bullet on a comparison page. If your risk profile does not need the jurisdiction, a clean address on an ordinary provider is worth more to you than anything on this page. If it does, buy the jurisdiction and rent the reputation from somebody else — and if you are going to self-host mail seriously, start from a machine that comes with its own block of addresses rather than one address in a crowd.
Written by the engineers who run the platform, and re-read today. If something here is wrong or has gone out of date, say so from the panel — that is where about half of these came from.