The deliverability toolbox

The free deliverability toolbox, job by job: DNS lookups, record checkers, blocklist and header tools, postmaster dashboards, and their blind spots.

Last updated 19 July 2026

A working deliverability toolbox is small and entirely free, and it is organized by job rather than by brand. Eight slots cover the whole diagnostic craft: a raw DNS lookup, a record checker, a full-domain health check, a blocklist checker, a header analyzer, a single-message tester, a DMARC report processor, and the postmaster dashboards. After this lesson you can name which slot answers which question, and which question each one is structurally unable to answer. The tools are the cheap part. The judgment about which one to reach for is what Parts 1 through 5 were building, and it's the part people pay for.

Brands churn; the jobs don't. Tool sites get acquired or quietly abandoned, so this tour names categories. The exceptions, tools I can vouch for directly, are our own pages, the command-line staples, and the receivers' own dashboards.

Reading DNS raw

The humblest slot, and the one professionals reach for most: a plain DNS lookup, dig on the command line (or nslookup), or any online dig-style tool. It answers the foundational question: what does this record resolve to right now, from the outside, the answer a receiver would get rather than the one your DNS panel remembers?

Its blind spot is that it has no opinion. It hands you a broken record and a perfect one with identical indifference; judging legality or ownership is entirely on you.

Record checkers

One rung up: tools that parse a specific record type and judge it. An SPF checker counts the DNS lookups against the limit of ten, flags a +all, follows the include chain. DMARC checkers tell you what the policy actually instructs receivers to do. DKIM checkers fetch a key and report its length, though they need you to supply the selector name, exactly the thing you often don't know.

The blind spot: a checker judges legality, not intent. An SPF record quietly edited to authorize a server you've never heard of parses perfectly. "Valid" and "still the record you approved" are different verdicts, and no validator can issue the second one.

Our health check

The free health check is the record-checker job run across the whole domain at once: SPF existence and syntax, DMARC presence and policy strength, a probe of well-known DKIM selectors, MX records, general DNS sanity, MTA-STS and TLS-RPT, BIMI, and the domain's status on more than two dozen blocklists. It also reads your DNS for the fingerprints of sending tools, which regularly surfaces a forgotten platform still authorized to send as the domain. No signup, no cap a human will hit.

The honest limit, true of every domain-only checker on the internet, ours included: everything above runs from the domain name alone, so it sees configuration only. Whether your messages actually get signed, which IP really carries them, what verdict a receiver issues, whether the compliance headers are present: those facts only exist on a real delivered email. That's why the full audit inside the product has you send a test email from each tool, and why a domain that passes every DNS check can still be sending unsigned mail. A domain-only pass is necessary, never sufficient.

