How to test email deliverability before launch: the tools, what each one checks, and what a pass looks like

Test three things, not one score: send a real message from the app to a Gmail, an Outlook and a Yahoo mailbox and read the headers, run one scoring tool over the same message, and look the sending domain and IP up on the blocklists. That is how to test email deliverability before launch: three results, written down with a date.

What an email deliverability test measures, and what it cannot

An email deliverability test samples 3 things: whether the message authenticates as your domain, what reputation the sending domain and IP carry, and how a content filter scores the message. Tools can see the first fully, the second partly and the third well. None can predict placement for a real customer next month.

Testing is one part of the wider work of how to improve email deliverability; this page stays on the test itself.

Delivered and in the inbox are two different events. When your email provider marks a message delivered, the receiving server has accepted it. That server then makes a second decision on its own: the inbox, a tab, or the spam folder. A deliverability test is a sample of that second decision, taken by you, on a day you choose.

What no test tells you is where next month’s message lands for a real customer. Reputation moves with every send, so I treat every pass as a dated sample, never a promise. The sample also has to be the right message. To check deliverability of email your app sends, the test message has to be the app’s own message from the production sending domain, never a note typed into a mail client.

Why it matters before launch: the first emails are the ones that cannot fail

The first message a new customer gets is a verification or welcome email, sent from a domain with no sending history. If it lands in spam, the signup is lost and nothing records an error. The provider says delivered, the app says sent, and the customer says nothing at all.

The big mailbox providers publish what they expect. Google’s email sender guidelines require every sender to Gmail accounts, since February 1, 2024, to set up SPF or DKIM and to keep the spam rate reported in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to Gmail accounts must also set up SPF, DKIM and DMARC and, for direct email, align the From domain with either the SPF domain or the DKIM domain; Google’s guidance aims lower still, below 0.10%, and says to avoid ever reaching 0.30%. Yahoo’s sender best practices ask all senders for SPF or DKIM at a minimum and a spam rate below 0.3%, and ask bulk senders for both SPF and DKIM plus a valid DMARC policy of at least p=none, with enforcement from February 2024.

A new domain has no reputation, good or bad. So the before-launch test is mostly about authentication and content, the two layers you control. Recovery is a separate job: once real customers report transactional emails landing in spam, the order of work changes.

None of this means your setup is broken. A first run that fails a check is normal, and in my working estimate the fix is usually about an afternoon of DNS or template work.

How to test email deliverability, step by step

Email deliverability is tested in 5 steps: send the app’s real messages to mailboxes you control and read the headers, score one message with a free tool, run a small seed test across providers, look the domain and IP up on the major blocklists, and keep address verification as a separate job.

The steps come from the mailbox providers’ sender documentation and each tool’s own description, read on 2026-10-04; nothing below reports a test I ran. The first three checks (the real send, the score, the blocklist lookup) take about an hour in my working estimate.

Send a real message from the app and read the headers

A real send is checked in the raw message, not the inbox view. The Authentication-Results header should show dmarc=pass, which needs SPF or DKIM to pass for a domain that matches your From address. A dkim=pass with your own domain in header.d is the usual aligned pass.

The browser-only way to check email deliverability is to make the app send its real messages to mailboxes you own, then open each one at the source.

1. 01 Create or reuse three mailboxes you control: Gmail, Outlook.com and Yahoo Mail. Add a Google Workspace and a Microsoft 365 address if your customers are companies.
2. 02 From the production app, trigger each critical message (verification, password reset, receipt, invite) to each mailbox.
3. 03 Note where each message landed (inbox, a tab or spam) and how long it took to arrive.
4. 04 Open the raw message. Gmail: More, then Show original. Outlook.com: More actions, then View, then View message details. Yahoo Mail: the More options icon, then View Raw Message.
5. 05 Find the Authentication-Results lines and read the spf, dkim and dmarc results against the table below.
6. 06 Save the raw headers as a text file named for the message, the mailbox and the date. That file is your evidence.

The click paths come from Gmail’s help on viewing the original message and each mailbox’s own help pages, and the header itself is defined in RFC 8601, the Authentication-Results header. Microsoft 365 can print dmarc=bestguesspass, which Microsoft uses when the domain has no DMARC record but would pass if it had one.

An illustration with example domains, not a real message, of what the three passing lines look like:

Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounces.provider.example;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Every fix for a failing line is DNS work that belongs to SPF, DKIM and DMARC setup.

