Why Your Signup and Password-Reset Emails Land in Spam (and How to Fix It)

Signup emails going to spam almost always come down to one of six causes: a shared IP with bad neighbors at your ESP, a brand-new domain with zero reputation, a DMARC alignment mismatch from your ESP setup, missing reverse DNS, a flagged link/tracking domain, or a template that trips content filters. The fix is systematic: confirm the email actually left your infrastructure, identify which layer failed, then work the ranked suspect list below.

This is written for the moment a user types "I never got the email" into support chat and you have no idea where to start.

First: Is It Actually Spam, or Was It Never Sent?

Before you touch a single DNS record, you need to know which of three different problems you have. People use "not delivered" for all of them. They are not the same.

1. Sent — your application handed the email to your ESP and the ESP accepted it. Check your ESP's event log or webhook feed. If there's no accepted/processed event, the problem is in your code, queue, or API key — not deliverability.

2. Delivered — the recipient's mail server (Gmail, Outlook, the corporate MX) accepted the message with a 250 OK. Your ESP will show this as delivered. Important: "delivered" only means the MX took it. It says nothing about inbox vs. spam folder.

3. Placed — where the message actually landed: primary inbox, Promotions, spam, or silently dropped after acceptance (yes, that happens — Gmail can accept a message and then discard or junk it based on its own filtering).

The trap: you see delivered in the ESP dashboard, tell the user "our side says it was sent," and stop investigating. The user is still right — the email is in their spam folder, or gone.

So your first diagnostic step is always:

1. Open your ESP's event log for that exact recipient and timestamp.
2. If there's a bounce or deferral — read the SMTP response code. A 550 5.7.1 from Gmail is a policy rejection, not a "try again later." Since November 2025, Gmail rejects non-compliant bulk senders with hard 5xx errors instead of deferring, and Microsoft has done the same since May 2025.
3. If it shows delivered — you have a placement problem. That's the rest of this article.

Try it: Send your actual signup email to a free test address at willitinbox.com/test — you'll see authentication results, content flags, blacklist status, and a 0–100 score with prioritized fixes in about 15 seconds.

The Usual Suspects, Ranked by How Often They're the Cause

After watching hundreds of transactional streams break, this is roughly the frequency order for a SaaS product:

1. Shared IP Reputation at Your ESP

If you're on a shared sending pool (the default on most ESP free and low tiers), your reputation is pooled with every other sender on those IPs. One spammy neighbor running a cold-outreach blast can drag the whole pool's Gmail placement down for days.

Symptoms: deliverability degrades suddenly without you changing anything; some domains (Gmail) get worse while others stay fine; your own authentication is perfect.

Check: ask your ESP which pool you're on, and look at your placement split by mailbox provider. If Gmail placement is bad but your setup is clean, the pool is the prime suspect.

Fix: a dedicated IP makes sense past ~50k/month — but under ~10k/month it's often worse than a good shared pool, because receivers can't build a reputation signal on tiny volume. At low volume, the better answer is an ESP with a tightly-policed transactional stream.

2. New Domain With No History

A domain registered last week has no reputation — and in 2026, "no reputation" is treated closer to "suspicious" than "neutral." Yahoo moved to domain-reputation-first filtering in April 2025, and Gmail weights domain history heavily.

New domains sending verification emails in bursts (launch day, a Product Hunt spike, a viral TikTok) look exactly like a spam operation ramping up. Volume spikes on a young domain are the single fastest way to land in spam.

Fix: you can't shortcut domain age, but you can avoid making it worse. Ramp volume gradually over 2–4 weeks (see /blog/ip-warming-schedule — the same logic applies to domains). Keep complaint rates under 0.1% and never above 0.3% — that's Gmail's published ceiling, and they mean it.

3. DMARC Alignment Mismatch From Your ESP Setup

This is the most common technical cause and the most invisible one. Your ESP says "add these CNAMEs," you add them, their dashboard shows green checkmarks — and your email still fails DMARC alignment.

Here's why it happens: SPF and DKIM can both pass while DMARC fails, because DMARC requires alignment — the domain in your visible From: header must match (or share an organizational domain with) the domain that passed SPF or DKIM.

Classic failure pattern:

