Email Deliverability Tools: What Each One Actually Tells You

Run your domain through three deliverability tools and you will often get three different verdicts. One gives you 10/10, another warns about your SPF record, a third says your domain is fine but your IP is listed somewhere.

They are not contradicting each other. They are measuring different things, and most guides never explain which question each tool is answering — which is why people fix whatever the last tool complained about and wonder why nothing improves.

This is a map of the categories, what each genuinely tells you, and where each stops being useful.

The five categories

Every tool in this space falls into one of five groups. They answer different questions, in a rough order of usefulness for a WordPress site.

1. Inbox placement testers — where does a message land?
2. DNS and authentication checkers — are your records correct?
3. Blacklist checkers — is your sending IP or domain listed?
4. DMARC report aggregators — what is happening to mail claiming to be you?
5. Continuous monitors — has anything broken since you last looked?

1. Inbox placement testers

What they do: you send a message to an address they generate, and they report a score plus a breakdown of what they found — authentication results, content flags, blacklist status.

What they genuinely tell you: a fast, broad first read. If a message scores badly here, something is wrong and the breakdown usually points at it. This is the correct first tool when you have no idea what is wrong.

Where they stop: the score is not a probability of reaching an inbox. It is a checklist result. A perfect score means you have made no detectable mistakes — not that Gmail will deliver to the inbox, because Gmail’s decision also depends on your reputation with that recipient, and no third-party tool can see that.

The specific trap: people fix everything until they score 10/10, then report that mail still goes to spam. Both things are true. The score measured configuration; the spam folder reflects reputation.

Use it for: a first diagnosis, and to confirm a fix landed. Not for judging whether you have a reputation problem.

2. DNS and authentication checkers

What they do: look up your SPF, DKIM and DMARC records and validate them — syntax, lookup counts, policy, and whether a DKIM selector resolves.

What they genuinely tell you: whether your records are published correctly. These are the most precise tools in the category because they check something objectively verifiable.

The best of them count SPF DNS lookups, which is the single most valuable number they can give you. A record that exceeds ten lookups returns PermError, and DMARC treats PermError as an SPF failure — so mail fails authentication while the record looks entirely reasonable. Almost nothing else surfaces this.

Where they stop: they check what is published, not what is happening. A perfect SPF record proves nothing about whether your mail actually passes SPF, because passing depends on which server sent the message. A site can have flawless records and a misconfigured plugin sending from somewhere not covered by them.

Use it for: verifying record syntax, and specifically for checking the lookup count.

3. Blacklist checkers

What they do: query dozens of DNS blocklists for your sending IP and domain.

What they genuinely tell you: whether you appear on a list. Useful when mail is being rejected outright rather than filtered — a rejection message naming a blocklist is unambiguous.

Where they stop, and this matters: most of the lists these tools query are irrelevant to the major providers. A “listed on 2 of 87 lists” result usually means you appear on two obscure lists nobody consults. It looks alarming and often means nothing.

The lists that genuinely affect delivery are a short list — Spamhaus most of all. Being on Spamhaus is a real problem. Being on a list you have never heard of, run by one person, generally is not.

There is also a scoping point people miss. If you send through a provider, the IP being checked is theirs, not yours. You cannot fix their IP reputation, and on a shared pool you are partly subject to other senders’ behaviour. Checking your web server’s IP is meaningless if your web server does not send mail.

Use it for: confirming a suspected block when mail is bouncing. Not as a routine health check.

4. DMARC report aggregators

What they do: you publish a DMARC record with a reporting address, receiving mail servers send you daily XML reports about messages claiming to be from your domain, and the aggregator turns them into something readable.

What they genuinely tell you: this is the only category that reports on real mail to real recipients. Everything else tests a message you sent deliberately. DMARC reports cover everything, including sources you forgot about and sources that are not you.

This is how you discover that a CRM nobody mentioned has been sending as your domain and failing authentication for a year.

Where they stop: reports arrive daily at best, so this is not a debugging tool for a problem happening right now. Aggregate reports also contain no message content — counts and authentication results only.

