What an email deliverability audit tool actually checks (and what to look for)

A deliverability audit tool reads the same public signals the receiving mailbox uses to decide whether your email lands in the inbox or the spam folder. The difference between a real audit and a marketing page is whether it actually queries those signals, shows you the underlying records, and tells you the exact fix. Here is what a real audit checks, and what to look for in a tool.

The seven checks that decide delivery

A useful audit covers the records and reputation signals that actually gate inbox placement:

MX: does the domain even receive mail, and do the mail servers resolve to real IPs with matching reverse DNS?
SPF: which servers are allowed to send, and is the record within the 10-lookup limit with a proper -all or ~all?
DKIM: is there a signing key, is it a strong length (2048+), and does the selector actually resolve?
DMARC: is there a policy, does it align with SPF/DKIM, and is it set to rua so you get reports?
TLS / STARTTLS: does your mail server offer a modern TLS version, or is it falling back to a cipher a receiver will flag?
PTR / reverse DNS: does the sending IP's reverse DNS match the hostname, or is it a bare IP that looks like a spam source?
IP reputation: is the sending IP on any blocklist, and does it have a clean sending history?

Each of these is a live lookup. A real tool runs them against your domain right now, not from a cached snapshot, and shows you the actual record value so you can see exactly what is broken.

It must show the record, not just the score

The most common failure mode of a deliverability tool is a black-box score. You get a number, but when something breaks you cannot tell which record is the problem. Look for a tool that shows the exact TXT value, flags the specific issue (a missing -all, a weak DKIM key, an SPF lookup over the limit, a PTR that does not match), and hands you the fix to paste into your DNS. The SPF checker, DKIM checker, and DMARC checker do exactly this: they show the record and point at the problem.

It must open a real SMTP connection

DNS records are only half the story. A receiving mailbox also checks whether your mail server actually speaks TLS and whether the IP has a clean reputation. A real audit opens a real SMTP connection to your MX, checks the TLS version and cipher, and looks up the IP on the major blocklists. If a tool only reads DNS and never talks to your mail server, it is missing the half of the decision that happens at connection time.

It must keep checking, not just check once

Records break. A new include: gets added to your SPF, a DKIM key rotates, a provider changes your sending IP, a certificate expires. A one-time audit tells you where you are today; it does not tell you when you break. The tools worth paying for re-run the full audit on a schedule and alert you the moment a record changes or a check flips from pass to fail. That is the difference between catching a deliverability drop the day it happens and finding out from a customer who says their emails are going to spam.

It must be read-only and account-free

The best audit tools are the ones you can run in 30 seconds with no setup. They query your public DNS read-only and open a real SMTP connection, the same way Gmail and Microsoft do. No account, no DNS changes, nothing to install. If a tool requires you to forward an XML file, add a CNAME, or create an account before it will show you a single result, it is adding friction to the one action that should be frictionless.

What to do with the result

Run the audit on your sending domain. Read the score, then read each failed check and apply the exact record the tool hands you. Re-run the audit to confirm the score climbed. Then set up monitoring so the next time a record breaks, you find out before your customers do. Run a free audit on your domain and get the score, the exact records to fix, and the option to monitor them daily.