Domain reputation vs IP reputation: which one is hurting you

IP reputation is the standing of the machine that connected. Domain reputation is the standing of the identity in your From: address and your DKIM signature. Providers use both, but they have leaned increasingly on domain reputation for a decade, because domains are the identity a sender actually controls and cannot cheaply discard. That asymmetry is the practical point: moving to a new IP does not escape a domain problem, and it is the most commonly attempted non-fix in deliverability.

How they differ in behaviour

Two notes on that table. Validity's Heatwave list, launched 3 September 2026, is a domain list — it targets synthetic reputation warming and launched with over a million domains, with lookup at lookup.validity.tools. And SORBS, still cited in older IP-side checklists, has not existed since June 2024.

Diagnose which one you have

Run these in order; the first mismatch tells you where the problem lives.

1. Send the same message from the same domain through a different IP — another relay, another provider. If placement improves, the IP is implicated. If it does not, the domain is.
2. Send a message from a different, clean domain through the same IP. Good placement here points the finger at your domain, not the infrastructure.
3. Check listings separately. Look up the IP on the IP lists and the domain on the domain lists, and also look up every link domain in your body — a listed tracking or redirect domain fails your message regardless of your own standing.
4. Read the rejection text. Providers often name the object: 550 5.7.1 ... blocked using zen.spamhaus.org with an IP in the message is an IP block; a rejection referencing your domain or a URL in the body is not.
5. Compare mailboxes. If one mailbox on a domain is bad and the rest are fine, it is neither reputation — it is that mailbox, usually compromised or sending to a worse list.

What each one actually responds to

IP reputation moves on connection-level behaviour: volume and its rate of change, how many recipients do not exist, how many connections get deferred and retried, and in a shared pool, what your neighbours do. It recovers relatively quickly when behaviour improves, and it decays when an IP goes quiet.

Domain reputation moves on recipient behaviour: complaints, replies and other positive interaction, spam-trap hits, and whether the mail is authenticated and aligned. It accrues slowly, persists much longer, and is the reason an established domain with a good history can send volume that would get a new domain throttled.

The remediation difference

If the IP is the problem and it is shared, your lever is your provider: open a ticket with evidence that your own mail is clean and ask to be moved. If it is yours, find the sending source that caused it, stop it, and request review through the list's free path. If it is a pool you cannot leave, consider your own IP only if you have the steady volume to keep it warm.

If the domain is the problem, infrastructure changes will not help. Fix list quality, make unsubscribing trivial and immediate, get SPF, DKIM and DMARC aligned, split transactional from marketing from outbound onto separate domains or subdomains, and rebuild by sending only to recipients who engage. Budget weeks.

What not to do

Do not register a new domain to escape a damaged one. You lose every bit of positive history, you inherit the suspicion attached to new domains, and the hop itself is visible. Do not rotate IPs to dodge a listing — rotation through a pool after a block is a recognised abuse pattern and it degrades the whole pool. Do not assume a clean blocklist lookup means good reputation: most reputation damage never produces a listing. Do not spread outbound across dozens of lookalike domains hoping to dilute risk; you end up with many unwarmed domains and no accumulated standing anywhere. And do not try to settle the question with a reputation grade from Google — the Postmaster Tools domain and IP reputation charts are retired, so the available evidence is Gmail spam rate plus per-provider seed placement, which is exactly what the two-sided test above uses.

Where subdomains fit

A sending subdomain like mail.example.com or send.example.com gives you partial separation: it benefits from the parent's standing while keeping its own record, so a problem in one stream is easier to contain. It is not a firewall — severe, sustained abuse on a subdomain can affect how the organisational domain is judged — but as a way to keep receipts arriving while an outreach experiment goes wrong, it earns its keep.

MailPilot measures both sides where it can: real per-provider inbox placement through a seed network, SPF, DKIM and DMARC validation per domain, and per-mailbox reputation recorded daily, so the "is it the domain, the IP, or one mailbox" question has data behind it instead of a guess.