Why are emails going to the spam folder

Junked mail almost always traces back to a short list of causes, and they are nowhere near equally likely. If you are asking why are emails going to spam folder for your signup, receipt or password reset mail, work down this list in order. Authentication alignment sits first because it fails silently and is the only cause you can prove in a single test. Subject line wording sits last, because it is rarely the real problem.

The ordering below assumes transactional mail sent from an application, through an email service provider or your own SMTP server.

Cause 1: SPF and DKIM pass, but neither aligns with your From domain

This is the most common answer to why are emails going to spam folder, and it is invisible from the outside.

SPF authenticates the envelope sender, the Return-Path address the receiving server sees during the SMTP conversation. DKIM signs the message with a key belonging to whatever domain sits in the signature’s d= tag. Neither one has to match the From address your recipient actually reads. DMARC is the rule that ties them together: RFC 7489 says a message passes when at least one of the two produces a pass result “based on an identifier that is in alignment” with the From domain.

The classic break looks like this. You send from billing@yourapp.com, but your provider uses its own bounce domain for Return-Path and its own key for the signature. SPF passes. DKIM passes. DMARC still fails, because the domain that passed belongs to the provider and not to you.

Fix: publish the DKIM CNAME records your provider hands you, so the d= tag becomes a subdomain of yours, and configure a custom Return-Path (usually a bounce. or mail. subdomain carrying its own SPF record). Then verify from a delivered message, not a lookup tool. If the records are unfamiliar, SPF, DKIM and DMARC explained covers what each one does.

Cause 2: there is no DMARC record at all

Google’s sender guidelines require bulk senders, roughly 5,000 messages a day to Gmail accounts, to have SPF, DKIM and DMARC in place, and are explicit that the enforcement policy “can be set to none”. Below that volume it is not required, but it is still the cheapest positive signal available.

Fix: publish a TXT record at _dmarc.yourdomain.com.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none changes nothing about delivery by itself. It turns on reporting. Read the aggregate reports for two or three weeks, identify every system sending as you, then move to p=quarantine and later p=reject. Publishing p=reject before you know your sending sources is how an internal tool quietly stops delivering. That pattern is common enough that WordPress mail that stops sending covers the same failure from the site side.

Cause 3: the domain or IP has no reputation, or a borrowed one

A domain that sent nothing for a year and then pushes forty thousand messages in an afternoon looks exactly like a compromised domain. On a shared IP pool you inherit whatever your neighbours did last week. Google also asks for valid forward and reverse DNS, the PTR record, on the sending IP.

Fix: ramp volume up gradually rather than in one step, and separate streams by subdomain, so notify.yourapp.com carries password resets while news.yourapp.com carries campaigns and a bad campaign cannot poison the resets. Confirm the PTR record resolves back to the sending host. This is the least satisfying answer to why are emails going to spam folder, because there is no setting to flip, only weeks of consistent behaviour.

Cause 4: the message looks like bulk mail

Microsoft assigns a bulk complaint level to inbound mail from bulk senders, treats that as its own filtering verdict, and can move the message to Junk or to Promotions on that basis alone. Mail that carries campaign furniture gets read as a campaign even when it is a receipt.

Fix: keep transactional mail plain. No link shorteners, no tracking domain unrelated to the From domain, no body that is one large image and four words of text. For genuine list mail, add List-Unsubscribe along with List-Unsubscribe-Post: List-Unsubscribe=One-Click as described in RFC 8058, and make sure your DKIM signature actually covers those headers, since an unsigned one-click header is not trusted.

Cause 5: recipients complain, or never engage

Google asks senders to keep the spam rate reported in Postmaster Tools below 0.30%, and recommends staying under 0.10%. Once you are above that line, even well authenticated mail starts getting filed away.

Fix: register the domain in Postmaster Tools so you can see the rate at all, process unsubscribes immediately, suppress hard bounces permanently, and stop mailing addresses that have not opened anything in a year. A purchased list will burn a domain faster than the four causes above combined.

Prove it from a delivered message, not a DNS checker

Every cause above ends in the same place, and so does every honest answer to why are emails going to spam folder: a header on a message that actually arrived. A checker tells you what you published. It cannot tell you what the receiving server decided, which is the only thing that matters. The ground truth is the Authentication-Results header on a message that actually arrived somewhere.

The fastest version of that loop: create a disposable inbox, send your application’s mail to it, and read the headers. The Email Testing API does it in two calls and lets you assert on the outcome instead of eyeballing it.

curl -X POST https://inboxdome.com/v1/inboxes \
  -H "Authorization: Bearer idk_live_..."

curl -X POST https://inboxdome.com/v1/inboxes/inb_.../assert \
  -H "Authorization: Bearer idk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"timeoutSeconds":45,"assertions":[
        {"type":"auth","check":"spf"},
        {"type":"auth","check":"dkim"}]}'

The response carries passed, arrivalSeconds and a per-assertion result list, so you learn which check failed rather than that something did. Wire it into the pipeline, either through Playwright email tests or as a step in GitHub Actions, and a DNS change that breaks DKIM fails a build instead of a customer signup. The free tier covers 100 inbox tests a month.

When only one provider junks it

If Gmail delivers and Outlook does not, stop editing DNS. Shared causes produce shared symptoms, so a single-provider problem points at a provider-specific signal: a bulk verdict at Microsoft, a complaint rate at Google, a local block at a corporate gateway. Read the anti-spam headers Microsoft stamps on the message, which name the verdict, and Postmaster Tools for the Gmail side. Fix alignment, DMARC and PTR first, since those are cheap and universal, then chase whichever provider is still unhappy.