Use it for: finding unknown senders before you tighten a DMARC policy. Publishing p=reject without first reading reports is how organisations discover their own legitimate mail was failing.

5. Continuous monitors

What they do: re-run checks on a schedule and tell you when something changes.

Why the category exists: every tool above is a point-in-time test, and deliverability configuration decays. Records get edited during unrelated migrations. Providers rotate DKIM keys. A host starts blocking a port. An OAuth token expires. A plugin update changes a From address.

None of these announce themselves. Mail keeps being generated and quietly stops being trusted or stops being sent, and the gap between the break and the discovery is usually a customer complaint.

Where they stop: monitoring tells you something changed. It does not tell you whether your reputation is good, and it cannot see inside a provider’s filtering decision.

Choosing tools for a site you do not own

If you maintain sites for clients, the constraints are different and worth planning around.

You may not have DNS access. This is the normal case, and it shapes everything. You can diagnose fully without it — every check in categories one to three is read-only — but fixes require somebody else. Producing a precise instruction (“add this exact TXT record at this exact hostname, at Cloudflare, not at the registrar”) is the difference between a fix landing this week and a fortnight of round trips.

DMARC reports go to whoever the record names. If you want visibility across a portfolio, that address needs to be one you control, agreed with the client up front. Retrofitting it later means another DNS change and another round trip.

Point-in-time checks do not survive handover. An audit at launch tells you nothing in month eight, and clients do not report deliverability degradation — they report that a customer complained. Monitoring inside the site is what covers the gap, because it is the only thing that persists without anybody remembering to look.

Cost, and what is worth paying for

Most of this can be done free, and it is worth knowing where money actually buys something.

Free and sufficient: reading Authentication-Results, DNS lookups, your provider’s own dashboard, and receiving raw DMARC reports. Between them these answer the large majority of questions.

Worth paying for, sometimes: DMARC report aggregation, once you have enough sending sources that raw XML stops being readable. This is a real convenience rather than a capability — the data is free, the parsing is what you are buying.

Rarely worth paying for on a WordPress site: seed-list inbox placement testing, which sends to a panel of real accounts across providers and reports folder placement. It is genuinely useful for high-volume marketing operations. For a store sending order confirmations, the signal it adds over reading a real header is small relative to the cost.

The honest summary is that the paid tier of this category is built for email marketing teams. A transactional WordPress site gets most of the value from free tools plus something that re-checks on a schedule.

Why the tools disagree

Three common contradictions, each with a boring explanation.

“One tool says SPF passes, another says it fails.” They are testing different things. A checker validating your published record can report valid syntax; a placement tester reports whether the actual sending server was authorised. If your plugin sends through a service not in your record, the record is valid and the mail still fails.

“DKIM passes here and fails there.” Usually multiple selectors. Providers publish their own, and a tool checking a different selector than the one signing your mail reports failure for a perfectly working setup.

“Perfect score, still in spam.” The score measured configuration. Spam placement is reputation and content. Once authentication passes, more configuration work has no effect — which is the most expensive misunderstanding in this topic, because people keep editing DNS.

The free tools that cover most of this

You do not need a subscription to run everything above. The free options cover the majority of real diagnosis.

• Gmail’s Show original. The most useful and least used. It is the only free method that reports what a real receiver concluded, and it costs nothing. Everything else in this list is a prediction; this is a result.
• Command-line DNS lookups. dig TXT yourdomain.com for SPF, dig TXT _dmarc.yourdomain.com for DMARC, and dig TXT selector._domainkey.yourdomain.com for DKIM. These read authoritative DNS directly, which is genuinely useful when a web tool is showing you a cached answer and you are trying to work out whether a change has propagated.
• Your provider’s dashboard. The most under-used diagnostic available. It shows what happened after the provider accepted the message — delivered, bounced, suppressed, deferred. Half the “deliverability problems” people investigate are visible here in one screen.
• DMARC aggregate reports. Free by definition; you only need somewhere to receive them. Even reading the raw XML occasionally beats not having them.

Building a small toolkit

Rather than collecting tools, most sites are well served by picking one from three categories and knowing them properly.

