Skip to main content
Relaymetry

Email deliverability tools: what to test and how to read the results

Email deliverability tools fall into a few groups: record checkers for SPF, DKIM, DMARC, MX, and TLS; blacklist and reverse-DNS lookups for reputation; header and report analyzers for reading what receivers actually decided; and message-level tests that send a real email and report inbox placement. This page walks each group, the question it answers, and how to read its result, then points you to a single test that runs the message-level checks together.

Group the tools by the question they answer

There are a lot of deliverability tools, and most lists throw them at you alphabetically. It is easier to pick the right one if you sort them by the question each answers: are my records correct, is my reputation clean, what did a real receiver decide, and where does my mail actually land. Work through those questions in order and the tools fall into place.

Almost all of the technical layer is checkable for free. The one thing no third party can give you is the providers' own reputation view, which is why the list ends with the dashboards Google and Microsoft run themselves.

Authentication checkers

These read your published DNS and tell you whether the records that prove who sent a message are present and valid. Check SPF with an SPF checker, DKIM with a DKIM checker, and DMARC with a DMARC checker. Confirm the domain can receive mail with an MX lookup and that it supports encrypted transport with a TLS check.

How to read them: a pass means the record exists and parses, not that it is doing its job. SPF should authorize every service that sends for you and stay within the ten-lookup limit. DKIM should have a published key for the selector your mail signs with. DMARC matters most for alignment, so a present DMARC record still leaves you to confirm the From domain lines up with the SPF or DKIM domain. If you are building records rather than checking them, the SPF, DMARC, and DKIM record generators produce valid syntax to publish.

Blacklist and reverse-DNS lookups

Once the records are valid, the next question is reputation, and the cheapest signal is whether anyone has flagged you. A blacklist lookup checks the sending domain and IP against public DNS blacklists; a listing on a widely used one is enough to send mail to spam regardless of authentication. A reverse-DNS lookup confirms the sending IP has a PTR record that resolves to a hostname matching your sending host, which several providers require before they will trust the IP.

How to read them: a clean blacklist result is a floor, not proof of good reputation, and a single listing is worth resolving before anything else. A missing or generic PTR is a quiet cause of spam placement that records alone never reveal.

Header and report analyzers

These read what receivers actually wrote, which is the only way to confirm the records work on a real send. An email header analyzer parses the Authentication-Results header from a delivered message (RFC 8601) so you can see spf, dkim, and dmarc results and the signing domain for a specific email. For ongoing data, a DMARC report analyzer turns the XML aggregate reports providers send into per-source pass and fail counts, and a TLS-RPT report analyzer does the same for the encryption reports defined in RFC 8460.

How to read them: the header analyzer answers "did this message authenticate and align," while the report analyzers answer "which of my sending sources are passing or failing over time." The reports are what you read before tightening a DMARC policy toward reject, because they show every source using your domain.

Inbox-placement and message tests

Authentication and reputation checks still leave one question open: did the mail reach the inbox? Inbox-placement testing sends to seed addresses across providers and reports where each copy landed. An email deliverability test is the all-in-one in this group. You send a real message to a unique address, and it reads the Authentication-Results for SPF, DKIM, DMARC, and alignment, checks blacklist status, and surfaces content problems in one result, so you do not have to run the earlier tools one at a time.

How to read it: treat it as the receiver's verdict on a real send. If it passes and mail still goes to spam, the cause is reputation or engagement rather than configuration, which is the point at which the providers' own dashboards become essential.

The providers' own reputation dashboards

The receiving providers keep the reputation data no external tool can see, and both expose it free once you verify ownership. Google Postmaster Tools shows domain and IP reputation, spam-complaint rate, and authentication results for mail to Gmail. Microsoft's Smart Network Data Services shows complaint and trap data for an IP sending into Outlook.com and Microsoft 365. Connect them and you watch reputation as a trend instead of guessing from one test.

Where to start

Run them in the order the questions arrive: check the records, check the blacklist and PTR, analyze a real message, then run the all-in-one test and connect the reputation dashboards. For the method behind that sequence, see how to test email deliverability. If your mail is already going to spam and you want the causes ranked rather than a tool list, start with why are my emails going to spam.

Frequently asked questions

Which deliverability tool should I start with?

Start with the records, because a failing record explains most spam and bounce problems and is the fastest thing to fix. Run an authentication check on your domain to confirm SPF, DKIM, and DMARC are present and aligned, then a blacklist lookup on your sending domain and IP. Once the records are clean, move to a message-level test that reads how a real send is judged. Fixing records first means the later, slower checks are not chasing a problem you could have caught in a minute.

What is the difference between a record checker and a message test?

A record checker reads your published DNS and tells you whether SPF, DKIM, DMARC, MX, and TLS are present and well-formed. A message test sends or analyzes a real email and reads the Authentication-Results the receiver wrote, which is the only way to confirm alignment and see content and reputation signals. Record checkers catch configuration mistakes; message tests catch the problems that only appear once mail is in flight. You want both, in that order.

Do free deliverability tools tell me everything I need?

Free tools cover the technical layer completely: authentication records, blacklist status, reverse DNS, TLS, and reading an Authentication-Results header are all checkable for free. What free tools cannot give you is the reputation view the providers keep for themselves. For that you need Google Postmaster Tools and Microsoft SNDS, which are free but require you to verify ownership and connect your domain or IP. Free checkers plus those provider dashboards cover almost everything short of paid inbox-placement panels.

What tools check sender reputation?

Reputation is reported by the receiving providers, not by a third party. Google Postmaster Tools shows domain and IP reputation, spam rate, and authentication results for mail to Gmail; Microsoft SNDS shows complaint and trap data for an IP sending into Outlook.com and Microsoft 365. Public DNS blacklists are a related but separate signal: a blacklist lookup tells you whether a list has flagged your IP or domain, which is one input to reputation but not the whole picture.

How do I read a DMARC aggregate report?

DMARC aggregate reports are XML files mailbox providers send to the address in your DMARC record, summarizing how your mail authenticated across sources. They are hard to read by hand, so a report analyzer parses them into per-source pass and fail counts for SPF, DKIM, and alignment. Reading them tells you which sending services are aligned, which are failing, and whether any unexpected source is using your domain, which is what you need before tightening a DMARC policy toward reject.

Other deliverability problems

References

Browse all guides →