Skip to main content
Relaymetry

How to test email deliverability before you hit send

To test email deliverability, send a real message and read how a receiver judged it rather than guessing. Confirm SPF, DKIM, and DMARC pass and align from the Authentication-Results header, check whether the sending domain or IP is blacklisted, and, for bulk mail, look at inbox placement across providers. Do it before a campaign, not after the complaints arrive.

Test the message, not just the records

There are two very different things people mean by "testing deliverability." One is reading your published DNS to confirm SPF, DKIM, and DMARC exist and are well-formed. The other is sending a real message and seeing how a receiving server actually judged it. The first is necessary and quick. The second is the one that catches the problems that hurt, because alignment, reputation, and content only show up once a message is in flight.

A useful test sends from the system you use for production mail, then reads the verdict the receiver wrote. That is the difference between knowing your records look right and knowing your mail gets in.

Step 1: get authentication right first

A delivery test is only meaningful once the records are in place. Publish SPF and DKIM for the sending domain, add a DMARC record, and make sure the domain in your visible From header aligns with the SPF or DKIM domain. If any of that is missing or misaligned, fix it before you test anything else, because it will dominate the result. Email authentication explained covers how the three records work together, and the instant snapshot on the home page checks all of them for a domain in one pass.

Step 2: read the Authentication-Results header

When a receiver accepts your message it records what it checked in an Authentication-Results header, defined in RFC 8601. Open the raw message at the receiving end and look for it. You want three results: spf=pass, dkim=pass, and dmarc=pass.

The detail that trips people is alignment. A message can show dkim=pass while the header.d value belongs to a different domain than your From address, which means the signature is valid but does not represent you, so DMARC still fails. Check that the DKIM signing domain and the SPF domain line up with the domain a recipient sees. Always read this header from the receiver's copy of the message, since the receiver is the one that writes it; your outbound copy does not have it.

Step 3: check blacklists and content

Authentication can pass while delivery still fails, and the two usual culprits are reputation and content. Look up the sending domain and IP against public DNS blacklists with a blacklist lookup; a listing on a widely used list is enough to push mail to spam on its own. Then look at the message itself for the patterns filters dislike: image-only bodies with little text, bulky or broken HTML, links to domains with poor reputation, and bulk mail without a working unsubscribe.

Step 4: read inbox placement

Authentication tells you a message is trusted to be from you. It does not tell you where the message landed. Inbox placement testing fills that gap by sending to seed addresses across Gmail, Outlook, Yahoo, and others and reporting which delivered to the inbox, which went to spam, and which vanished. It matters most for bulk and marketing senders, where reputation and engagement decide placement after authentication passes. A small transactional sender chasing one bounce can usually skip it and rely on the header and blacklist checks.

Step 5: watch reputation over time

A single test is a snapshot. Reputation is a trend, so connect the continuous tools too. Google Postmaster Tools shows your domain and IP reputation, spam-complaint rate, and authentication results for mail to Gmail. Microsoft's Smart Network Data Services does the same for the sending IP into Outlook.com and Microsoft 365. Watching these means you see a reputation slide while you can still act on it, rather than discovering it when a campaign underperforms.

The fastest way to run the whole test

Doing all of this by hand for every send is slow. The email deliverability test runs the message-level checks in one place: you send a real email to a unique address, and it reads the Authentication-Results for SPF, DKIM, DMARC, and alignment, checks blacklist status, and surfaces content issues, so you get the receiver's-eye view without assembling it yourself. Pair it with the home-page snapshot for the DNS side, and you have covered both halves: the records that should be right and the message that proves they are.

If your mail is already going to spam and you want the causes in order rather than just a test method, start with why are my emails going to spam. For the full set of instruments and how to read each one, see email deliverability tools.

Frequently asked questions

What does an email deliverability test actually check?

A good test sends a real message and inspects the result rather than just reading your DNS. It confirms SPF, DKIM, and DMARC from the Authentication-Results header the receiver added, checks that the From domain aligns, looks for the sending domain or IP on public blacklists, and flags content or formatting that filters commonly penalize. Some tests also report where the message landed across several providers. The point is to see what a receiving server sees, not what you hope it sees.

How do I read the Authentication-Results header?

Open the raw message at the receiving end and find the Authentication-Results header, defined in RFC 8601. It records each check the receiver ran, written as name=result, so you are looking for spf=pass, dkim=pass, and dmarc=pass. A dkim=pass with a header.d that differs from your visible From domain is the classic sign of an alignment problem: the signature is valid but it does not belong to your domain, so DMARC still fails. Read the header from the receiver, not from your own outbound copy, because only the receiver writes it.

What is inbox placement testing and do I need it?

Inbox placement testing sends your message to a set of seed addresses across Gmail, Outlook, Yahoo, and others, then reports whether each one delivered to the inbox, the spam folder, or nowhere. It answers a question authentication cannot: even with everything passing, did the mail actually reach the inbox? It is most useful for bulk and marketing senders, where reputation and engagement decide placement. For a transactional sender mainly worried about a single bounce, reading the Authentication-Results header and blacklist status usually tells you enough.

How is a deliverability test different from the snapshot on the home page?

The home-page snapshot reads your published DNS: it tells you whether SPF, DKIM, DMARC, reverse DNS, and TLS are present and well-formed for a domain. A deliverability test goes a step further by sending an actual message and reading how a receiver judged it, including alignment and content signals that a DNS check cannot see. Use the snapshot to fix the records first, then run the message test to confirm a real send passes end to end.

How often should I test deliverability?

Test before any significant change and after any incident. Run a check before a large campaign, after you move to a new sending platform or IP, after editing SPF, DKIM, or DMARC records, and the moment recipients report missing mail. Beyond one-off tests, keep Google Postmaster Tools and Microsoft SNDS connected so you watch reputation and complaint trends continuously rather than discovering a problem only when a send underperforms.

Other deliverability problems

References

Browse all guides →