Email deliverability tools: what each kind actually checks

Email deliverability tools get sold as one thing and do six different jobs. A DNS checker, a block-list lookup and a placement test don't measure the same thing, and mixing them up is how people trust a green tick that doesn't mean what they think. Here are the kinds, what each tells you, and where each one is blind.

DNS and authentication checkers

What they check: whether your SPF, DKIM and DMARC records exist, parse, and pass. They read your DNS and flag problems like two SPF records or more than 10 lookups. The mechanics are in SPF, DKIM and DMARC explained.

What they tell you: your records are valid and what the receiver will see.

Blind spots: they check the records, not what a real message did. A DKIM selector can exist and the service can still sign with another domain, which breaks alignment. Always back a DNS check with a real test message and its headers (look for spf=pass, dkim=pass, dmarc=pass).

Block-list checks

What they check: whether your sending IP or domain appears on public block lists.

What they tell you: a listing is an explanation for blocks. Some bounces even say it, such as 550 5.7.1 with a block list named in the text.

Blind spots: providers keep their own internal lists that no public lookup shows. Microsoft's 5.7.1 text, for example, can refer to its own block list. A clean result doesn't mean you're fine, and a listing doesn't always mean it's the cause of your problem. They also say nothing about reputation inside Gmail.

Inbox placement tests

What they check: you send to a set of seed addresses at various providers, and the tool reports whether each message landed in the inbox, promotions or spam.

What they tell you: a rough placement picture, fast, before a campaign. Email spam test covers how to run one well.

Blind spots: seed accounts aren't your recipients. Providers personalize filtering per user, and a seed that has never interacted with you sees a different view than a prospect would. A result is also a snapshot; it says nothing about next week. Use it as one input and compare with your real replies and bounces.

Provider dashboards

These carry the most weight, because they're the receiving provider's own data.

• Google Postmaster Tools shows Gmail's view of a domain you verify: reputation, spam rate, authentication, delivery errors. Google's guidelines point you to it for the spam-rate thresholds (under 0.1%, never 0.3%).

• Microsoft SNDS reports on IP addresses, not domains.

Blind spots: Postmaster Tools needs enough volume to Gmail to show anything, so a small domain sees blank charts, which is not the same as healthy. It covers Gmail only. SNDS is only useful if you control the IPs you send from. And neither covers every provider your list uses. More on reading them in domain reputation.

Warmup tools

What they do: send and answer mail between a pool of inboxes to build a sending history on a new inbox. Email warmup explains what that does and doesn't achieve.

What they tell you: little, on their own. Their value is the history, not a report.

Blind spots: warmup doesn't fix broken authentication, a bad list or copy people report. The pool matters too: it's only as good as the inboxes in it. In SendingOS, warmup runs on a pool of real Google and Microsoft inboxes only, with no SMTP accounts in it.

List verification

What it checks: whether an address looks deliverable before you send: syntax, domain, whether the mailbox appears to exist.

What it tells you: which addresses are likely to hard bounce, which is how you avoid 550 5.1.1 piling up. See hard bounce vs soft bounce.

Blind spots: some servers accept everything and bounce later, so a "valid" result isn't a guarantee. It also can't tell whether the person will want your email. In SendingOS, email verification is free.

Your own bounce data

The cheapest deliverability tool is the one you already run. Bounce codes name the reason, and they come from the receiving server, not a guess. In SendingOS, every bounce is sorted into hard, soft or block, with its reason and SMTP code on the conversation, and the thread is labelled Bounced. Domain health rules can pause a drifting domain's inboxes before the whole campaign suffers. For the code-by-code reading, use the bounce code library.

Email deliverability tools by question

No tool replaces judgment. Pick the one that answers your question, know its blind spot, and cross-check with something else before you change anything. If you're not sure where to start, how to stop emails going to spam walks through it in order.

How to combine them

A sensible order for a new sending domain: check the DNS records, send a real test and read the headers, verify the list, warm up the inbox, run a placement test, then start a small campaign. Once it's live, your day-to-day instruments are your bounce data and Postmaster Tools, with a block-list check when bounces mention one. Don't buy a tool for a question you haven't asked yet.

One more warning: any tool that returns a single "deliverability score" is compressing several of the checks above into one number. Ask what went into it. A score you can't take apart can't tell you what to fix, and a green score doesn't change what a recipient does with your email.