GUIDE
Email deliverability audit checklist: 12 checks in the order that finds the cause
Run an email deliverability audit yourself: twelve checks from bounce text to DMARC alignment, the evidence each needs, and when to get help.
This audit is a fixed sequence of twelve checks for why mail is being rejected, delayed or filtered. Run them in the order below, with the evidence for one affected message in hand, and stop at the first check that explains it. The order matters: the cheap, decisive checks come first, and the ones that need a mailbox provider's dashboard or your platform's logs come later. DemiEmail investigates reported delivery problems from the same material, the available rejection messages, headers, reports and sending configuration, which is why the list ends with what a scoped engagement adds when the checklist does not find the cause.
The twelve checks
The rows draw on the evidence guide, the free DemiSignal check (opens in a new tab), the dmarc=fail guide (opens in a new tab), Google's sender guidelines (opens in a new tab), Google Postmaster Tools (opens in a new tab) and Microsoft SNDS (opens in a new tab); each is explained in the sections that follow.
| # | Check | Evidence it needs | A found-it result looks like |
|---|---|---|---|
| 1 | What happened to the message? | the sent folder, the platform's activity log, the recipient's spam folder | the message was never sent, never accepted, delayed, bounced, or filtered |
| 2 | What does the bounce say? | the whole bounce message | a 5.x.x permanent code with text that names the cause |
| 3 | Are SPF, DKIM and DMARC published and sound? | the domain name | a fail or warning on the free DemiSignal check |
| 4 | Do the messages pass DMARC alignment? | full headers of the affected message | dmarc=fail in the Authentication-Results header |
| 5 | Do you meet Google's sender requirements? | your sending setup | no SPF or DKIM, no PTR record, or no DMARC reports |
| 6 | What do Postmaster Tools dashboards show? | Postmaster Tools access for your domain | a spam-rate, reputation, authentication or delivery-error problem |
| 7 | What does Microsoft SNDS show for your IPs? | SNDS access to the IPs you send from | reputation data or junk reports for an IP |
| 8 | What does the sending platform's record say? | the platform's event for the message | the platform's own record of what happened to it, within its retention period |
| 9 | Which tools send as your domain? | the list of integrations, CRM and automation sending email | a sending service missing from the domain's authentication setup |
| 10 | Is the problem tied to one list, flow or template? | your own sending records, split by list, flow or template | the problem appears in one of them and not the others |
| 11 | Did the receiver flag content? | the bounce or filtering reason | a bounce text that names content, links or attachments |
| 12 | What changed recently? | DNS history, provider changes, volume, templates | a change on or before the date the problem started |
Before you start: collect the evidence
The guide What to collect when email delivery fails is the evidence list for one affected message: the exact bounce text, the full headers, your sending platform's record of it and the time it was sent. Collect it before you contact anyone, and note when the problem started and whether it affects one recipient or many. It also sets the first distinction the audit depends on: a recipient not seeing an email in their inbox is not the same as the email not being delivered, and sometimes the message was never sent to the recipient at all.
Checks 1 to 4: rejection and authentication
1. What happened to the message? The evidence guide separates the outcomes before any other step: the message was never sent at all, never accepted by the sending platform, or accepted and then filtered, with delays and bounces as the other two cases. Name yours first. If the recipient's administrator uses Google Workspace or Microsoft 365, they can look the message up from the receiving side.
2. What does the bounce say? Copy the whole bounce message, not a summary. The status code's first digit decides the next step: a code starting with 4 is a persistent transient failure, a temporary condition that delayed or stopped the attempts to send; a code starting with 5 is a permanent failure that resending in the same form is unlikely to resolve. Read the text after the code; if it mentions authentication, policy or reputation, the next checks are where to confirm it.
3. Are SPF, DKIM and DMARC published and sound? Run the free DemiSignal check (opens in a new tab) on your sending domain; it needs no account and only reads the public DNS records you enter. It runs four checks and reports each as pass, warning, fail or error. For SPF it flags a missing record, a rule that lets anyone send or decides nothing, a soft fail, and a record close to or over the 10 DNS lookup limit. For DMARC it flags a missing record, a policy of none, no reporting address, a policy that covers only part of your email, and subdomains left at none. For DKIM it looks for keys under commonly used selectors and flags keys that are weak, revoked or of an unknown type. For MX it shows where the domain receives email. A fail here is a found-it result. A clean result means the records exist and says nothing about any one message: a DNS finding shows how the domain is set up, not where a particular message landed.
4. Do the messages pass DMARC alignment? Records can be published and still not apply to the message: RFC 9989 (opens in a new tab) requires that the domain associated with the SPF or DKIM pass be aligned with the Author Domain, the From domain, for a DMARC pass. The full headers of an affected message carry the receiver's Authentication-Results line, and the dmarc=fail guide (opens in a new tab) explains how to read it and how to fix SPF and DKIM alignment for services and forwarded mail. For a Google Workspace domain, the Google Workspace guide (opens in a new tab) shows where each record value comes from in the Admin console.
Checks 5 to 8: sender requirements, reputation and platform data
5. Do you meet Google's sender requirements? Google's email sender guidelines (opens in a new tab) require senders to set up SPF or DKIM for their sending domains, to have valid forward and reverse DNS (PTR) records for sending domains or IPs, and to format messages to RFC 5322; Google also recommends DMARC reports so you can monitor email sent from your domain or appearing to be, and notes that on a shared IP the activity of every sender affects the reputation of all of them. Treat a gap on any of these as the finding for mail to Gmail.
6. What do Postmaster Tools dashboards show? Google Postmaster Tools (opens in a new tab) monitors outgoing email you send to personal Gmail accounts, and its dashboards carry detailed information about spam rate, reputation, message authentication and delivery errors. Two limits: the data applies only to mail sent to personal Gmail accounts, and data can be missing when the day's message volume is too low.
7. What does Microsoft SNDS show for your IPs? Microsoft's Smart Network Data Services (opens in a new tab) gives senders detailed data about individual IPs and includes the Junk Email Reporting Program, which sends reports when users junk your messages; Microsoft states that deliverability to Outlook.com is based on your reputation. Access requires a Microsoft account and a request for the IPs you are responsible for.
8. What does the sending platform's record say? The evidence guide covers finding the platform's record of the affected message and how long each platform keeps it, with one caution: a delivered status means less than it sounds. In Mailgun's events, delivered means the recipient's email server accepted the message, and once Postmark hands a message to the recipient's mail server it loses all sight and control over it.
Checks 9 to 12: integrations, list signals, content flags, recent changes
9. Which tools send as your domain? List every service that sends email using your domain: the mail platform, the CRM, forms, automation and the application itself. Each one belongs in the domain's authentication setup, which is the scope DemiEmail works in: configuring or troubleshooting SPF, DKIM and DMARC across the services sending email for your business. The DemiSignal check page (opens in a new tab) puts the point plainly: reports show which services send email as your domain, including ones nobody remembers setting up. RFC 9989 (opens in a new tab) describes aggregate reports as revealing mail streams using your domain that do not pass, and requires legitimate ones to be fixed before an enforcement policy is published.
10. Is the problem tied to one list, flow or template? Split your own sending records by list, flow or template and note where the problem sits. This checklist gives no list-management advice; it only asks you to record what you find.
11. Did the receiver flag content? Only where the bounce or the filtering reason names content, links or attachments. Do not guess at content causes without a receiver saying so.
12. What changed recently? DNS edits, a provider change, a volume jump, a new template or a new integration on or before the date the problem started. Match the change to the first check that moved.
When the checklist does not find it
When the evidence is collected and the twelve checks do not point at a cause, the next step is a scoped engagement: a sending-service and DNS review, authentication setup and remediation, and verification with a documented handover. DemiEmail investigates reported delivery problems using the available rejection messages, headers, reports and sending configuration, and works from what can be checked: bounce and rejection messages, message headers, DMARC reports, DNS records and the settings of the services that send your email. A person reads your enquiry and replies by email with questions or with what a scoped piece of work would involve; the work, required access, deliverables and price are agreed before any paid work starts, and mailbox providers still decide where messages land, so there is no inbox placement promise.
Sources
- DemiEmail homepage: what we help with, how it works
- DemiEmail: what to collect when email delivery fails
- DemiSignal: free SPF, DKIM and DMARC check (opens in a new tab)
- DemiSignal: dmarc=fail (opens in a new tab)
- DemiSignal: Google Workspace SPF, DKIM and DMARC (opens in a new tab)
- Google: email sender guidelines (opens in a new tab)
- Google: set up Postmaster Tools (opens in a new tab)
- Microsoft: Smart Network Data Services (opens in a new tab)
- RFC 9989: DMARC (opens in a new tab)
Questions
How long does a self-audit take?
It depends on how fast you can collect the evidence. The checks themselves are quick once you have the bounce text, the headers and your platform's record of one affected message in front of you.
Which tools does this checklist use?
The free DemiSignal check, which needs no account; the mailbox providers' own sender dashboards, Google Postmaster Tools and Microsoft SNDS; and your own sending platform, the bounce message and the full headers.
What does a professional audit cost?
DemiEmail quotes work after understanding the setup and scope, and confirms the price and deliverables before any paid work starts. There is no fixed price and no free audit.