Why are my emails going to spam? A diagnostic walkthrough

Emails go to spam for a short list of reasons, and most guides check them in the wrong order. As of August 2026, the causes ranked by real-world likelihood are: broken reverse DNS (PTR), failed or misaligned SPF/DKIM/DMARC, a spam complaint rate above Google's ceiling, a domain with no sending history, a bad recipient list, content signals, and sudden volume spikes. The single largest driver of Gmail rejections during the late-2025 enforcement ramp was a missing or mismatched PTR record — an infrastructure detail almost no checklist mentions. Work down the list in order; every cause below comes with a concrete check and a concrete fix.

First, confirm it actually went to spam

Three different outcomes get conflated. Your ESP saying "delivered" only means the receiving server returned SMTP 250 OK — it says nothing about inbox versus spam folder versus silently discarded. And Gmail's Promotions tab is not the spam folder: mail there passed the trust check and was categorised as commercial.

Check: run a seed test. Send the real message to accounts you control at Gmail, Outlook, and Yahoo, and note where it lands at each. Only diagnose what a seed test confirms — a "spam problem" that turns out to be Promotions placement needs none of the fixes below.

The diagnostic order

#	Cause	60-second check	Fix
1	Missing/mismatched PTR	dig -x <sending IP>, then resolve the result forward	IP owner (host or ESP) sets PTR; verify both directions, incl. IPv6
2	Authentication failing or unaligned	Gmail "Show original" → Authentication-Results	Align DKIM d= or SPF domain with your From domain; publish DMARC
3	Spam rate over 0.30%	Postmaster Tools spam-rate dashboard	Stop the offending segment; fix one-click unsubscribe
4	No sending history	whois creation date; any prior consistent volume?	Warm the domain up before real volume
5	Bad list / spam traps	Bounce breakdown: clusters of 550 5.1.1	Verify addresses; purge by acquisition source
6	Content signals	Seed-test a stripped-down copy of the same message	Plain-text part, clean link domains, less image-heavy HTML
7	Volume spike	Deferrals: 421 4.7.28, [TSS04], 451 4.7.650	Hold below trigger volume 24 h, then ramp 25–100%/day

1. Reverse DNS (PTR) — the cause almost nobody checks

Nearly every compliance checklist covers SPF, DKIM, DMARC, and the spam-rate ceiling. Almost none cover reverse DNS — and the data says reverse DNS is the bigger problem. Google began exposing SMTP rejection data inside DMARC aggregate reports around July–August 2025, and when Al Iverson and Scott Ziegler analysed that corpus across the Black Friday 2025 period, the largest single driver of rejections was not authentication at all but sending IPs with broken or missing PTR records. By their account, Gmail alone rejected "tens of millions of messages in a matter of weeks" for this one reason, after enforcement of the 550 5.7.25 rejection turned aggressive in December 2025:

550-5.7.25 The IP address sending this message does not have a PTR record
550 5.7.25 setup, or the corresponding forward DNS entry does not match
the sending IP.

This bites senders who did everything else right because the PTR record lives with whoever owns the IP — your VPS provider, cloud host, or ESP — not in your domain's DNS zone. Nothing in your SPF, DKIM, or DMARC setup surfaces it, so a domain can pass every authentication checker and still be hard-rejected.

Check: Gmail's requirement is forward-confirmed reverse DNS (FCrDNS), which has three parts — the IP has a PTR, the PTR's hostname has an A/AAAA record, and that record points back to the same IP:

dig -x 203.0.113.25 +short    # → mail.example.com (must not be empty)
dig mail.example.com +short   # → must return 203.0.113.25

If you send over IPv6, repeat both steps for the IPv6 address — a missing IPv6 PTR is a very common partial failure.

Fix: ask the IP's owner to set the PTR. On a VPS or cloud host that's a control-panel setting or a support ticket; on a managed ESP such as Resend, SendGrid, or Postmark, the sending IPs are theirs and the PTR is their job — this failure mode mostly hits self-hosted senders and misconfigured dedicated IPs. Full details in our PTR record guide, and re-check after any infrastructure change: this is the record that silently breaks.

2. Authentication — and Microsoft's stricter-than-DMARC rule

Since 2024, unauthenticated mail is rejected outright at Gmail with 550 5.7.26 — SPF or DKIM is mandatory, not advisory. The subtler failure is alignment: dkim=pass header.d=sendgrid.net on mail sent from you@yourdomain.com is a pass that does not align, and DMARC still fails.

Check: send a test to a Gmail account, open it, choose Show original, and read the Authentication-Results header. You want spf=pass, dkim=pass, dmarc=pass — and the domain each result names should be your From domain, not your ESP's. To verify the DNS records themselves, run your domain through our free domain checker.

Then check which provider is filtering you, because the rules differ. DMARC passes if either aligned SPF or aligned DKIM passes. Microsoft broke that either/or rule: since May 5, 2025, senders of 5,000+ messages per day to Microsoft consumer domains (outlook.com, hotmail.com, live.com, msn.com) must pass SPF and DKIM and publish DMARC, or mail bounces with 550 5.7.515. Because the requirement only kicks in above the threshold, mail that has been fine at Gmail for months can start bouncing at Outlook the day your volume crosses it.

Fix: SPF under 10 DNS lookups with no +all; DKIM signing with a key whose d= matches your From domain; DMARC published at p=none minimum. Verify by reading Authentication-Results on a real received message, not just with a checker tool.

3. Your spam complaint rate crossed Google's line