From: [email protected]
Return-Path: [email protected]     ← SPF passes for yourresp.com
DKIM d=youresp.com                          ← DKIM passes for yourresp.com

SPF: pass. DKIM: pass. DMARC: fail — neither authenticated domain aligns with yourapp.com. Since the major providers started hard-failing DMARC, this gets you rejected or junked.

Fix: set up a custom return-path (usually em.yourapp.com or similar via CNAME) and a custom DKIM signing domain (d=yourapp.com) at your ESP. Every mainstream ESP supports both; it's usually two or three DNS records. Then publish a DMARC record, even if it's just monitoring-mode:

_dmarc.yourapp.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Verify with the free SPF checker and DMARC checker, and read /blog/spf-dkim-dmarc-explained if the alignment concept is new — it's the thing that bites everyone exactly once.

4. Missing PTR / Reverse DNS

Every sending IP should have a PTR record, and it should forward-confirm: PTR → hostname → A record → same IP. This is called FCrDNS, and some receivers (older corporate gateways, some regional providers) still reject outright without it.

If you're on a reputable ESP's shared pool, this is handled for you — skip it. If you're self-hosting Postfix, running on a cloud VPS, or on a dedicated IP you just provisioned, check it:

dig -x 203.0.113.10 +short
# should return something like mail.yourapp.com
dig mail.yourapp.com +short
# should return 203.0.113.10

Cloud providers require you to request PTR setup explicitly (and GCP blocks outbound port 25 entirely by default). A missing PTR on a fresh VPS is a near-guaranteed spam-folder ticket.

5. Link and Tracking Domain Reputation

Your email can be perfectly authenticated and still get junked because of what's inside it. Receivers extract every URL in the body and check each domain against their own reputation systems and public blocklists like SURBL and Spamhaus DBL.

The usual culprits in onboarding emails:

• Your ESP's shared click-tracking domain. That click.youresp.com wrapped around your links shares reputation with every other customer. If it gets flagged, your links get flagged.
• URL shorteners. bit.ly, t.co-style generic shorteners in a verification email are a strong spam signal. Never use them in transactional mail.
• Link-text mismatch. Anchor text says https://yourapp.com/verify but the actual href points somewhere else. Filters treat this as a phishing pattern.
• A link to your own young domain. See suspect #2 — it compounds.

Fix: configure a branded link domain at your ESP (links.yourapp.com), use plain full URLs or honest anchor text, and run a blacklist check on every domain that appears in your template — including the tracking domain.

6. Template Issues in Onboarding Emails

Content filtering matters less than it did in 2015, but it's not zero — and transactional templates have specific anti-patterns:

• Image-heavy welcome emails. A big hero image, three social icons, a logo — and twelve words of text. High image-to-text ratio is a classic spam signature. Keep at least a few real sentences of text.
• "Verify now!!!" subject lines. Urgency + imperative + exclamation is the exact shape of phishing. "Confirm your account for YourApp" outperforms "⚡ VERIFY YOUR EMAIL NOW ⚡" in every way that matters.
• All-caps, emoji clusters, and spam-trigger words ("free," "winner," "act now") — individually weak signals, but they stack.
• Missing plain-text part. Send multipart/alternative with both HTML and text. HTML-only mail takes a hit with some filters.
• A From name that's just an address. [email protected] with no display name looks automated-hostile. Use "YourApp Team."

None of these alone will junk a well-authenticated email from a reputable domain. Stacked on suspect #2 or #5, they tip the scale.

The Fix Sequence, in Order

When a user reports a missing email, work this list top to bottom. Don't skip ahead — each step is cheaper than the next.

Step 1 — Confirm the event. ESP logs: accepted? delivered? bounced? If bounced, the SMTP reply tells you the category. 550 5.7.26 = authentication failure. 550 5.7.1 with "unsolicited" language = reputation. 452/421 = throttling, retry and slow down.

Step 2 — Reproduce it yourself. Send the exact same template (same code path, same ESP stream) to a controlled address you own at the same provider — a real Gmail account, not just a seed tool. Check inbox, spam, and "All Mail."

