IP vs Domain Reputation

“My IP is clean” and “my mail is trusted” are two different statements, and conflating them is one of the most expensive mistakes in deliverability. A receiver evaluates two identities on every message: the IP address that opened the SMTP connection, and the domain in your authentication and your From:. They accumulate reputation separately, they move at different speeds, and - critically - they survive different kinds of change. This page draws the line exactly.

For the broader picture of what reputation is, start with the overview. For how domains specifically get listed, see the Spamhaus blocklists, the DNSBL directory, and the URI blocklists pages. For where these identities get judged in a receiver’s filter, see the spam-filtering overview; for the list hygiene that keeps both identities clean, see suppression and consent.

The 60-second version

• IP reputation attaches to the connecting address. It is what blocklists like the Spamhaus SBL, CSS, XBL, and PBL evaluate.
• Domain reputation attaches to your sending/authenticating domain. It is what the Spamhaus DBL and the URI lists evaluate, and what DKIM lets you carry with you.
• Domain reputation increasingly dominates. Spamhaus: “IP reputation is less important than the reputation of domains and content for inbox placement,” a shift driven by IPv6 making IP-only blocking impractical.
• DKIM is the bridge. It binds reputation to your domain so it “carries with them in the future” even across infrastructure changes.
• Change the IP and you reset the IP history - not the domain history. A clean IP does not launder a bad domain, and a domain’s good standing does not fully rescue a bad IP.

Two identities, scored separately

Every inbound message exposes both identities to the receiver at different points in the SMTP conversation:

Stage	Identity exposed	What is checked against it
TCP/SMTP connection	The connecting IP	IP blocklists: Spamhaus SBL, CSS, XBL, PBL (PBL only here)
HELO / MAIL FROM	The envelope domain + HELO name	Domain reputation, DBL on HELO/Mail-From
DKIM signature	The signing domain (d=)	Domain reputation tied to the signature
DATA / content	Domains in the body (links)	URI blocklists (SURBL, URIBL), DBL on body URLs

Two takeaways. First, the PBL is connection-only - Spamhaus mandates it be used “against the connecting IP in the initial SMTP connection,” never on header or body domains. Second, domain checks happen at multiple stages, including deep in the content, which is why a domain you merely link to can sink a message sent from a spotless IP (see the URI blocklist page).

What attaches to the IP

IP reputation is the history of behaviour seen from a specific address. The Spamhaus IP datasets each capture a different failure mode of an IP:

Spamhaus IP list	What the IP did to earn it
SBL	Identified as a spam source, snowshoe operation, or bulletproof host (manual OSINT research)
CSS	Automatically detected as a low-reputation sender / static spam emitter
XBL	Compromised or exploited - malware, proxy abuse, hijacked to send
PBL	End-user IP space that “should never be sending email” directly to MX

The PBL is worth dwelling on because it is not about bad behaviour at all. Spamhaus: “The IPs in this dataset are not necessarily ‘bad’ - simply, they should never be sending email.” It covers “end-user IP address ranges from which email should never be sent directly to the final destination” - over 1.4 billion IPv4 addresses, “almost 40% of the routable IPv4 space.” If you try to deliver mail straight from a residential or dynamic IP, the PBL is what stops you, regardless of your intentions. The fix is architectural: authenticated submission to a proper sending host, not a cleaner residential IP.

What attaches to the domain

Domain reputation is the history of behaviour seen from a domain name, independent of which IP carried the mail. Spamhaus’s DBL is the canonical example: “a list of domain names with poor reputation… Domain reputation is calculated from a wide range of observed domain behaviors.” It deliberately catches actors who rotate through clean IPs: per Spamhaus, IP-only filtering means “you are missing a simple, yet highly effective, step,” and the DBL “catches actors who evade IP-detection by using clean IPs but abusive domains.”

Domain reputation is also more portable and more proactive than IP reputation. Spamhaus notes domains can be flagged early: “suspicious activity can be identified before being seen in the wild, making this a highly proactive dataset.” A freshly registered domain has no history - which, on the URI side, is itself treated as a risk signal (see URI blocklists).

