How to test email deliverability?

To test email deliverability, check four things in order: that your domain authenticates (SPF, DKIM and DMARC pass and align with the From address), where a real message lands at the large mailbox providers (inbox, a tab, spam, or rejected), why it landed there (the receiver's Authentication-Results header or bounce code), and how your reputation develops over time (spam-complaint rate and DMARC reports). A one-off test answers the first three questions. Only the fourth tells you whether the result will still hold next week.

Step 1: Rule out authentication problems

A placement test on a domain with broken authentication only measures the breakage. Start with the domain in your From address and every subdomain you send from (for example news.example.com):

• SPF: one record, at most 10 DNS lookups, covering every platform that sends for you.
• DKIM: a 2048-bit key for each platform, signing with your domain (d=example.com) rather than the platform's.
• DMARC: a record at _dmarc with at least p=none and a rua= reporting address.
• Reverse DNS: every sending IP you control has a PTR record that resolves back to the same IP. Large providers manage this for their own IPs.
• Blocklists: your sending IPs and the domains in your links are not listed.

The full deliverability test checks the DNS side in one pass; how to check your domain's email security shows the same checks by hand. Fix failures before going further. What each mailbox provider requires is summarised in Google and Yahoo sender requirements and Microsoft Outlook sender requirements.

Step 2: Check one real message end to end

DNS shows what you published; a delivered message shows what the receiver concluded. The email deliverability tester gives you an address to send to and reports how SPF, DKIM and DMARC evaluated on that message, together with spam indicators.

Send from your production system: the same platform, From address and template you use for real mail, not your personal mail client. Repeat this for every platform that sends as your domain (mailbox provider, newsletter tool, CRM, helpdesk, invoicing). Each has its own configuration and fails independently.

Step 3: Measure placement with seed mailboxes

Mailbox providers do not report inbox placement to senders, so the only direct measurement is to send to accounts you control and look. A practical seed list has at least one account at each provider your recipients use:

• Gmail (personal) and a Google Workspace domain
• Outlook.com or Hotmail (personal) and a Microsoft 365 tenant
• Yahoo Mail
• iCloud Mail
• regional providers that matter for your list, such as GMX or Web.de for German recipients

Send the real message through the real platform to the seed list, and record for each account whether it arrived in the inbox, a tab (Gmail Promotions or Updates, the Outlook Other tab), spam or junk, or not at all. A missing message is a result too: look for a bounce in the sending platform's logs.

Treat seed results as a sample, not a measurement of your whole list. Your seed accounts have no history with your mail, while real recipients do, and providers take recipient behaviour into account. Seeds catch configuration and content problems; they do not predict an exact inbox percentage. Commercial seed-list services work the same way with more accounts.

Step 4: Read why the message landed where it did

For each delivered copy, open the raw message (Gmail: Show original; Outlook: View message source) and find the receiver's Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google header.b=Ab12Cd34;
       spf=pass (google.com: domain of bounce@​mail.example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=bounce@​mail.example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Read it part by part:

• dkim=pass header.i=@example.com: signed and verified with your domain. If the only passing signature belongs to sendgrid.net or another platform domain, DKIM does nothing for DMARC.
• spf=pass ... smtp.mailfrom=bounce@​mail.example.com: the envelope (bounce) domain passed SPF. It aligns with example.com under DMARC's default relaxed alignment because it is a subdomain of it.
• dmarc=pass: at least one of the two passed and aligned. dis=NONE means no policy action was applied to this message.

Outlook.com writes its verdict to Authentication-Results as well and adds a composite result, compauth=pass reason=.... The email header analyzer parses a pasted header for you, and how to analyze email headers explains every field.

If the message was rejected instead, the bounce code usually names the cause:

• 550 5.7.26 (Gmail): the message failed authentication or DMARC. Fix SPF and DKIM alignment with the From domain.
• 550 5.7.25 (Gmail): the sending IP has no valid reverse DNS.
• 421 4.7.28 (Gmail): temporary rate limiting because of an unusual rate of unsolicited mail. Slow down and find the source of the complaints.
• 550 5.7.515 (Outlook.com): a high-volume sending domain does not meet Microsoft's SPF, DKIM and DMARC requirements.

Step 5: Interpret the placement pattern

• Spam or rejected everywhere: authentication, a blocklist listing or a broken DNS record. Go back to step 1.
• Spam at one provider only: usually your reputation at that provider. Check its sender tools (step 6).
• Transactional mail in the inbox, newsletters in spam: a problem specific to that stream, often a newsletter platform that does not sign with your domain. Compare the headers of both.
• Gmail Promotions tab: a classification, not a spam verdict; the message was delivered. That is normal for marketing. Password resets and invoices should not end up there; if they do, keep promotional content out of them and send them from a separate stream.
• Inbox at every seed, yet complaints from real users: seed tests cannot see engagement. Look at the reputation data instead.

Step 6: Monitor reputation over time

A placement test is a snapshot. These free sources show the trend:

• Google Postmaster Tools (postmaster.google.com): verify your domain with a DNS TXT record. It shows the user-reported spam rate for mail to Gmail users and your compliance status against Google's sender requirements. Google asks senders to keep the spam rate below 0.1% and never let it reach 0.3%. Data only appears once you send enough mail to Gmail.
• Microsoft SNDS (Smart Network Data Services): per-IP data for mail to Outlook.com, for IPs you can show you control. Mainly useful when you run your own sending IPs.
• Yahoo Sender Hub: Yahoo's portal for sender support and its complaint feedback loop.
• DMARC aggregate reports: daily XML reports in which receivers list every IP that sent mail as your domain and whether SPF and DKIM passed and aligned. Unknown IPs failing DMARC are spoofing or a forgotten platform; your own platforms failing alignment need fixing. The DMARC report analyzer turns the XML into a readable table.

A repeatable routine

• Before a new platform, domain or template goes live: steps 1 to 5.
• Weekly, for active senders: spam rate in Postmaster Tools and a look at the DMARC reports.
• Monthly, and after every DNS change: a fresh scan of every sending domain and subdomain.
• After a drop in opens or placement: a seed test of the affected stream, and a comparison of its headers with an older message that landed well.

Common testing mistakes

• Testing from your own mail client instead of the production platform. Different servers and different signatures give a different result.
• Testing a different message than you send. Templates, links and tracking domains all affect filtering; test the real one.
• Reading only SPF and DKIM. Both can pass while DMARC fails, because neither aligns with the From domain.
• Treating one inbox result as proof. One seed in the inbox says little about a list of thousands; the trend data matters more.
• Forgetting subdomains and secondary platforms. The newsletter tool on news.example.com needs its own SPF, DKIM and DMARC check.