Email deliverability audit: a step-by-step checklist

An email deliverability audit checks six things in order: DNS authentication, the headers of a real message, the reputation signals mailbox providers publish (Google Postmaster Tools, Microsoft SNDS), blocklists, complaint and bounce rates, and list quality. Do it before the first send and after any change, then monitor weekly. The result is a list of fixes with an owner and a date, and a rule for when to stop sending.

Deliverability is not one number. It is whether mail is accepted, and where it lands, at each provider. This checklist covers what you can verify yourself and what providers state in their documentation. It promises no inbox placement, because only the providers control that.

Step 0: Inventory what you send from

List every sending domain, mailbox, IP address and tool, including any other system that sends from the same domain. You cannot audit what you have not listed.

Step 1: DNS authentication

Check SPF, DKIM and DMARC on every sending domain. The records themselves are explained in SPF, DKIM and DMARC for cold email.

Commands for the lookups, with an example domain:

dig +short TXT example.com
dig +short TXT s1._domainkey.example.com
dig +short TXT _dmarc.example.com

An example set of records:

example.com.               IN TXT  "v=spf1 include:_spf.sendservice.example -all"
s1._domainkey.example.com. IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.        IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

If you move from p=none toward enforcement, Microsoft’s own advice is to go gradually, none, then quarantine, then reject, to avoid losing legitimate mail.

Step 2: Read the headers of a real message

Records can look right and the message can still fail. Send a real campaign message, not a test from your personal client, to a Gmail address and an Outlook.com address you control, and open the original.

1. Authentication results. Find spf=pass, dkim=pass and dmarc=pass, with the domain after header.from= equal to your From domain. A pass for a service’s domain is not alignment. The Outlook error 550 5.7.515 is what failure here looks like at scale.
2. Unsubscribe headers. List-Unsubscribe with an HTTPS address and List-Unsubscribe-Post: List-Unsubscribe=One-Click, covered by the DKIM signature. See one-click unsubscribe.
3. Encryption and DNS. Google and Yahoo ask for valid forward and reverse DNS for the sending IP, and Google asks for TLS. Gmail’s “Show original” displays the transport details.
4. Format. Messages should follow RFC 5322, as both providers require.

Step 3: Google Postmaster Tools

Postmaster Tools is the provider’s own view of your mail at Gmail. Add every sending domain and verify it with a DNS record. Google lists these dashboards on its help page: compliance status (compliant, needs work or no data for each requirement), spam rate, IP reputation, domain reputation, feedback loop, authentication, encryption and delivery errors. The reputation dashboards use four levels, bad, low, medium and high. Dashboard availability changes over time, so check Google’s page for what is current.

What to read, in order:

1. Compliance status. Anything marked “needs work” is on Google’s list of requirements.
2. Spam rate. The percent of your messages that recipients manually mark as spam. Google asks for below 0.3% and recommends below 0.1%.
3. Authentication and encryption. Percent passing SPF, DKIM and DMARC, and percent sent over TLS.
4. Delivery errors. Rejections and temporary failures for authenticated messages.

Two limits. Google notes that data can be missing when the daily message count is too low, so a quiet dashboard on a small domain does not mean healthy. And Postmaster Tools only covers Gmail. Google also says it does not track open rates and that low open rates are not a reliable sign of spam filtering, which is a reason to leave opens out of an audit. See why open rates lie.

Step 4: Microsoft SNDS and JMRP

Microsoft lists two free services for senders. SNDS (Smart Network Data Services) gives data on how users are rating the mail from your sending IP addresses at Outlook.com. JMRP (Junk Email Reporting Program) sends you reports when Outlook.com users mark your messages as junk. Access is requested with a Microsoft account for your IP ranges, and Microsoft says network access expires after 10 months and that reputation is always the responsibility of the sender.

Because both are tied to IP addresses, they are useful when you control the IPs. If your mailboxes are at Google Workspace or Microsoft 365, the IPs belong to the provider and there is nothing to register. The older SNDS address now redirects to a newer Microsoft page, so use the current page for sign-up and read what it says about access.

Step 5: Blocklists