Step 3 — Run the full diagnostic. Send it to willitinbox.com/test. You'll get 70+ checks back: SPF/DKIM/DMARC results as received (not as you hope they are), rDNS, blacklist status across 20+ DNSBLs, header anomalies, content and link flags — scored 0–100 with fixes ranked. This turns "something is wrong" into "DKIM signs with your ESP's domain and your tracking links sit on a flagged shared domain," which is an actionable sentence.

Step 4 — Fix authentication alignment. Custom DKIM d= domain, custom return-path, DMARC published. This is the highest-leverage fix and usually takes 20 minutes of DNS work.

Step 5 — Fix the links. Branded tracking domain, no shorteners, honest anchor text.

Step 6 — Fix the template. Real text content, multipart, calmer subject line.

Step 7 — Address the pool problem. If steps 4–6 are all clean and Gmail placement is still bad, it's your IP pool or your domain's history. Talk to your ESP about a better pool or dedicated IP, and give a young domain 2–4 weeks of steady, low-complaint volume.

Step 8 — Verify the fix. Re-run step 3. The score should move. If it doesn't, you fixed the wrong suspect — go back to step 1 with the new data.

Prevention: Never Debug This in Production Again

Everything above is reactive. Here's how to make the "I never got the email" ticket rare:

Use a Subdomain for Transactional Mail

Send transactional email from mail.yourapp.com or notify.yourapp.com, keeping marketing on a separate subdomain and your apex domain clean. If your marketing campaigns earn complaints, your password resets don't pay for it. This also makes per-stream reputation visible in Google Postmaster Tools, which reports at the domain level.

Full reasoning and DNS setup: /blog/email-subdomain-strategy. And if you're mixing receipts and newsletters through one stream today, read /blog/transactional-vs-marketing — separating them is the single best structural deliverability decision a SaaS can make.

Test Every Template Before Launch, Not After

Deliverability testing belongs in the same mental category as unit tests: run it when the template changes, not when a user complains. Add a step to your release process — send each transactional template to the tester and gate on the score. If you wire it through the API, this can literally run in CI: render template → send to test address → assert score ≥ threshold → deploy.

Monitor the Drift

DNS records get changed by well-meaning teammates. ESPs rotate IPs. DKIM keys expire. Your setup that passed in March silently breaks in June.

Set up ongoing monitoring: SPF/DKIM/DMARC drift scans, Google Postmaster Tools sync for domain reputation and spam rate, and DMARC aggregate report ingestion so unknown sending sources (a rogue integration, a forgotten Zapier workflow) get flagged before users do. WillItInbox monitoring watches all of these and alerts on drift — the free tier covers the basics.

Watch Complaint Rate Like a SLO

0.1% is the healthy ceiling; 0.3% is Gmail's hard line. Complaints on transactional mail usually mean you're emailing people who never asked (imported lists, pre-checked boxes) — fix the consent flow, not the email.

Pre-Launch Checklist: Run This Before Your Next Release

Run it every time you touch onboarding emails or change ESPs.

• [ ] SPF, DKIM, and DMARC pass with alignment on the exact domain in your From: header (test the real email, not a DNS lookup)
• [ ] Custom return-path and custom DKIM signing domain configured at your ESP
• [ ] DMARC record published (p=none minimum) with a working rua: address
• [ ] Transactional mail on a dedicated subdomain, separate stream from marketing
• [ ] PTR/rDNS forward-confirmed (only if dedicated IP or self-hosted)
• [ ] Branded link/tracking domain — no shared ESP tracking domain, zero URL shorteners
• [ ] Every domain in the template passes a blacklist check
• [ ] Multipart email (HTML + plain text), no image-only layouts
• [ ] Subject lines contain no urgency-bait, excessive caps, or emoji clusters
• [ ] Every transactional template (signup, verify, reset, receipt, invite) sent through the deliverability tester with a score you're willing to ship
• [ ] Google Postmaster Tools verified for your sending domain
• [ ] Drift monitoring enabled on SPF/DKIM/DMARC
• [ ] Support playbook: ESP event-log lookup written down, so the next "I never got it" takes 5 minutes, not 5 days

Apply the findings from Why Your Signup and Password-Reset Emails Land in Spam (and How to Fix It) with the deliverability testing workflow, then use the relevant WillItInbox product workflow to collect current evidence.