Learn · Reading your report
Blocklists and “not confirmed”
Your report can show an IP flagged as a known abuser or known attacker, with the blocklists that supposedly listed it — each marked not confirmed. That annotation is doing real work: it means we asked the blocklist ourselves and it did not agree. Here's why that happens, and what to do about it.
Where the flag comes from
Every source IP in your report is enriched against a commercial IP-intelligence feed, which aggregates dozens of reputation sources into a single answer. Aggregation is what makes it useful — one lookup instead of forty — and it's also where the accuracy goes. The aggregator holds a copy of each source's data, and copies go stale: a listing that was withdrawn last month can persist in the aggregate for weeks.
So a flag is a claim, not a verdict. The useful question is never “does the feed say this IP is bad?” but “does the list it names still say so?”
So we ask the list directly
Blocklists are queryable over DNS. To ask SpamCop about 209.85.220.41 you reverse the octets and look up a name in their zone:
$ dig +short 41.220.85.209.bl.spamcop.net
(no answer)An answer means listed. NXDOMAIN — no such name — is the list saying, authoritatively, we do not list this address. That's a straight contradiction of the aggregated flag, and when we get it we mark the entry not confirmed rather than quietly hiding it or presenting it as fact.
Sometimes we genuinely can't tell. Some lists refuse queries that arrive via large public resolvers, and answer with a sentinel address instead of a real result. Some named sources aren't mail blocklists at all and have no DNS zone to query. Both cases also read not confirmed, because we would rather say “we couldn't verify this” than guess in either direction. Not confirmed never means proven clean.
Your own DKIM key settles it
There is one piece of evidence stronger than any reputation feed, and you already own it. If mail from that IP arrived carrying a DKIM signature that validates against your domain, the sender holds your private key. That cannot be forged — an attacker who could produce a valid signature for your domain would not need to be on a blocklist to hurt you.
So when a flagged IP is also DKIM-authenticated for your domain, whatever the list is complaining about is not your mail. The most common shape of this is a large mailbox provider's shared outbound relay: thousands of tenants send from the same address, one of them earns a complaint, and the reputation lands on the IP rather than on them.
What to actually do
| What you see | What it means | Action |
|---|---|---|
| Flagged, listing confirmed | The list itself confirms this IP is listed right now | Investigate. If it's your own sending IP, request delisting; if it isn't yours, this is what p=reject is for |
| Flagged, not confirmed, DKIM passes for your domain | Almost certainly shared-IP reputation from another tenant | Nothing. Your mail authenticates |
| Flagged, not confirmed, fails SPF and DKIM | Unverified claim and unauthenticated mail | Treat the authentication failure as the real signal — see identifying source IPs |
| No threats found | We looked the IP up and nothing was raised | Nothing |
Every blocklist name in your report links to that list's own site, so you can check any claim yourself — and if a list is wrong about an IP you control, their site is where you contest it. We won't stop showing you a flag just because we couldn't confirm it; you should know what was said about your senders. But we won't dress an unverified claim up as a finding either.
The general rule: flags are evidence, not verdicts. Authentication is the verdict. Mail that passes DMARC from an IP with a scary reputation is usually fine; mail that fails both SPF and DKIM is a problem whether or not anyone has listed the IP.