Shared vs dedicated IPs

Whether your reputation pools with other senders or stands alone is the shared-vs-dedicated decision. M3AAWG lays out the trade-off directly.

	Shared IP	Dedicated IP
Whose behaviour counts	Everyone on the IP	Only you
Effect of a small sender’s mistake	Diluted across the pool	Falls entirely on you
Effect of your mistake	Diluted (and you dilute others)	Isolated to you
Volume needed to build reputation	Lower (pool carries it)	Higher (you must sustain it yourself)
Best for	Low/irregular volume, average quality	Volume control critical; quality notably better or worse than average

M3AAWG: in shared environments, “mistakes made by any single sender in the environment can dilute the overall reputational impact” - a double-edged sword, because your good behaviour is diluted too. They recommend a dedicated environment when “quality is unknown/poorer than average” (isolate to prevent contaminating others), when “quality is known to be higher than average” (isolate to prevent being contaminated by others), or “when volume control is critical.” And in any shared pool, M3AAWG advises that “entities should have similar content and metrics, including complaint and bounce rates” - a mismatched neighbour is a liability.

The reason volume consistency matters so much here is reputation itself: “Combining transactional and marketing email or mail from more than one entity can create irregular traffic volumes. Consistency of volume, whether high or low, plays an integral part in the determination of IP reputation and deliverability outcomes.”

DKIM rescues you from the shared-IP problem

Even on a shared IP, DKIM lets receivers tell tenants apart. M3AAWG: DKIM “gives ISPs and recipient domains the opportunity to differentiate the individual entities responsible for the various mail streams originating from the shared environment when making automated deliverability decisions.” This is the mechanism by which domain reputation rides above IP reputation.

Subdomain strategy: separating streams within one domain

Once you accept that the durable identity is the domain, the next question is how to structure it. The standard answer is separate subdomains per mail stream, so one stream’s behaviour does not drag down another’s. Adobe states the rule directly: “Separate your subdomains for Transactional and Marketing message categories… You don’t want these types of messages to be impacted by the reputation of your marketing subdomain.” Marketing generates the complaints and trap risk; transactional carries time-critical receipts and password resets. Running them on, say, news.example.com and mail.example.com lets receivers build a distinct reputation for each, so a rough marketing month does not delay a password reset.

The same logic extends further when reputations genuinely differ: Adobe notes it “may also be advisable to separate different products or marketing streams into different IP pools if your reputation is drastically different.” A subdomain is the lightweight version of that isolation; a separate IP pool is the heavyweight version, and they are often used together.

When delegating to an ESP, the subdomain you choose is itself a trust signal. Spamhaus’s preference order, from best to worst: a delegated subdomain on your own domain (email.customerbrand.com), then a subdomain under the ESP’s domain (customerbrand.espdomain.com), and only as a last resort a brand-new look-alike domain (customerbrand-email.com) - which reads as a throwaway and starts with no reputation.

One honest limit, though: a subdomain separates reputation streams, but it does not insulate you from a blocklisting on the registered (organizational) domain. Domain blocklists like the Spamhaus DBL and the URI lists list at the registered-domain level and match subdomains by wildcard - if example.com is listed, news.example.com is listed too. Subdomains compartmentalise the reputation receivers build; they do not compartmentalise a listing against the parent.

Why domain reputation increasingly dominates

The shift from IP-centric to domain-centric reputation is explicit, not speculative. Spamhaus: “IP reputation is less important than the reputation of domains and content for inbox placement,” and the driver is IPv6 - the address space is so vast that listing individual IPs no longer scales as a defence. When any sender can trivially acquire fresh IPs, the durable identity is the domain.

This is also why DKIM is strategically important beyond authentication. M3AAWG: DKIM “allows the entity to continue benefitting from the positive sending reputation earned in a prior environment and to carry that reputation with them in the future, should they be re-provisioned.” Your domain, signed consistently, is the asset that compounds.

How the two interact: a worked example

The two identities are evaluated at different moments, so they can pass or fail independently. Walk a message through an ESP migration to see it:

