Domain name, mail server name or IP address — IPv4 and IPv6. Email addresses and URLs are shortened automatically.

What gets checked

The check runs on two levels, because blacklists operate on two levels:

  • Domain blacklists (15 lists) — judge the domain name itself, regardless of which server sends. They mostly catch domains that appeared as links in spam: Spamhaus DBL, SURBL, URIBL black/grey/red, NordSpam DBL, Rspamd URIBL, SPFBL.net and more.
  • IP blacklists (43 DNSBLs) — judge the IP address. The IPs of the domain's MX hosts are tested: Spamhaus ZEN, Barracuda, SpamCop, UCEProtect, PSBL, Mailspike, SpamRATS, Blocklist.de, Hostkarma, SPFBL.net and more.

Three kinds of input, three paths

  • A domain such as example.com — the domain name is checked against the domain blacklists and the IP addresses of its MX hosts against the DNSBLs.
  • A mail server name such as mail.example.com — if the name has no MX records it is treated as a mail server itself and resolved via its A and AAAA addresses. That is the case when you have the hostname from a Received header or from your own server configuration in front of you.
  • An IP address, IPv4 or IPv6 — checked directly. Domain blacklists are skipped, because there is no name for them to carry. This is the input you want when a rejection such as 554 5.7.1 … blocked already names the IP: notation with a port (203.0.113.10:25) and in square brackets ([2001:db8::1]:25) is understood as well.

IPv6 is checked too — but not by every list

Mail server names are resolved over A and AAAA, and both address families end up in the result. Of the 43 DNSBLs, however, only 22 carry IPv6 data at all; the rest answer "not listed" to every IPv6 address. They are therefore not queried for IPv6 — otherwise the report would show 21 passed checks that never happened. How many lists apply to an address is stated next to each IP.

Why the MX IPs — and what that tells you

Without a real message the sending IP is unknown. So the tool checks the servers that DNS does reveal: the MX hosts. In most smaller setups those are the same machines that also deliver outbound mail — in which case the result is directly meaningful.

If you separate receiving from sending — Google Workspace inbound, a newsletter tool outbound — you only see the receiving side here. The sending IPs live in your SPF record; the full email analysis covers those.

Listed — now what?

Not every entry carries the same weight. Spamhaus ZEN and Spamhaus DBL are consulted by a great many providers and genuinely block; smaller lists such as UCEProtect levels 2 and 3 list entire netblocks along the way and are barely used by serious receivers. A hit there usually means nothing.

Delisting always comes after the cause: an open relay, a compromised mailbox, a form without rate limiting, missing reverse DNS. Delist without closing the source and you are back on the list within days — and repeat entries make the next delisting harder.

What this check cannot see

Blacklists are only one part of deliverability. Whether a message arrives depends just as much on SPF, DKIM, DMARC, your reputation with the individual provider, and the content. And a clean result here is a snapshot — lists update continuously.

For the complete picture including the actual sending IP, send an email to hello@analyzemy.email.

The full analysis

Send any email to hello@analyzemy.email and within seconds you get back a report with over 20 checks — for the actual sending IP, including DKIM, DMARC evaluation, the TLS path, blacklists and header analysis.

Analyze your email now

Last updated: · All checks at a glance