How to Test Email Deliverability Before You Hit Send

A marketer I helped last year had a ritual before every campaign. She pressed "Send test" in her platform, watched the message arrive in her own Gmail a few seconds later, and took that as proof. Then the campaign went out and the replies dried up. Her inbox had told the truth about exactly one mailbox, her own, which had years of opened newsletters from that sender and the sender's address in its contacts.

The big providers filter per recipient, so the one mailbox guaranteed to like you is the worst witness you could pick. Testing deliverability means sending the real message by the real route to an address with no history, and then reading what the receiving side saw.

The routine, in the order I run it:

1. Send the actual campaign, through the platform and domain you will use, to a test address that has never heard from you.
2. Check that SPF, DKIM and DMARC pass, and that they align with the From domain.
3. Check the unsubscribe headers, and that the DKIM signature covers them.
4. Check the sending IP for reverse DNS, TLS and blocklist listings.
5. Read the content findings rule by rule, then click every link.
6. After the send, keep an eye on Postmaster Tools and read your DMARC reports.

Your own inbox is the wrong witness

Gmail, Outlook and Yahoo all keep a history per recipient. If you have replied to a sender, dragged its mail out of spam or saved it as a contact, every later message from it gets that benefit in your mailbox and nowhere else. A newsletter's trouble usually sits in the mailboxes that have never heard of you, and those are exactly the ones a self-test never reaches.

The "Send test" button has a second problem. On more than one platform I have worked with, it takes a slightly different road from a real campaign. The subject gets a prefix, the list headers are dropped because a test is not a list message, and now and then the copy leaves from a different pool of IPs. A clean result from that button tells you about the button.

So I add the test address to the list itself, as a subscriber or as a segment of one, and let it receive the campaign exactly as everyone else will. Same From, same sending domain, same template, same click tracking. If the platform rewrites links or puts its own domain in the DKIM signature, the test copy shows that as well.

Where to send the test email

Any mailbox whose raw source you can open will do for a first look, though you will be reading headers by hand. The tester on this site exists for this step. The home page gives you an address that takes a single message and stops accepting mail an hour later. Put it on the list and send. Once the copy arrives, it is held against 42 checks on the message and the DNS behind it, and the fixes come back ordered by how many points each is worth, with a classic ten-point score next to one out of 100. The report link keeps working after the address has expired, which helps when somebody else owns the DNS and needs to see the problem.

We send nothing ourselves. The message leaves your platform, crosses the internet and arrives at a server that checks it the way a receiving provider would.

Authentication, and whether it lines up

I start with Authentication-Results. Every receiving server adds this header, and it is short.

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.esp-mail.example;
  dkim=pass header.d=esp-mail.example;
  dmarc=fail header.from=shop.example

Two passes and a failure, and the failure is the line that decides things. SPF passed for the platform's bounce domain. DKIM passed for the platform's signing domain. Neither is shop.example, the domain in the From line, and DMARC wants at least one of them to match it, which RFC 9989 calls identifier alignment. The longer explanation of the three records is in SPF, DKIM and DMARC explained. On every test I look for four things.

• dkim=pass with header.d= set to your domain or a subdomain of it. If the platform signs as itself, publish the DNS records it offers for a custom sending domain.
• An SPF record that stays within ten DNS lookups. RFC 7208 turns the eleventh into permerror, and DMARC counts that as SPF not passing.
• A published DMARC policy for the From domain. p=none satisfies the bulk sender rules, provided the record exists and the message passes.
• A bounce address on your own domain, so that SPF aligns too and you still pass when a forwarder breaks the DKIM signature.

The report files these under authentication, and each finding quotes the RFC section it rests on.

The unsubscribe headers

These are the headers a platform's test send is most likely to leave out, which is one more reason to test with the real campaign.

One-click unsubscribe needs two headers and a signature. RFC 8058 asks for a List-Unsubscribe header with an HTTPS URI and a List-Unsubscribe-Post header containing List-Unsubscribe=One-Click, and section 4 says a valid DKIM signature has to cover both. What I find most often is the second header missing from the signature's h= tag, and the compliance checks in the report look for exactly that. Without it, Gmail and Yahoo do not show their own unsubscribe button.

Here is where the three largest providers stood in September 2026.

Google spells its rules out in the sender guidelines and an FAQ. Yahoo has its best practices and its own FAQ, which also asks for unsubscribes to be honoured within two days. Microsoft describes its rule on the page about the 550 5.7.515 error.

The machine that sent it

Next comes the sending IP. The tester takes it from the connection your platform's server made, and the infrastructure checks start with three questions about it. Does the address have a reverse DNS name that resolves back to the same address? Was the connection encrypted with TLS? Is the address on any of the DNS blocklists receivers actually query (21 of them)? Gmail asks every sender for the first two, bulk or not.

In practice, when the IP is shared at a large platform, reverse DNS and TLS are almost always fine, and a blocklist hit is usually the pool's problem rather than yours. On your own server all three are yours to fix. What a listing means and how to get off one is in the blocklist post.

Content, and every link in it

Content matters less than the three steps above, and it is where people spend most of their time. The spam engines read the message here, SpamAssassin and Rspamd among them. I read the list of rules that fired before I look at either total. A rule worth a tenth of a point is noise. Three rules clustered around one image with no text beside it are a design decision you can reverse in a minute.

Links next. I click every one, the footer included, because the tracking domain is part of all of them and nobody looks at it. When a platform's click-tracking domain lapses or gets listed, all the links in the message go down together. The content checks test whether each link resolves and whether a threat feed lists it, but only a person notices a landing page that loads fine and still shows last month's offer. Public URL shorteners are worth removing on principle, since filters distrust anything that hides where it leads.

What a seed test adds, and where it stops

An inbox placement test (people also call it a seed test) is a different instrument. The message goes to a set of real mailboxes at Gmail, Outlook, Yahoo and other providers, and you learn which folder each copy reached. That answers a question no header can, which is where the message physically ended up.

I keep its limits in mind. The seed mailboxes have no history with you, so they miss whatever goodwill your real subscribers carry. The sample is small next to a real list, and two runs an hour apart can disagree. It also says where the copy went and not why, so a result like "spam at Outlook" sends you back to the headers anyway.

The tester here does both, and the start screen asks which one you want: the technical check of the message or real folder placement at several providers. I run them in that order. The message test comes first and fixes whatever the headers and DNS reveal, and placement follows once those are clean.

After the send

A few things only become visible once real volume has gone out.

Google Postmaster Tools shows the spam rate your Gmail recipients report, and a compliance status against the sender requirements, once you have verified the domain and sent enough mail for the numbers to appear. The rate is the one I watch. A rate that climbs after a campaign tells you something no pre-send test could. The Gmail post goes further into what Gmail weighs and in what order.

DMARC aggregate reports are the other source. Receivers send them daily to the rua address in your record, and they list every IP that sent mail as your domain, with its authentication results. The first week of them nearly always turns up a service you forgot was sending as you, and each one is a sender you never tested.

When the report does flag something, I fix one thing and test again, rather than fixing five and testing once. It is slower. It is also the only way to know which change moved the score. And if every check comes back clean and the mail still lands in spam, the causes left over are the ones in why emails go to spam, most of them about reputation and engagement.