How to run an email deliverability audit, step by step

An email deliverability audit is a structured check of everything that determines whether your mail reaches an inbox: authentication records, sending reputation, list quality, infrastructure consistency, and actual placement outcomes. Run in the wrong order, an audit wastes time chasing blocklist entries or content tweaks when the real problem is a missing DKIM selector. Run in the right order, each step either clears a layer or points directly at the next thing to check.

Step 1: Confirm authentication is actually correct

Don't trust a dashboard that says "configured" - query the records directly.

dig +short TXT yourdomain.com | grep spf
dig +short TXT yourdomain.com | grep -i v=spf1

dig +short TXT selector1._domainkey.yourdomain.com
dig +short TXT default._domainkey.yourdomain.com

dig +short TXT _dmarc.yourdomain.com

Check three things in the output: the SPF record includes every actual sending source (not just the ones from a year ago), the DKIM selector your current ESP is signing with actually resolves (a migration that left an old selector active and never added the new one is extremely common), and the DMARC record's policy matches intent - p=none means you are only monitoring, not enforcing.

Step 2: Check alignment, not just presence

A record existing is not the same as it passing. Send a test message to a mailbox you control through every sending path in use (transactional API, marketing ESP, any SMTP relay) and check the authentication results header:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1;
       spf=pass smtp.mailfrom=bounce.yourdomain.com;
       dmarc=pass (p=quarantine sp=quarantine dis=none) header.from=yourdomain.com

dkim=pass with a mismatched d= domain, or spf=pass on the envelope sender but a different visible From domain with no DMARC alignment, is a pattern that technically passes each check individually but fails DMARC alignment overall - this is the single most common gap between "my records look right" and "my mail still gets flagged."

Step 3: Check sending reputation and blocklist status

Query the IP and domain against blocklists that are actually still operational and checked by major providers - Spamhaus (SBL, CSS), SpamCop, Barracuda Reputation, and Validity's Heatwave (launched September 2026) are current. SORBS shut down in June 2024 and should not be part of an audit checklist anymore; treat a "clean on SORBS" result as meaningless, not reassuring.

Pull your bounce and complaint rate for the audit period and compare against Google's published spam-rate threshold of 0.3% - staying meaningfully under that, not just under it, is the realistic target, since sitting right at the line leaves no margin for a bad week.

Step 4: Check list hygiene and sending pattern consistency

• What percentage of the active list has never opened or clicked in the last 90-180 days? A large dormant segment drags aggregate engagement down even if the active portion is healthy.
• Is sending volume consistent week over week, or does it spike around campaigns with no ramp? A sudden multi-times jump in volume on an otherwise-quiet domain is a reputation risk independent of content quality.
• Are hard bounces actually being suppressed on the first occurrence, or accumulating?

Step 5: Verify actual inbox placement, not just technical pass/fail

Everything above can look correct and the mail can still land in spam for a given provider - the only way to know is to send to real seed addresses across the providers your audience actually uses and check where the message lands, not just whether it was "accepted" at SMTP time.

Audit checklist summary

How long a full audit actually takes

Steps 1 through 4 can be completed within a day for a single domain with one or two sending sources - most of the time is spent waiting for a DMARC aggregate report to accumulate enough volume to be meaningful, which is why a one-off audit benefits from being scheduled a few days ahead rather than attempted entirely in a single sitting. Step 5, placement testing, benefits from being repeated across a few consecutive sends rather than treated as a single pass/fail snapshot, since placement for a single message can vary send to send even when the underlying reputation is stable.

What not to do

Do not run a blocklist check as the first step - a clean blocklist result tells you nothing if DMARC alignment is broken, and a listed IP with correct authentication is a faster, more specific fix than a vague "deliverability is bad" starting point. Do not check SORBS or any other defunct list and report it as a clean signal. And do not stop at "the record exists" for SPF/DKIM/DMARC - confirm actual pass/fail on a live test send, since a record can be syntactically valid and still fail to cover the sending source that's actually in use.

MailPilot's inbox placement testing through a seed-inbox network covers step 5 directly, alongside SPF/DKIM/DMARC checks and daily per-mailbox reputation tracking for steps 1 through 4, so an audit doesn't depend on stitching several separate tools together.