(Our per-ESP checker pages are the same engine pointed at one provider's expectations; same blind spot.)

Blocklist checkers

Question answered: is this domain, or this IP, on a published blocklist right now? Multi-list checkers sweep dozens of lists in one query, the right first move. For anything on a Spamhaus list, confirm with Spamhaus's own lookup, since it is authoritative for its own data and aggregators sometimes serve stale results.

Two blind spots. First, only published lists are queryable; Gmail's internal reputation system is not a blocklist and no checker can see it, a distinction blocklists explained covers. Second, a listing tells you that you're listed, never why; the cause investigation is still yours.

Two tools that need a real message

A header analyzer takes the raw source of a delivered email and unfolds it: the chain of servers, the authentication verdicts, the envelope addresses. It answers the most forensic question in the box: what happened to this specific message? Its limits: scope (one message, one path, one moment) and the lower headers, which arrived with the message and can be forged. How to actually read what it shows you is the next lesson's whole subject.

A single-message tester works the other direction: you send an email to an address it gives you and get back a scored report on authentication, content signals, and the path it observed. Good for catching a regression after a change. Its blind spot is seductive enough to deserve italics: a score is not placement. The tester's mailbox is not Gmail's filter, it knows nothing about your reputation with real receivers, and a 10/10 message from a blocklisted IP still goes to spam.

DMARC report processors

Aggregate DMARC reports are XML, and nobody should read XML. A processor turns the feed into tables: which sources sent as your domain, in what volume, and whether they aligned. This is the only tool in the box that watches the whole internet's use of your domain rather than one message or one record, the skill from reading DMARC reports.

Blind spots: it needs a rua address published in advance (nothing accumulates retroactively), the data lags a day or more, and it carries no content: it tells you a source failed alignment, never what the messages said.

The postmaster dashboards

Google Postmaster Tools shows Gmail's own opinion of your domain: reputation tier and user-reported spam rate. Microsoft's SNDS shows complaint and trap data for sending IPs you control, with JMRP as its complaint feed. This slot is unique: the data comes from inside the receiver, while every other tool in the box observes from outside. The postmaster lesson covers both.

The blind spots are coarseness and coverage. The data is aggregated, gated behind volume thresholds low-volume senders never clear, and each dashboard speaks for one receiver: Gmail's opinion says nothing about Outlook's.

What the whole box can't see

Line up all eight slots and two things remain invisible: per-message placement (inbox versus spam folder at a given provider is published nowhere) and engagement, which lives in your ESP's stats. Every vendor claiming to sell you those is selling an estimate. The toolbox covers the technical layer completely, and that is the layer that breaks without symptoms. A good trade.

A smoke alarm with no battery

These tools are how you see decay; decay does not announce itself any other way. A toolbox nobody opens on a schedule is a smoke alarm with no battery: reassuring on the shelf, useless on the night it matters. The schedule itself is the routine from monitoring for decay; this lesson just stocked the shelf it draws from.

The lab: run the tour

On your own domain, or read-only against any well-known domain if you don't have one yet, touch every slot once:

Pull your SPF, DMARC and MX records raw with dig or an online dig tool.
Run a dedicated record checker on the SPF record; note what it flagged that the raw lookup didn't.
Run the health check and read the whole report, including the sending tools it detected.
Check the domain on a multi-list blocklist checker, then confirm one result against Spamhaus's own lookup.
Open the raw source of any delivered email and find the header block. Don't decode it yet; just locate it.
At each step, write one line: what did this tool refuse to tell me?

The artifact is a one-page personal toolbox note: each slot, the occupant you chose, and the question it answers. When a tool dies, replace the occupant; the slot survives.

Next lesson: the header block you just located, and how to read it like the crime scene it is.

Terms from this lesson

toolbox slot - a diagnostic job (read DNS raw, check blocklists, process DMARC reports) that stays fixed while the specific tools filling it come and go.
record checker - a tool that parses one record type and judges its legality: SPF lookup counts, DMARC policy meaning, DKIM key length.
blocklist checker - a lookup of a domain or IP against published blocklists; multi-list checkers sweep many at once, the list operator's own lookup is authoritative.
single-message tester - a service that receives one real email at an address it provides and returns a scored report on that message's authentication and content.
DMARC report processor - a tool that turns aggregate DMARC XML into readable tables of sources, volumes and alignment results.
postmaster dashboard - a receiver-run console (Google Postmaster Tools, Microsoft SNDS/JMRP) publishing that receiver's own view of your reputation.
domain-only check - any test run from a domain name alone; it sees configuration but not behavior, so it cannot prove real messages are signed or delivered.

Check yourself

1. You suspect a colleague changed the DMARC record yesterday and want to see exactly what receivers get right now. Which slot do you reach for first?

2. A record checker reports your SPF record as fully valid. What can it still NOT tell you?

3. Why can a domain that passes every check in the free health check still be sending unsigned mail?

Scenario

A client reports their newsletter suddenly going to spam at Gmail, starting last Tuesday, after months of clean delivery. A well-meaning teammate has already run a single-message tester, gotten a strong score, and concluded the setup is fine.

The score is real. What was wrong with the choice of tool, and what do you reach for instead?