Email Deliverability Test: Why Your Emails Land in Spam (And How to Fix It)

Your ESP says 97% of last month’s send was “delivered.” That number means the receiving server accepted the message. Accepted includes the spam folder. So 97% “delivered” can sit on top of a campaign where a big chunk of recipients never saw a thing, and the dashboard won’t tell you.

Then you run a test. Mail-tester says 10/10. A seed test says a third of your Gmail copies went to spam. A colleague’s Outlook shows it in Junk. Which one is lying?

None of them. An email deliverability test only answers one narrow question (is my DNS right, does my content trip a filter, where did copies land in a few test inboxes), and no single test measures where your real recipients’ mail lands. The fix is knowing which test answers which question, then fixing causes in the right order.

The deliverability test decoder

Screenshot this. It’s the whole post in one table.

The ranking is simple. Postmaster data and DMARC reports describe your real mail. Everything else is a lab test on one message.

Why your deliverability tests disagree

Three reasons, and they compound.

They run different filters. Mail-tester scores your message with a stock SpamAssassin install, and its own FAQ says it plainly: “What may pass in mail-tester, might not in your own office inbox.” A 10/10 there says nothing about Gmail’s model.

They check different layers. The MxToolbox test looks at headers, your outbound IP’s blacklist reputation and SPF. It doesn’t tell you whether the message reached an inbox. A green report and a spam-folder landing can both be true.

Seed panels don’t look like your list. In an Adobe community thread, a Marketo user was “getting significantly different results across the different platforms.” The answer they relayed from a deliverability consultant: a consumer-centric tool says little about a B2B list full of Outlook and Proofpoint users. MailReach sells exactly this gap, testing across Google Workspace and Office 365 inboxes instead of a handful of consumer accounts. Seed inboxes also have no history with you. Your real recipients do, and engagement is a big part of how they get filtered.

So when two tools disagree, trust the one closest to real recipients: Postmaster spam rate first, DMARC reports second, seed placement third, content score last.

Which tests matter for your kind of email

Most startups run three mail streams off one domain and test only one.

• Product email (password resets, receipts via Postmark, Resend or SES): low volume, high engagement. What breaks it is authentication, not content. DNS checks and DMARC reports are the tests that matter.
• Marketing and newsletters (HubSpot, Loops, Customer.io): this is where you cross bulk-sender thresholds and where spam complaints pile up. Postmaster Tools plus occasional seed tests.
• Founder cold outreach: the riskiest stream. B2B recipients sit behind Workspace and Microsoft filters, so consumer seed tests mislead. Test against Workspace and O365 inboxes, and keep it off the domain your receipts send from. A spam-complaint spike from outreach shouldn’t be able to take down password resets.

SPF, DKIM and DMARC in five minutes

This is the layer every other test sits on, and the one you can fully fix yourself.

SPF lists which servers may send mail for your domain. Two hard limits from RFC 7208: evaluation may use at most 10 DNS-querying terms (include, a, mx, ptr, exists, redirect), and going over returns permerror, so SPF can’t pass at all. Publishing two SPF records on the same name is also a permerror. Every SaaS tool that asks you to “just add our include” spends from that budget of 10.

Google gave some budget back. In December 2025 it flattened _spf.google.com from nested _netblocks includes into plain IP ranges, cutting Google Workspace’s cost from 4 lookups to 1, as URIports documented. I checked on 26 September 2026: dig TXT _spf.google.com returns a flat ip4/ip6 list, and _netblocks3.google.com now returns only v=spf1 ~all. If someone hard-coded the netblock includes into your record instead of using include:_spf.google.com, part of Google’s range may no longer be authorized.

DKIM signs each message with a private key; receivers fetch the public key from selector._domainkey.yourdomain.com and check the signature (RFC 6376). The RFC’s floor is 1024-bit keys. Google Workspace recommends 2048-bit if your DNS host supports it.

DMARC ties both to the address people actually see. Per RFC 7489, a message passes DMARC when SPF or DKIM passes and the domain it authenticated is aligned with the From: domain. Relaxed alignment (the default) accepts the same organizational domain, so news.example.com aligns with example.com; strict needs an exact match. The policy is p=none (monitor), p=quarantine (treat as suspicious) or p=reject. Add rua= and receivers send you aggregate reports, the best free deliverability data you’ll ever get.

Now the mailbox rules, as of September 2026:

Two things people get wrong. First, p=none is legal everywhere; you don’t need reject to pass the bulk rules (gmail.com itself published p=none when I checked on 26 September 2026). Second, alignment only needs SPF or DKIM. That matters because many ESPs send with their own bounce domain, so SPF passes but doesn’t align, and aligned DKIM is what carries you.

Why your emails land in spam

Roughly in order of how often they’re the culprit:

1. Broken or unaligned authentication. Fully fixable, and a hard failure at bulk volume.
2. Spam complaints. Gmail’s line is 0.3%, with 0.1% as the target (Google). Cold outreach blows through this fastest.
3. List quality. Hard bounces, dead addresses and spam traps drag reputation down. Remove hard bounces on the first bounce and suppress long-unengaged contacts.
4. Volume spikes. Going from near-zero to a full-list blast looks like a compromised account. Ramp new domains and IPs gradually.
5. Content and rendering. Broken HTML, link-heavy templates, image-only emails, a missing unsubscribe. Real, but usually the smallest lever. It’s also the only thing mail-tester is good at, which is why people over-index on it.

Silent breakage: re-test after any of these

The nasty failures happen weeks after you passed every test, when nobody’s looking. Keep this list next to your DNS provider login.

1. You added a new tool’s SPF include (count your lookups; 10 is the ceiling).
2. Someone published a second SPF record instead of editing the first.
3. Your record hard-codes _netblocks includes instead of include:_spf.google.com.
4. Your ESP rotated DKIM keys, or someone deleted an “unused” _domainkey record.
5. You migrated DNS hosts and not every TXT record came across.
6. You started sending from a new subdomain without DKIM, or with strict alignment set.
7. You moved DMARC to quarantine or reject before every sender was aligned.
8. You switched ESPs and the new one uses its own bounce domain, so SPF stopped aligning.
9. A support desk, billing or CRM tool started sending as your domain without authentication.
10. Your sending volume crossed 5,000 a day. Past that threshold, Microsoft expects all messages from your domain to meet its authentication rules, not just the bulk ones.

Every item here is a DNS or config change, not a content problem. A one-off test catches none of them unless you happen to run it the day after.

Fix order when you’re already in spam

1. Authentication. SPF under 10 lookups, DKIM at 2048-bit where possible, DMARC at p=none with rua= so you can see who’s sending as you.
2. Stop the bleeding. Pause cold outreach on the shared domain, remove hard bounces, suppress unengaged contacts.
3. Template hygiene. One-click unsubscribe headers plus a visible link, a text part, fewer links.
4. Rebuild slowly. Send to your most engaged recipients first and let the Postmaster spam rate settle before widening.
5. Monitor the DNS, not just the campaign. Most regressions come from the silent-breakage list above.

The monitoring gap is why RunAgents watches SPF, DKIM, DMARC and blacklist status on your sending domains and alerts you in Slack, Discord, Telegram or email in real time when a record breaks, next to the SEO, AI-search and competitor signals it already tracks (and your agents can query it over MCP, see the MCP servers marketing teams actually use). If a DKIM rotation or a tenth include ever takes down your receipts, you’d rather hear it from an alert than from a customer. Set up email auth monitoring on your domain.