How to test email deliverability?

Testing email deliverability in 2026 means answering three separate questions: does your mail authenticate correctly, does it reach the inbox and not the spam folder, and does it get engaged with once delivered. All three matter, and testing only the first (as most tools do) will give you a false sense of safety. This guide walks through a repeatable test procedure that covers all three, using free tools and standard mail platforms.

Stage 1: Authentication check

Before sending a single test message, verify your domain's authentication posture. Open IntoDNS.ai and run a scan on your sending domain. You want to see:

• SPF record present, syntactically valid, under 10 DNS lookups, and ending in ~all or -all.
• DKIM signatures discovered on at least one selector (often default, google, s1, or a vendor-specific name), with 2048-bit keys.
• DMARC record at _dmarc.yourdomain, minimum policy p=none with rua=mailto: reporting configured.
• MTA-STS policy published and reachable at https://mta-sts.yourdomain/.well-known/mta-sts.txt.
• No blocklist hits on the sending IP.

If any of these fail, fix them before moving on. Deliverability testing on top of broken authentication is wasted work.

Stage 2: Seed list inbox placement test

A seed list is a set of email addresses you control across every major provider: Gmail, Outlook.com, Yahoo, iCloud, and at least one corporate Microsoft 365 tenant and one Google Workspace tenant. Sending to these addresses and checking inbox vs spam placement is the only reliable way to know where mail is actually landing, because no public API reports this.

Minimum viable seed list (free tier):

[email protected]        (personal Gmail)
[email protected]    (personal Outlook.com)
[email protected]        (personal Yahoo)
[email protected]      (personal iCloud)
[email protected]  (Google Workspace throwaway)
[email protected] (Microsoft 365 throwaway)

Send the exact same message your production system would send — same subject, same body, same From address, same list — through your production ESP to this seed list. Wait five minutes. Check each inbox manually. Record where the message landed (inbox, spam, promotions tab, quarantine).

Stage 3: Header inspection

For each seed address, open the message and look at the full source. You are checking five things in the headers:

1. Authentication-Results — should show spf=pass, dkim=pass, dmarc=pass.
2. DKIM-Signature — present, d= domain matches or aligns with From:.
3. Return-Path — should align with From: (if not, SPF will not help DMARC).
4. Received — trace the hops; each should be a server you recognise.
5. X-Spam-Status / X-Spam-Score — if present, shows the receiver's actual score and the rules that fired.

A message can pass SPF and DKIM and still fail DMARC due to alignment. The Authentication-Results line will tell you exactly which check failed:

Authentication-Results: mx.google.com;
  dkim=pass [email protected] header.s=default;
  spf=pass (google.com: domain of [email protected] designates 1.2.3.4 as permitted sender);
  dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

In this example SPF and DKIM technically pass, but spf aligns with mg.example.com and dkim is on @example.com — if d= is mg.example.com (vendor's domain), DMARC alignment fails.

Stage 4: Reputation monitoring

Inbox placement is a snapshot. Reputation is the trend. Three free tools cover most of what you need:

Google Postmaster Tools — register your domain, add a DNS TXT proof, wait 24 hours for data. You get per-day domain reputation (High/Medium/Low/Bad), IP reputation, spam rate, feedback loop complaints, and delivery errors. Target: domain reputation High, spam rate below 0.1%.

Microsoft SNDS (Smart Network Data Services) — register your sending IPs. Free but requires manual approval. You get per-IP spam rate, trap hits, and complaint rate from Outlook.com/Hotmail.

Yahoo Sender Hub — now the standard replacement for Yahoo's older CFL. Provides aggregate delivery data for mail sent to Yahoo, AOL and associated properties.

Stage 5: DMARC aggregate report analysis

If you configured rua=mailto: in your DMARC record (and you should), every receiver that honours DMARC sends you a daily XML report listing every IP that sent mail claiming to be your domain, whether SPF and DKIM passed, and whether DMARC aligned. These reports are unreadable as XML but essential.

Parse them with any DMARC report parser (there are several open-source ones, for example OpenDMARC's tooling). Look for:

• Unknown IPs sending mail as your domain (shadow IT or spoofing).
• Your own services failing alignment (misconfigured SaaS platforms).
• High-volume failures that indicate a broken signing chain.

Stage 6: Content and engagement testing

Once auth, placement and reputation are clean, test the content itself. A/B test subject lines against the seed list to see if any trigger spam filters. Check that:

• Text-to-HTML ratio is balanced (at least 50 words of real text for every 10 links).
• No URL shorteners (bit.ly, t.co, goo.gl) in the body.
• Links resolve over HTTPS.
• No mismatched display text vs href.
• Unsubscribe link and one-click List-Unsubscribe header present.
• From name and address match (no "Support" from random @mail.com).

Automating the test

A reasonable cadence for an active sender:

• IntoDNS.ai authentication scan: daily, automated.
• Seed list send and manual check: weekly.
• Postmaster Tools / SNDS review: weekly.
• DMARC aggregate report parse: daily, automated.
• Blocklist check on sending IPs: hourly, automated.

Common mistakes

Testing only with your own inbox. Your own mail always looks fine because you have a direct relationship and high engagement with yourself.

Testing with brand-new email addresses. Providers give new addresses temporarily lenient treatment. Use aged seeds.

Sending from a different volume or pattern than production. If production sends 50,000/day and your test is 10 messages, you are not testing what matters.

Ignoring the promotions tab. In Gmail the promotions tab is technically "inbox" but most users never see it. If transactional mail lands there, treat it as a placement failure.

When to use IntoDNS.ai

IntoDNS.ai covers stage 1 (authentication) and parts of stage 4 (blocklists) in a single scan with plain-English explanations. It is the fastest way to eliminate technical causes before you spend time on seed lists, Postmaster Tools registration and DMARC report parsing. Start every deliverability investigation here.

A reference test plan

For a commercial sender wanting a reliable quarterly deliverability health check, a reasonable test plan looks like:

1. Run IntoDNS.ai scan on primary sending domain and every subdomain used for mail. Fix any failures.
2. Register or confirm Google Postmaster Tools, Microsoft SNDS and Yahoo Sender Hub. Confirm seven days of data available.
3. Send a representative production message (transactional template, marketing template, and a "hot" urgent-style message) to a 25-address seed list covering Gmail personal, Gmail Workspace, Outlook.com, Microsoft 365, Yahoo, iCloud and Fastmail.
4. Record inbox vs spam vs promotions vs quarantine placement for each seed.
5. Inspect headers for Authentication-Results and note any partial-pass patterns.
6. Pull DMARC aggregate reports from the past 30 days. Calculate percentage of failing alignment. Target: under 2%.
7. Check blocklist status on all sending IPs and all domains used in mail links.
8. Review Google Postmaster domain reputation trend for 30 days.
9. Test TLS handshake against all MX hosts.
10. Spot-check MTA-STS and TLS-RPT reachability.

This takes about 90 minutes and catches almost everything that can go wrong before it affects real recipients. Automating the parts that can be automated (IntoDNS.ai scan, DMARC parsing, blocklist checks) cuts ongoing effort to about 20 minutes per quarter after initial setup.