Why we hold our own IPv4 ranges: email reputation accrues to whoever owns the address
Warmup, domain age and sending history all accumulate against an IP address, and whoever owns that address owns the result. We hold our own IPv4 space across three isolated ranges, so changing host does not change the addresses.
Warmup, domain age and sending history all accumulate against an IP address. Whoever owns that address owns the result.
That single fact decides more about a sending operation than any tactic, and it is the reason we hold our own address space. This article is where reputation physically lives, what renting actually rents, and the architecture underneath our fleet, lane by lane.
Where reputation actually lives
Receiving providers keep history per IP address and per domain: how much mail arrived from it, how much bounced, how much got marked as spam, how much got read. That history is the reputation. It is not a score you hold; it is a ledger they hold, keyed to identifiers you may or may not own.
Think of an IP address like a street address with a credit history attached. Every parcel sent from it adds to the record. Now ask who owns the street address your mail leaves from. If the answer is your vendor, then the credit history your careful sending builds up is being written to an account you cannot take with you.
What renting actually rents
On a rented sending pool the addresses stay with the vendor. Your domains, your warmup, your months of careful sending all build reputation on their IPs. Warmup runs for weeks per address before it carries real volume. On a rented pool, that time is spent building reputation on the vendor’s addresses, so changing vendor means spending it again from the beginning.
Leaving means starting from zero. The addresses were never yours to take.
What we hold instead
We hold our own IPv4 address space, across three separate ranges. The largest is leased directly and registered to us in WHOIS, with our own route origin authorisation, so it can be announced from whichever provider we choose. Changing host does not change the addresses. The reputation we built stays with us. The host is bare metal, contracted directly, and replaceable.
A route origin authorisation is a signed public statement of which network is allowed to announce a block of addresses to the rest of the internet. With one in place, the addresses behave like property rather than a lease: we can pick the hosting up and move it, and to every receiving mail server in the world, nothing moved at all.
The three ranges share no domain, no address and no SPF entry. A reputation failure inside one of them has no path to reach the other two. Sending is separated the same way: newsletter infrastructure is long lived and builds reputation over years, while cold outbound runs on a shorter cycle, and the groups share nothing except suppression. An opt-out on any rail applies across all of them.
One server instance per lane
The hardware runs an open-source mail server we configure ourselves. That is what lets us choose the source address per message and hold a separate queue per lane. Each lane runs its own server instance with its own IP address, queue, credentials, logs and reverse DNS record. The infrastructure page describes the runtime this sits on.
The practical reason is what happens when something goes wrong.
On a shared instance, pausing the queue stops every domain using it, including the ones with no problem. Separate instances let us stop one lane without touching the others. A hosted relay does not expose those controls, so a sender on one cannot separate lanes this way even if they want to.
The two lookups receivers run on you
Every address resolves to a hostname that resolves back to the same address, and each address presents an SMTP greeting name matching its own record. Receiving servers check this, forward-confirmed reverse DNS, and we verify it daily against the live mail server configuration rather than against DNS alone.
When your mail server says hello to Google, it introduces itself by name. Google then checks that the name matches the address the connection is coming from, in both directions, like a passport check where the photo and the name both have to agree. Machines that fail it look like machines pretending to be someone else.
When an address goes bad
Every sending address is checked daily against nine blocklists, and a lookup that is refused is recorded as unverified rather than counted as clean. When an address develops a reputation problem, we stop sending from it and bring in a held-back reserve. We do not move its traffic onto another range, and we do not rotate to fresh infrastructure.
Rotating away restores volume quickly. It also removes the evidence needed to find the cause, which is why the same problem tends to recur on the replacement. When a rail has a reputation problem, we hold it there and work it out.
Capacity planning follows the same conservatism: each rail holds enough installed headroom that any two of them can cover the whole target between them, we aim for around seventy percent utilization, and when volume needs to grow we add domains rather than running the existing fleet harder. Adding domains takes weeks of warmup. Pushing existing domains harder takes minutes, and it is how a fleet gets into trouble.
Who this applies to
Fleet-scale senders, and builders whose product sends on behalf of customers. If you send a handful of messages a day from one corporate domain, none of this is your problem: your provider’s shared reputation is doing you a favor, and owning address space would be cost without benefit. The decision point is the moment sending becomes infrastructure your revenue depends on.
Still open
The headroom numbers are choices, not measurements. Each rail holds enough installed capacity that any two can cover the whole target, and we aim for around seventy percent utilization, because reputation recovery is slow and adding warmed domains takes weeks. Whether a leaner reserve would hold through a real rail loss is something we have deliberately never tested in production.
Check it for yourself
Address ownership is on the public record, and forward-confirmed reverse DNS takes two lookups. The address below is a documentation range; use one of yours.
# Who the internet says owns the address your mail leaves from
whois -h whois.arin.net 203.0.113.10 | grep -iE 'orgname|netrange'
# NetRange: 203.0.113.0 - 203.0.113.255
# OrgName: the name to check
# Forward-confirmed reverse DNS: both answers must agree
dig -x 203.0.113.10 +short
# mail.yourdomain.com.
dig A mail.yourdomain.com +short
# 203.0.113.10If the WHOIS organisation is your sending vendor, the reputation you are warming belongs to them.
The principle
The infrastructure you can leave is the infrastructure you do not depend on. Own what accumulates. Rent what does not.