A blocklist is a public list of IP addresses or domains that receivers use as a spam signal. Google’s guidelines say messages from IP addresses on a blocklist are more likely to be marked as spam, and tell senders on shared IPs to make sure the address is not listed. They also advise checking regularly that your domain is not listed as unsafe by Google Safe Browsing.

An audit should:

1. Check each sending IP and each sending and tracking domain against the lists you care about, using a lookup tool.
2. For a listing, find out why before asking for removal. Without a fix it returns.
3. Read each list’s own policy. We did not review specific lists, and policies differ.

On a mailbox provider’s own IPs, a listing is a reason to ask the provider and reduce volume.

Step 6: Complaint rate

The complaint rate is the number the providers act on. Calculate it as spam reports divided by delivered messages, per domain and per mailbox, over a window of several days.

complaint rate = spam reports / delivered
Google: below 0.3% required, below 0.10% recommended
Example: 3 reports in 2,500 delivered = 0.12%

Sources of reports: Postmaster Tools for Gmail, the Complaint Feedback Loop for Yahoo, and JMRP for Outlook.com. Every complaint must lead to suppression of that address, and the audit should confirm that it does. Then ask why: the list, the offer or the frequency.

Step 7: Bounce handling

A bounce is a rejection with a code. SMTP replies beginning with 4 are transient and those beginning with 5 are permanent, and RFC 5321 says a client must not retry the same command after a 5xx. RFC 3463 gives enhanced status codes in the form class.subject.detail, with class 4 for persistent transient failures and class 5 for permanent ones.

The audit should confirm four things:

1. Hard bounces are suppressed at once and never retried.
2. Soft bounces have a retry limit, and repeated soft failures are escalated.
3. Policy blocks are not counted as bad addresses. A 5.7.x code often points to your domain or IP, so removing the recipient hides the real problem.
4. There is a pause rule. Set a bounce threshold per mailbox and per domain at which sending stops. We do not give a number, because we found no provider page that publishes a safe bounce rate. Google advises that if messages start bouncing or being deferred, you reduce the sending volume until the error rate falls, then increase slowly.

Step 8: List hygiene

Most deliverability problems are list problems. Check:

• Source. Google’s guidelines say not to purchase email addresses from other companies and not to send to people who did not sign up. Cold outreach is inherently outside the second, so keep the list narrow and the offer relevant.
• Verification. Verify addresses before sending and remove invalid ones. Microsoft recommends removing inactive or invalid addresses regularly, monthly or quarterly.
• Suppression. Unsubscribed, complaining and hard-bounced addresses are excluded from every campaign.
• Opt-out speed. Google asks for unsubscribes within 48 hours, Yahoo within 2 days.

Step 9: Sending pattern

Google’s guidance is to increase volume slowly, and says the more email you send, the more slowly you should increase it, and that daily sending allows quicker increases than weekly. It also says to start with a low volume and increase over time, and to monitor delivery as you do. Check that:

• New mailboxes and domains start at low caps and rise in steps.
• Volume changes follow your monitoring, not the calendar.

See cold email without warm-up.

Step 10: A routine

Write down who pauses sending, at what level, and what must be true to restart. An audit without a stop rule is a report.

How Dooxout handles this

Dooxout’s preflight runs before a campaign starts. It checks DNS for SPF, DKIM and DMARC and the sending identity, scrubs the audience against the suppression list and shows the verification status. It sends the first message, rendered with real fields, from each sending mailbox through the live path to DeliverProbe, which analyzes headers, authentication, content and blocklists and returns a score and findings. A failing result blocks the launch by default. A person with the right can launch anyway, with a reason that is logged, and the agent cannot override it. If DeliverProbe cannot be reached the result is “could not check”, never a silent pass.

Every message carries the List-Unsubscribe headers and an unsubscribe link. A hard bounce suppresses the address, a soft bounce may be retried on the same step up to two times, and a complaint suppresses the address and stops its sequence. Bounce and complaint thresholds pause sending automatically, and you set them. Suppression of unsubscribed and complaining addresses is the one rule that cannot be turned off. Delivery events can be tailed through the API or MCP. The platform warns and recommends, and the decision stays with you. It makes no promise about inbox placement. See email deliverability, cold email infrastructure and docs.