A sender moves from ESP A to ESP B. ESP B assigns a new dedicated IP with no history, but the sender keeps the same DKIM signing domain (mail.example.com).

• At connection time, the new IP is judged. It has no reputation, so receivers are cautious - this is why ESP B requires a warmup. If that IP happened to sit in PBL space or were SBL-listed, the message could be refused before the trusted domain is ever examined. The IP gate comes first.
• At DKIM verification, the domain is judged. Because the signing domain is unchanged, the domain reputation carries over - “carries with them… should they be re-provisioned.” If example.com had a clean history, that good standing helps the new IP warm faster. If it had a bad history (complaints, a DBL listing), the new IP does not launder it - the domain is still the wounded identity.
• At content inspection, the linked domains are judged. Even with a clean IP and a trusted signing domain, a listed link or tracking domain in the body can sink the message (see URI blocklists).

The two failure modes this produces are the ones senders walk into repeatedly:

1. “I’ll switch IPs to fix my reputation.” If the damage is domain-side - complaints tied to your domain via DKIM, a DBL or URI listing - a new IP changes nothing, and the IP-hopping itself reads as snowshoe behaviour.
2. “My domain is trusted, so the IP is irrelevant.” The connecting IP is checked first; a PBL- or SBL-listed IP can get you refused before your trusted domain matters.

The takeaway: build and protect the domain as the compounding asset, and keep the IP un-listed and consistent so it never blocks the door before the domain is read.

What survives an IP change (and what doesn’t)

This is the practical payoff of the whole distinction.

Asset	Survives an IP change?	Why
Domain reputation	Yes	It is attached to the domain, carried by DKIM
DKIM-borne sending history	Yes	M3AAWG: reputation “carries with them” across re-provisioning
DBL / URI-list standing	Yes	Those list domains, not IPs
IP reputation (good or bad)	No	It was attached to the old address
A PBL listing on the old IP	N/A to the new IP	But the new IP must itself not be PBL-listed end-user space
A blocklisted domain	No relief	Changing IPs does nothing; the domain is still listed

The two failure modes people walk into:

1. “I’ll switch IPs to escape my reputation problem.” If the problem is domain-side (DBL, URI lists, complaints tied to your domain via DKIM), a new IP changes nothing. Worse, abandoning IPs to dodge reputation is itself a spammer signature - constantly shifting traffic across addresses is exactly the snowshoe pattern blocklists hunt for.
2. “My domain is trusted, so the IP doesn’t matter.” It still matters at connection time. A PBL-listed or SBL-listed connecting IP can get you refused before your trusted domain is ever evaluated.

Common confusion

• “IP and domain reputation are the same thing.” They are two identities, evaluated at different SMTP stages, listed by different blocklists.
• “A dedicated IP is always better.” Only if you can sustain consistent volume on it. Below that, a shared pool’s dilution can actually help - M3AAWG frames it as a deliberate trade-off, not a hierarchy.
• “A new IP wipes the slate.” It wipes the IP slate only. Domain reputation, carried by DKIM, persists - which is usually what you want.
• “PBL means the IP is bad.” No. PBL means the IP is end-user space that should not send direct-to-MX. It is a policy statement, not an abuse finding.
• “Domain reputation made IP reputation irrelevant.” It is less important, not gone. The connecting IP is still checked first.

What this means for you, and what Egressif does

Build the asset that compounds and survives: a consistently authenticated domain reputation, carried by DKIM, that you keep clean. Treat the IP as the thing that must stay un-listed and consistent, not as an escape hatch.

Egressif operates owned IP space, so the IP-side history is ours and is not pooled with strangers whose mistakes would dilute - or sink - our standing the way a shared pool can. We keep DKIM signing consistent so the durable, domain-side reputation accrues to your domain and travels with it. We monitor the IP and domain blocklists - the Spamhaus IP lists against our connecting addresses and the DBL/URI lists against our domains - so a listing on either identity is something we catch and work, not discover from a delivery cliff. We do not chase reputation by hopping IPs; that pattern is precisely what receivers treat as abuse.