One diagnostic you use on demand. Reading Authentication-Results from a real Gmail delivery. Free, always available, and it reports a result rather than a prediction. If you learn one thing from this article, make it this.

One source of truth about real mail. A DMARC reporting address, with somewhere to read the reports. This is the only thing that tells you about mail you did not send yourself, including anyone spoofing your domain — and it is the prerequisite for ever moving your policy past p=none safely.

One thing that watches while you are not looking. Whatever form this takes, it is the category that determines whether the other two get used. Point-in-time checks depend on somebody remembering, and nobody remembers — deliverability work is invisible when it is going well, which is precisely when configuration drifts.

Everything else in this article is worth knowing about and reaching for when a specific question arises. Blacklist checkers matter when mail is bouncing; placement testers matter when you are diagnosing from scratch. Neither belongs in a routine.

The mistake underneath most tool use

Worth ending on, because it explains why people can spend a week on this and get nowhere.

Every tool here answers a question about configuration. Configuration is a small part of deliverability, and it is the part you can fix in an afternoon. The rest — reputation, engagement, whether recipients want your mail — is not addressable with a tool at all, and no score reflects it.

So the useful sequence is: use tools to get configuration provably correct, verify it against a real delivery, and then stop using tools. If mail is still filtered after authentication passes, further testing produces more numbers and no progress, and the answer lies in sending practices rather than settings.

The people who get stuck are almost always the ones who keep testing.

What none of these tools can see

Worth being explicit, because it sets a realistic ceiling on what testing can achieve.

Your reputation with a specific recipient. Gmail’s decision about your mail to one user depends partly on how that user and users like them have engaged with you. There is no API for that and no tool can report it.

The receiving organisation’s local rules. A corporate mail system may quarantine you because an administrator wrote a rule. Perfect authentication does not override it, and no external tool can detect it. The fix is asking them to allowlist you.

Whether your server can reach your provider. Every external tool tests your domain from the internet. None can test the direction that actually matters — whether your web server can open a connection outbound. Hosts block SMTP ports routinely, and this failure is invisible to every tool in categories one to four.

Whether mail is stuck on your own site. A queue that has stopped draining produces no external symptom whatsoever. Your DNS is perfect, your provider is healthy, and the message is sitting in a database table.

The last two are the gap a plugin can close, because both questions can only be answered from inside the site.

A practical order

For a WordPress site with a delivery problem:

1. Send a real message to Gmail and read the Authentication-Results header. Free, immediate, and it reports what a receiver actually concluded rather than what a tool predicts.
2. If authentication fails, use a DNS checker to find out why — with attention to the SPF lookup count.
3. If authentication passes and mail is still filtered, stop editing DNS. Check your provider’s own logs and suppression list.
4. If mail is being rejected rather than filtered, check blocklists — reading the rejection message first, since it usually names the list.
5. Once fixed, publish a DMARC reporting address and read the reports for a couple of weeks before tightening policy.
6. Put the whole thing on a schedule, because you will not think to re-check it.

Where a plugin fits

Every category above is a standalone service. That is a real gap for a WordPress site, because the tools cannot see two things that matter and your site can.

Which provider you are actually configured to use. A generic checker reports “SPF record found” and cannot say whether it covers your provider, because it does not know who your provider is. NimblyMail’s audit reads the expected SPF include and DKIM selector from your configured mailer, so it reports the specific record you are missing rather than a generic warning.

Whether your site can reach the provider at all. External tools test your DNS from the internet. They cannot test whether your server can open a connection to your mail host — which is a common failure, because hosts block outbound SMTP ports. The connectivity pillar opens a real TCP socket to your configured host and port with a five-second timeout, or an HTTP request for API mailers, and reports which endpoint passed.

It also covers the case none of these tools can see at all: a queue that has stopped draining. Mail sitting on your own server looks, to the person waiting for it, exactly like mail that went to spam.

The six pillars — SPF, DKIM, DMARC, PTR, connectivity and queue health — run weekly and can be re-run on demand, which turns the point-in-time checks above into something that notices when it breaks.

Summary