The app’s own message matters because only a real send shows what the template renders. One CRM I audited stored raw placeholders in its email templates when a template was picked before the contact, a fault no typed note would ever show and one reason to read the raw source of an email verification email template before launch. A note typed into a mail client tests your mailbox, and only a triggered send tests your app’s message. The provider’s record of the same send (accepted, delivered, bounced) sits with transactional email best practices, and the two records should agree.

Check email deliverability free with a scoring tool

A free scoring tool gives you a one-time address, receives your app’s real message and scores 5 things: authentication, a SpamAssassin run, blocklist lookups, links and HTML structure. Fix authentication findings first. One score is one filter’s opinion, so it is a step, not the verdict.

One example is mail-tester. It generates a random address each time you open the page; you send to it, click “Check your score”, and get a mark whose goal is a perfect 10/10. Its FAQ allows 3 free tests within 24 hours and describes its SpamAssassin as “an out of the box default installation”. MailGenius works the same way: copy the address it gives you, send to it, and see your score.

To get the app’s real message to that address, sign up a test account whose email is the tool’s address, or set the tool’s address on a test user and trigger a password reset. A pasted copy of the template skips the app’s own rendering, so the score would describe a different message.

Read the result in order. Fix anything about authentication first, then the content warnings that are true of your template. Skip advice written for newsletters. Google’s one-click unsubscribe rule, for example, names “Marketing messages and subscribed messages”, not password resets. A pass is the tool’s top band with no authentication warning, recorded with the date. Scoring is step two for that reason: one filter cannot speak for Gmail or Outlook.

Run a seed test across mailbox providers

A seed test sends one message to a list of mailboxes at many providers and reports inbox, tab or spam for each. Paid and freemium inbox placement services sell this: GlockApps offers 2 free tests before a paid plan, MailReach offers a free spam test, and EasyDMARC’s free inbox tester reports Inbox, Spam or Promotions placement across providers but says it does not analyze authentication, domain reputation or content. I name them as types of tool, not as picks.

The do-it-yourself version is the three to five mailboxes from the first step. Its limits are real. A handful of fresh test mailboxes are not your customers, they carry no engagement history, and a company’s Microsoft 365 tenant applies its own rules on top of Microsoft’s. For a transactional sender, I consider the do-it-yourself list enough before launch, and a paid seed test worth its price once volume is real and placement differs by provider.

Some providers also publish test addresses that simulate outcomes without touching a real mailbox. Resend’s test email addresses are delivered@resend.dev, bounced@resend.dev, complained@resend.dev and suppressed@resend.dev, and Resend asks you not to send to fake addresses instead. Those addresses test how your app handles each event, not where mail lands. The per-provider bounce test is part of an email bounce handling checklist.

Blacklist, spam-score and reputation checkers: which tool answers which question

Deliverability tools answer 7 different questions: are the DNS records valid, did this message authenticate, how does a filter score it, is the IP or domain blocklisted, what does Gmail think of the domain, what does Outlook think of the IP, and what spam confidence level did Microsoft 365 stamp on it.

A blacklist checker service queries public blocklists, and Spamhaus’s blocklists are the main example: SBL for malicious network ranges, XBL for compromised IPs, PBL for non-mail IPs, DBL for low-reputation domains, CSS for spam-sending IPs, and ZEN combining PBL, SBL and XBL. Lookups and removals go through its IP and Domain Reputation Checker; for an SBL listing, you ask your ISP’s abuse team to contact Spamhaus for removal. On a shared sending IP, that in practice makes the delisting your email provider’s job.

Google Postmaster Tools shows spam rate, reputation, authentication and delivery errors, but only for a domain you have verified with a TXT or CNAME record, and it shows no data for a day when the total number of messages is too low. Microsoft SNDS gives data about individual IPs and junk reports, and you request access to the IPs you are responsible for, so it helps only on a dedicated IP.

A spam confidence level checker is any tool that reads Microsoft’s X-Forefront-Antispam-Report header, where Microsoft 365 stamps the SCL value, including Microsoft’s own Message Header Analyzer. Microsoft’s spam confidence level reference says the value no longer decides the verdict or the action in cloud organizations, so read the CAT field beside it.

For a transactional sender, I’d narrow the best email deliverability tools down to four: the mailbox’s raw headers, one scoring tool, one blocklist lookup, and Postmaster Tools once volume allows. Most of the rest solve marketing-list problems.

Check email address deliverability is a different job

Checking an email address and checking your deliverability are two different jobs. Address verification asks whether a mailbox exists, and bulk verifiers sell it for marketing lists. An app proves an address by sending a verification email and suppresses the ones that hard bounce.