Google's sender guidelines publish two numbers: keep the spam rate below 0.10%, and never reach 0.30%. Note the definition: the rate is the share of messages delivered to engaged recipients' inboxes that those recipients then mark as spam — mail already going to the spam folder can't be complained about, so a "stable" rate can mask a worsening problem.

Check: the spam-rate dashboard in Google Postmaster Tools. Low-volume senders often see blank charts, which itself tells you that you're below Google's reporting threshold. Our Postmaster Tools guide covers setup and what each chart means.

Fix: stop the stream that generated the complaints and suppress the whole segment, not just the individual complainers — if one segment complains at 0.5%, the rest of it will too. Verify one-click unsubscribe actually works (List-Unsubscribe plus List-Unsubscribe-Post); a large share of complaints come from people who couldn't find another way out. Then resume at low volume to your most engaged recipients. The spam rate itself responds within days; the filtering consequences lag it by weeks — no provider publishes exact recovery curves, so treat any confident timeline as folklore.

4. No sending history: new domains start guilty

A brand-new domain has no reputation, and no reputation is not neutral. Google's spam models explicitly target "messages from newly created domains attempting to disguise low-volume spam within legitimate traffic" — which is exactly the shape of a legitimate fresh domain sending its first campaign. Your first sends are your baseline: a cold-start blast with the bounce and complaint rates typical of an unproven list becomes the first impression every later send is judged against.

Check: whois yourdomain.com | grep -i creation. If the domain is weeks old, or has never sent consistent daily volume before, missing history is your explanation — no error code will say so.

Fix: warm the domain up before it carries real volume. Google's own guidance is to start with a low volume to engaged users and increase slowly — our warm-up walkthrough covers the schedule in detail. This is the problem WarmEnvelopes automates: gradual daily sends from your domain, through your own Resend account, to inboxes you control — building real history without faked engagement. Warmup builds a track record; it does not guarantee inbox placement, and it cannot compensate for a bad list.

5. List quality and spam traps

The bounce composition of one campaign tells you which problem you have. Clusters of 550 5.1.1 at Gmail or 554 delivery error: dd at Yahoo mean invalid addresses — a list problem. Deferrals like 421 4.7.0 [TSS04] mean a reputation problem. Same campaign, completely different remediation.

Check: pull the raw bounce strings from your ESP's webhook or event detail — dashboard summaries like "Blocked" destroy the diagnostic information. Then look up both your sending IP and your domain in the Spamhaus IP & Domain Reputation Checker; a domain listing (DBL) follows you across IPs and ESPs, so the distinction matters.

Fix: verify addresses before first send, and record where each address came from. If you hit a spam trap — Spamhaus will rarely tell you which address — purge by acquisition source, not by address: a purchased list that hit one pristine trap is contaminated throughout. Sunset recipients who have stopped engaging before their addresses can be recycled into traps. And if you're blocklisted, delisting via Spamhaus is self-service and never costs money — any site charging for it is a scam.

6. Content — the honest answer on "spam trigger words"

Word lists are mostly folklore, and the evidence is public. In SpamAssassin's published rule weights, the classic ALL-CAPS subject line scores 0.5 points against a 5.0 threshold, while a Spamhaus PBL listing scores 3.558 and a near-certain Bayes verdict 3.8. The heavy weights sit on reputation and statistics, not vocabulary. Bayesian and ML filters have no built-in word list at all — a token's spamminess is learned from each installation's (and at Gmail, each user's) mail. Laura Atkins has been debunking the "FREE" myth for a decade, and Litmus quotes Gmail's own anti-spam team pointing senders at user value, not word choice.

What is documented to matter: the reputation of the domains you link to (a blocklisted link domain poisons an otherwise clean sender — Atkins documents Gmail bulk-foldering mail purely for a domain mentioned in the body), a missing plain-text alternative, image-heavy HTML with little text, and structural red flags — Microsoft's ASF settings can treat forms, iframes, and scripts in HTML as high-confidence spam on structure alone.

Check: seed-test a stripped-down version of the same message — plain text, minimal links — to the same addresses. If the stripped version inboxes and the original doesn't, you have a content signal worth isolating (usually a link domain or the HTML weight).

Fix: send multipart/alternative with a real text part, link only to domains with clean reputations (skip URL shorteners — you share their reputation with every other user), and keep HTML modest. Do not waste effort rewording copy to dodge a word list: when content is the tiebreaker, it's because reputation was already marginal.

7. Volume spikes

Rate limits key on deviation from your own history, not on absolute volume. The signatures: 421 4.7.28 at Gmail, 421 4.7.0 [TSS04] at Yahoo, 451 4.7.650 at Microsoft — all deferrals clustering at one provider right after a step up in volume.

Check: compare deferral timestamps against your send log; if they start at a consistent volume level, you found your ceiling.

Fix: Google publishes an exact recovery protocol: stop for 15 minutes, send one test message, hold below the trigger volume for 24 hours, then grow 25–100% per day — and pace sends steadily (Google's example: one message per second, not bursts of 60). Do not retry harder: sustained 4xx deferrals are worse than a clean rejection, because your queue fills while your dashboard shows nothing bounced.

If every check passes

Isolate the variable: send the same message from a clean domain. If it inboxes, the problem is your sender identity; if it doesn't, it's content or the recipient's side. For B2B recipients, remember that corporate gateways (Proofpoint, Mimecast, Barracuda) return 250 OK and then quarantine silently — there is no bounce to read, and their reputation databases are independent of Gmail's. Their scanners also fetch images and follow links within seconds of delivery, so opens and clicks from enterprise domains are unreliable; count replies instead.