How to run an email deliverability audit

The repeatable email audit: intake, outside-in evidence, the client-access checklist, safe-change practice, and a findings write-up with priorities.

Last updated 19 July 2026

After this lesson you can take a domain you have never seen and turn it into a findings document its owner can act on. A deliverability audit is a fixed sequence run the same way every time: intake questions, outside-in evidence, inside evidence once you are granted access, a written finding for each problem, and a fix plan in priority order. Every tool in it is free and you met all of them in the toolbox. What a client pays for is not the tools. It is the sequence, and the judgment about what matters first.

Hold on to one framing for the whole lesson: an audit is evidence plus priorities. It is not a lecture about email, and it is not a sales pitch for the fixes. The deliverable is a document; when the document is delivered, the audit is done. That fixed scope is what makes it something you can quote a price for, and it is what separates you from the consultant who bills hours until the client gives up.

Start with questions, not tools

The intake interview comes before the first dig, because the symptom is usually reported wrong. "Our email goes to spam" might mean one Gmail recipient complained, or open rates halved in March, or the owner's replies to his accountant bounce. Each of those is a different investigation, and you learned in the triage tree how differently they branch.

Ask, at minimum: what exactly was observed, by whom, at which mailbox provider, starting when. What changed in the month before that (new website host, new ESP, a rebrand, an intern in the DNS panel). Every tool that sends email as the domain, knowing the list will be incomplete. Where the address list came from, and when it was last cleaned. Volume and cadence. Whether any bounce messages were kept, because a bounce is evidence you can read directly.

Write the answers down. They go in the report as reported symptoms, kept separate from what you verify yourself.

The outside half

Everything in this stage works with zero access, which is why it comes first. You query public DNS for the MX, SPF, and DMARC records and whatever DKIM selectors the intake lets you guess. You run the domain and its sending IPs through blocklist checkers. You run the free health check, which does the record-reading and ESP-detection pass in one shot and catches the syntax rot a human eye skims past. If the client can forward you one real recent email as raw source, you read its headers the way reading email headers taught, and you now have the receiver's verdict in Authentication-Results.

This is the same evidence chain you ran in the capstone, just pointed at a stranger's domain. On a typical small-business domain, the state to expect is not "nothing configured". It is "configured once, decayed since": an SPF record fossilized with includes for tools the business quit years ago, a DKIM CNAME that stopped resolving after a host migration, a DMARC record someone published and nobody ever read reports from.

The inside half

Some evidence only exists behind a login, and you request it rather than guess at it. Inside the ESP: whether domain authentication is actually enabled, whether a custom Return-Path is configured, what the suppression list looks like. Inside Google Postmaster Tools, once the client grants your account access: spam-rate history and reputation trend, the closest thing to Gmail's own opinion you will ever see. The DMARC report mailbox, if one was ever configured, is a log of every source sending as the domain, including the ones nobody authorized.

The access checklist

Send this list on day one, in writing, with the reason for each item. Clients grant access faster when they understand why, and the list itself signals that you have done this before.

DNS: a read-only login or a text export of the zone. Reason: you audit records as the public resolves them anyway; you need to see the panel only to catch what is staged but not live.
Postmaster Tools: the client adds your Google account to their verified domain in Google Postmaster Tools. Reason: reputation and spam-rate data exist nowhere else.
ESP: a read-only seat if the ESP supports roles, otherwise a walkthrough on a call. Reason: authentication toggles and list practice are invisible from outside.
DMARC reports: access to the rua mailbox or the report processor, if either exists. Reason: it is the only census of everything sending as the domain.

The principle behind the list is read-only first. Ask for the minimum that lets you see, and take edit power only when a scoped fix engagement starts. This protects the client, and it protects you: if something breaks during the week you were looking around, an access log showing you could not have changed anything is worth more than your word.

Before anything gets changed

The audit itself changes nothing, but the fix plan you deliver promises how changes will be made, so put the discipline in writing. Before the first edit, export every DNS record that will be touched, as text, into a file the client keeps. Then one change at a time, with outside-in verification between each, exactly as verifying deliverability fixes drilled; two simultaneous edits mean an improvement and a regression can cancel out and teach you nothing. And every edit goes in a change log the client owns, not you: date, record, old value, new value, reason. Most decay I have traced back in monitored domains starts with an edit nobody wrote down.

The write-up

Use the findings format from the capstone: for each finding, the symptom, the evidence (the actual query output, quoted), the cause in plain English, the fix, and a priority. Lead the document with a half-page summary the owner can read without you in the room. Then the fix plan, ordered by the dependency logic from repairing a decayed setup: inventory before SPF, authentication before alignment, DMARC last.

Be honest in the document about what you could not see. Without inside access there is no engagement data, no complaint rate, no proof of where the list came from; the intake interview covers those by asking, and the report should say "reported, not verified" wherever that is the truth. An audit that admits its limits is more credible, not less.

One more limit belongs in the closing paragraph of every audit you write: the findings expire. The document is a snapshot of a system that decays, which the client's own domain just proved, and it is the honest bridge to the monitoring conversation later in this part.

The lab: your first real audit

Do the outside half for real, on a domain you do not own. Pick a local business you actually know, run the intake on yourself (what would you ask them?), then work the outside-in sequence: DNS records, blocklist status, the health check. Read-only, look but never touch, and an ethics note that matters: do not cold-pitch the findings to the business as a sales tactic unless you disclose upfront that the audit was unsolicited. Surprise diagnoses of strangers are a spam tactic, and you are in the anti-spam business now.

Write it up in the full findings format, including the "reported, not verified" gaps an outside view leaves. That document is your portfolio piece: the thing you show the first paying client as proof you have done this before.

The next lesson takes the findings document you just produced and teaches the harder half of the job: explaining it to the person who has to pay for the fixes.

Terms from this lesson

intake interview - the structured questions asked before any tool runs; it pins down the real symptom and covers the evidence no outside tool can see.
outside-in evidence - everything verifiable with zero access: public DNS, blocklist status, the health check, headers from a forwarded message.
client-access checklist - the written day-one request for DNS, Postmaster Tools, ESP, and DMARC-report access, each item with its reason.
read-only first - the principle of asking only for viewing access during an audit, taking edit power only when a fix engagement starts.
record backup - a text export of every DNS record before it is edited, kept by the client as the restore point.
change log - the client-owned record of every edit: date, record, old value, new value, reason.

Check yourself

1. What is the correct order of the audit sequence?

2. Why ask for read-only access during the audit rather than full admin?

3. Which of these can an outside-in audit NOT verify without inside access?

Scenario

A new client signs on Monday morning. Open rates have been falling for two months and the owner is anxious. No access has been granted yet, but he says: 'Just start fixing things today, I'll get you logins eventually.'

What do you do first?