An address verifier checks the format, the domain’s MX records, whether an SMTP server accepts the address, whether the domain accepts everything (catch-all), and whether the address is disposable. Bulk verification services such as ZeroBounce, Hunter, Verifalia and Kickbox run those checks over a whole list before a campaign. Hunter’s verifier has a Free plan with a monthly cap, so bulk email verification for free works at small volume.

An app with signups does the same job differently. A syntax and MX check runs at the form, and for an app the best email verification tool is the verification message itself: knowing how to send a verification email matters more than any verifier, because a clicked link proves the address works. The wording of that message belongs to the verification email template, and hard bounces feed a suppression list as part of bounce handling. Never buy or scrape a list to test with. I’d run a bulk verifier once, before mailing an old user table that was never verified.

How to check your own app: what a pass looks like

A deliverability pass before launch is 6 checks: every critical message reaches the inbox or a tab at Gmail, Outlook and Yahoo, the headers show dmarc=pass, a scoring tool reports its top band, no major blocklist lists the sender, the provider’s log shows each send, and a DMARC record is published.

Run each check on the production sending domain. Each one can fail.

1. 01 Every critical message type, sent from production, reaches the inbox or a tab at all three consumer mailboxes. Fail: any one in spam.
2. 02 Each raw header shows dmarc=pass with an aligned DKIM or SPF pass. Fail: dmarc=fail, or dmarc=none because no record is published.
3. 03 The scoring tool reports its top band with no authentication warning.
4. 04 The sending domain, and the IP if it is dedicated, appear on none of the major blocklists.
5. 05 The provider log shows each test message as delivered, matched by recipient and send time.
6. 06 A DNS lookup shows a DMARC record published for the sending domain.

The policy value on that DMARC record is a separate decision that ties into how to stop email spoofing. Keep the evidence together: a pass record like the one below, the raw headers as text files, the scoring tool’s result link or PDF, and the date.

Re-run the record after any change of email provider, sending domain, DNS host or template. While volume is too low for Postmaster Tools to show data, I re-run it about monthly.

This is how the Production Hardening Sprint checks its email work: deliverable 11.1 is verified this way: “Inspect DNS and received message headers for the configured authentication results” , and deliverable 11.2 is verified this way: “Trigger each critical message type and confirm provider records and expected recipient delivery”.

Where the sprint fits

In the Production Hardening Sprint, deliverable 11.1, Sending-domain authentication, is where we verify and configure SPF, DKIM, and DMARC for the transactional sending domain ; in 11.2, Transactional delivery tracking, we configure a dedicated transactional provider with delivery tracking for account and transaction messages ; in 11.3, Bounce and complaint handling, we process bounces and complaints and suppress further sending where appropriate. The production readiness report, deliverable 13.1, gives the result for every scope item, the work completed, and its verification evidence. Hosting, paid tools, and API usage remain in your accounts. Each item is listed in the published scope, area 11.

Common questions about deliverability testing

How to test email deliverability without sending email?

Only the DNS layer can be tested without a send: a domain checker such as Hunter’s reads your SPF, DKIM, DMARC and MX records from the domain name alone. Alignment, content scoring and placement all need a real message. The same words are also used for address verification, which checks whether someone else’s address exists and does nothing for your own sending.

What is the spam threshold score?

SpamAssassin’s default threshold is 5: its required_score setting is “the score required before a mail is considered spam”, with “(default: 5)”. SpamAssassin’s configuration reference calls 5.0 “quite aggressive” and suggests 8.0 or 10.0 for an ISP. A Gmail spam score threshold is not stated in Google’s sender guidelines, and Microsoft’s SCL is a different scale.

What does a spam confidence level of 9 mean?

SCL 9 is the top of Microsoft’s scale, which runs -1 and then 0 to 9; Microsoft says an SCL of 5 or higher generally indicates the message is considered bad. In Microsoft 365 cloud mailboxes the value no longer decides whether a message is spam or what happens to it; there, the primary use of SCL is mail flow rules, where a rule that sets SCL 9 treats a message as high confidence spam, and the CAT field shows what actually filtered it. On an on-premises Exchange server, the defaults reject at SCL 7 or higher and move SCL 5 or higher to the Junk Email folder.

How to monitor email deliverability?

After launch, monitor your email provider’s bounce and complaint rates, add Google Postmaster Tools once the domain is verified and sends enough mail for data to appear, and re-run the real send to your own mailboxes about monthly. Rising bounces are a bounce handling problem first, and a rising spam rate in Postmaster Tools is the signal to re-run every check above.

Can I do email verification for free?

Yes, for a small number of addresses: Hunter’s Free plan, for one, lets you verify up to 100 email addresses a month. An app with signups needs no verifier for that, because the verification email it sends is the check.