Glossary term
IP reputation: how receivers judge your sending address
What IP reputation is
IP reputation is the trust assessment a mailbox provider maintains for a sending IP address, built from the history of everything that address has ever sent to that provider. Every connection your mail server makes arrives with one piece of unfakeable context — the IP it came from — and receivers have been keeping books on IPs since long before domain authentication existed.
There is no single, global IP reputation. Gmail keeps its own ledger, Microsoft keeps its own, Yahoo keeps its own, and dozens of blocklist operators and filtering vendors keep theirs. The same address can be trusted at one provider and throttled at another, because each judges from its own mail flow and its own users' reactions. When senders talk about "our IP reputation" in the singular, they are averaging over a committee that never meets.
Reputation expresses itself as treatment, not as a number you can read directly: full-speed acceptance for trusted addresses, rate limiting and 4xx deferrals for doubtful ones, spam-foldering or connection refusal for bad ones. A few receivers expose a partial view — Google Postmaster Tools reports IP reputation in broad bands, and Microsoft SNDS shows activity data for IPs you register — but most of the ledger is deliberately opaque.
How IP reputation differs from domain reputation
Modern filtering tracks two identities in parallel: the address the mail came from, and the domains it claims and signs with.
IP reputation attaches to infrastructure. It answers: has this machine historically emitted wanted mail? It is the older signal, harder to fake and faster to read — a receiver knows the IP before the first message byte arrives — but it is also transferable in ways that create noise. IPs are reassigned, pools are shared, and a sender can simply buy new address space.
Domain reputation attaches to the brand doing
the sending, established through authentication (the
SPF domain, the DKIM d= domain,
the visible From under DMARC). It follows the sender across any infrastructure and cannot
be shed by renumbering, which is precisely why receivers have shifted weight
toward it.
They interact. A trusted domain sending from an unknown IP gets more benefit of the doubt than an unknown domain would; a spam-listed IP drags down mail from any domain crossing it. Warm-up exists because a new IP has no history at all — and no history is not neutral, it is suspicious. The practical summary: the domain carries your long-term identity, the IP carries your current infrastructure's hygiene, and you need both in order.
How IP reputation works
Each receiver's model is proprietary, but the published guidance (Google Postmaster guidelines, Microsoft's sender documentation, Yahoo Sender Hub) and observable behavior agree on the inputs that matter:
- Complaint rate. Recipients clicking "report spam" is the loudest signal. Providers state acceptable complaint thresholds in their sender requirements, and sustained excursions above them move an IP's standing quickly.
- Spam-trap hits. Sends to addresses that exist only to catch senders with bad list practices — recycled dead mailboxes, addresses that never opted into anything. Traps are weighted heavily precisely because they cannot produce false positives from a well-run list.
- Invalid-recipient rate. A stream of
550 user unknownresponses tells the receiver you do not clean your list. - Volume patterns. Steady, predictable volume reads as legitimate operations. Sudden spikes from a quiet address read as a compromise or a rented cannon.
- Authentication and infrastructure hygiene. SPF/DKIM alignment on the traffic, forward-confirmed reverse DNS, a sane EHLO — each absence costs a little trust.
- Blocklist presence. Third-party DNS blocklists (Spamhaus being the most consequential operator) are consumed by many receivers as one input among several — influential, but neither necessary nor sufficient for filtering decisions.
Two structural properties follow from the inputs. Reputation is asymmetric: it accrues slowly, over weeks of consistent good sending, and degrades fast — one bad campaign to a stale list can undo a quarter's patience. And it is decaying: an IP that stops sending stops generating evidence, and its standing drifts back toward unknown. Reputation is maintained by sending, not achieved and banked.
You can check the visible slice — presence on the major public blocklists — with a blacklist check, and the infrastructure prerequisites with a reverse DNS check.
IP reputation and your deliverability
How much your IP's standing matters depends on whose IP it is.
On shared pools — the default for most ESP customers — the pool's reputation is a platform-level product. You experience it but only fractionally influence it; the operator's onboarding standards, outbound filtering and eviction speed determine what neighborhood your mail travels through. This is a real, measurable differentiator between platforms, and it is invisible on every pricing page. It is one of the things our seed-list placement testing captures indirectly: identical content, different pools, different outcomes.
On a dedicated IP, the ledger is entirely yours. Every input above is under your control, which is the appeal — and the workload. Warm-up, volume steadiness, list hygiene and complaint management stop being the platform's problem.
Either way, the receiver-side mechanics are the same. Degrading IP reputation usually announces itself first as throttling: rising 4xx deferrals, delivery slowdowns, "try again later" responses. That is the correctable stage. Left unaddressed, it progresses to spam-foldering and then to connection-level blocks. Watching your bounce logs for deferral patterns is the cheapest early-warning system in email.
Registering for the receiver-side dashboards — Google Postmaster Tools and Microsoft SNDS — turns two of the biggest black boxes into partial gauges. They are free, and running high-volume mail without them is flying on dead reckoning.
Limitations and failure modes
The pool-neighbor incident. On a shared IP, a spammer onboarded by your platform can put your sending address on a blocklist overnight. Your mail bounces, your metrics crater, and the remedy is entirely in the platform's hands. How fast an ESP detects, evicts and delists is worth more than any feature it advertises.
Delisting ≠ restoration. Getting removed from a blocklist removes the listing; it does not restore the trust each receiver's internal model subtracted while you were listed. Expect placement to recover on the receivers' timelines, not the blocklist's, and only under continued good behavior. Senders who treat delisting as case-closed are reliably surprised.
The new-IP fallacy. When reputation goes bad, moving to a fresh IP looks like a reset. Receivers know this move — it is standard spammer procedure called snowshoeing — and treat unknown IPs with corresponding suspicion. A new address with the same broken practices reacquires the old reputation, sometimes faster, while domain reputation carries the history across anyway.
Volume whiplash. Quiet address, sudden burst: the pattern of a compromised host. Seasonal senders hit this every year. Ramp up ahead of peaks; keep a baseline pulse in the off-season.
Monitoring the wrong thing. A clean blacklist check is compatible with a mediocre reputation at every major receiver — the public lists see only the worst behavior. Blocklists are a smoke alarm, not a health tracker; the receiver dashboards and your own deferral rates are closer to the truth.
Opacity is policy. No receiver will tell you your score, and the models change without notice. Every reputation strategy is therefore indirect: control the inputs (list quality, complaints, volume shape, authentication) and read the outputs (placement, deferrals, dashboard bands).
Related terms
Domain reputation, sender reputation, dedicated IP, shared IP, spam trap, spam complaint rate, email warm-up, list hygiene, PTR record.
Frequently asked questions
How do I check my IP reputation? There is no single readout. Check the public blocklists with a blacklist check, register the IP with Google Postmaster Tools and Microsoft SNDS for those receivers' views, and watch your own logs for 4xx deferral patterns — the earliest practical signal.
How long does it take to build IP reputation? Weeks of consistent, complaint-free sending at steady volume; longer for higher volumes and stricter receivers. It degrades much faster than it builds, and it decays if the IP goes quiet.
Does changing my IP fix a bad reputation? Rarely. A fresh IP starts unknown, not trusted, and receivers treat sudden volume from unknown addresses with suspicion. Meanwhile domain reputation carries your history across the move. Fix the practices that burned the address first.
What is a good spam complaint rate? Mailbox providers publish thresholds in their sender requirements — Google and Yahoo state them in their bulk-sender documentation. Directionally: complaint rates that would round to zero are the goal, and sustained rates near the published ceilings put placement at risk.
Is IP reputation still relevant now that domain reputation dominates? Yes. Domain reputation carries more long-term weight in modern filtering, but the IP is evaluated at connection time, before any domain evidence is seen, and connection-level blocks and throttles are IP decisions. You need both healthy.
Whose job is IP reputation if I use an ESP on shared IPs? The platform's — which makes pool quality a real selection criterion. Measured placement differences between platforms partly reflect exactly this, which is why we rank on measured deliverability rather than claimed rates.
Set up the two free receiver dashboards this week, and put a monthly blacklist check on the calendar — reputation problems announce themselves quietly before they get loud.
Sources
- Google Postmaster guidelines and Postmaster Tools documentation (IP reputation reporting, sender requirements)
- Microsoft SNDS documentation (Smart Network Data Services)
- Spamhaus policy and listing documentation (DNS blocklist operation)
- Yahoo Sender Hub (sender requirements and complaint thresholds)