Your sending IP's reputation isn't a single published score. It's an inference receivers make from several signals at once: whether you're on any DNSBL, your complaint and bounce rates, whether you've hit spam traps, how consistent your sending volume and pattern are, and (for Gmail and Microsoft specifically) private reputation systems that never surface publicly. Checking it properly means checking all of these, not just running one blacklist lookup.
What actually feeds IP reputation
| Signal | Where it comes from | Why it matters |
|---|---|---|
| DNSBL presence | Public blocklists (Spamhaus, SpamRats, Barracuda, SpamCop, Invaluement) | Directly consulted by many receiving servers at connection time |
| Complaint rate | Feedback loops from Gmail, Yahoo/AOL, Microsoft | Google's own guidance treats a spam-rate above roughly 0.3% as a problem threshold |
| Bounce rate | Your own send logs | High hard-bounce rates signal poor list hygiene to receivers watching the same pattern |
| Spam-trap hits | Inferred from sudden deliverability drops, sometimes flagged in feedback loops | A single pristine spam trap hit can do more damage than a dozen real complaints |
| Volume consistency | Receiver-side throttling and rate-limit responses (4xx deferrals) | Sudden spikes from a previously quiet IP look exactly like a compromised host |
| Provider-specific reputation | Gmail Postmaster Tools, Microsoft SNDS | Not visible on any public DNSBL; this is often the real reason mail is filtered when every blacklist check is clean |
The checklist, in order
- Run a multi-list DNSBL check against your sending IP (Spamhaus ZEN, Barracuda BRBL, SpamCop SCBL, the four SpamRats zones, Invaluement's ivmSIP/ivmSIP24 via their own lookup). This takes minutes and rules the simplest explanation in or out.
- Pull your own bounce and complaint data from the last sending window. A hard-bounce rate climbing past roughly 2% or a complaint rate near Google's 0.3% threshold is actionable before you look anywhere else.
- Check Gmail Postmaster Tools (domain-level reputation there was retired, but IP reputation and spam-rate data remain) and Microsoft SNDS for your IP range. These catch problems no public blacklist will ever show.
- Look at recent 4xx deferrals and 5xx rejections in your own logs for text naming a specific blocklist or rate limit — this is often faster than running checks blind.
- Confirm SPF, DKIM, and DMARC alignment. A reputation problem and an authentication problem produce similar symptoms (mail to spam, mail bounced), and fixing the wrong one wastes the investigation.
Reading a mixed result
It's common to be clean on every public DNSBL and still see poor inbox placement. That almost always means the problem is in complaint rate, engagement, or a provider-specific system rather than a blocklist — chasing blacklist delisting in that situation fixes nothing because nothing was actually listed.
The reverse is also common: a single narrow DNSBL hit (a SpamRats or Invaluement listing, for instance) with otherwise clean sending metrics. These lists are consulted by a meaningful minority of receivers, not the majority, so the practical impact is usually smaller than a Spamhaus ZEN listing but still worth clearing.
What not to do
- Don't treat "zero blacklist hits" as proof you're fine. It rules out one category of problem, not all of them.
- Don't fixate on a low-reach list (a narrow regional or niche DNSBL) while ignoring a rising complaint rate — the complaint rate is what gets you onto the major lists in the first place.
- Don't buy a "reputation score" from a tool that won't say what inputs it uses. Many of these repackage a DNSBL check and a WHOIS lookup as a proprietary number.
- Don't change sending IPs as a first response. A fresh IP with no sending history has no reputation at all, which receivers treat cautiously too — it buys you nothing if the actual cause (content, list hygiene, volume pattern) travels with you to the new IP.
Reading the result together, not list by list
The most common mistake in this checklist is running each step and treating the results as independent. They aren't. A fresh DNSBL listing, a spike in complaints, and a drop in Gmail Postmaster Tools reputation in the same week are usually three views of one event — a bad send, a compromised credential, or a purchased list going out. Line the timestamps up before you start remediating each signal separately; fixing the common cause once is faster than chasing three symptoms independently, and it's easy to "fix" a blacklist listing while leaving the sending behaviour that caused it untouched.
A note on IPv4 versus IPv6 and shared infrastructure
If you send from a shared IP (common with many ESPs and some SMTP relays), your own sending history is only part of the reputation picture — other tenants on the same IP contribute to it too. A shared IP with mixed-quality tenants will show noisier reputation signals than a dedicated IP with a single, consistent sender, which is worth knowing before you spend time investigating a reputation dip that may not have originated with your own sends at all.
How MailPilot helps
MailPilot checks your IPs and domains against the blocklists receivers actually consult, tracks per-mailbox reputation daily, and measures real per-provider inbox placement with a seed-inbox network — so you see the composite picture (blacklist status, placement, and authentication) in one place instead of reconstructing it from five separate tools.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial