Deliverability problems are rarely one thing. A message that lands in spam is the sum of several reputation signals, and any one of them read alone can mislead you. The skill is triangulation, reading three independent signals together until they agree on a story.
The three signals
- IP blacklists (DNSBL) answer: is the server that sent this listed for spam? This is your sending IP's reputation. Check it with the blacklist / DNSBL tool.
- Domain blocklists (URIBL) answer: is a domain inside the message listed? This is about the links, shorteners and tracking domains in the body, not the IP. Check it with the URIBL tool.
- Message headers answer: what did the receiver actually decide, and why? This is the ground truth for one specific message. Read them in the Email Header Analyser.
Why one signal alone lies
- A clean IP feels reassuring, but if a link domain is on a URIBL, mail still gets filtered. IP reputation can't see body content.
- A URIBL hit on a shortener you use might be someone else's abuse of a shared domain, not your fault, but still your problem.
- Headers show the verdict for one message, but not whether the pattern is systemic. That's what the two reputation checks add.
Only together do they resolve into a diagnosis.
Triangulating a real case
Suppose newsletters are going to spam:
- Headers first. The Authentication-Results line shows
spf=pass dkim=pass dmarc=pass, so it's not authentication. Good, that rules out a whole layer. - DNSBL next. The sending IP is clean on the major lists. So it's not raw IP reputation either.
- URIBL last. The click-tracking domain in every link comes back listed. There's the culprit: a shared tracking domain poisoned by another sender.
Three checks, one clear answer, and you'd never have found it by staring at the IP alone.
What to do once they agree
- Listed IP → identify the cause (compromise, bad sending pattern), fix it, then request delisting at the specific DNSBL. Confirm reverse DNS with the reverse DNS tool, a mismatched PTR compounds the problem.
- Listed domain (URIBL) → stop using the poisoned shared domain; move to a branded domain you control, then request delisting.
- Auth failures in headers → fix SPF/DKIM/DMARC alignment before touching reputation; receivers weigh authenticated mail very differently.
FAQ
My IP and domain are both clean but mail still spams. What now?
Read the headers for that message. Clean reputation plus spam-foldering usually means an authentication alignment issue (SPF/DKIM/DMARC) or content/engagement signals the reputation tools can't see.
How can a domain I don't own get me blacklisted?
Shared link shorteners and ESP tracking domains appear in your message body. If another customer abuses that shared domain and it's URIBL-listed, every message referencing it inherits the hit. Use a branded domain you control.
Which signal should I trust most?
For a single failing message, the headers are ground truth. For a systemic pattern, the two reputation checks tell you whether it's IP-side or domain-side. Trust the one that matches the scope of the problem.