Emails going to spam despite SPF and DKIM: why

Cause 2: content triggers filters

Anti-spam filters always analyze content, even for authenticated mail. Some classic triggers:

• Too many links, especially to domains different from the sender's or to URL shorteners.
• An imbalanced text/image ratio — an email that's just one big image resembles a filter-evasion technique.
• Keywords historically associated with spam ("free," "urgent," excessive capitalization, multiple exclamation marks).
• Malformed HTML — code from a broken tool, unclosed tags, invalid structure.
• A missing plain-text version alongside the HTML, when many filters expect to find one.

None of these signals is disqualifying on its own, but they add up. An authenticated email with several warning signals in its content can flip to spam where the same email with clean content would have passed. Running a suspicious template past a spam-score checker before a big send is a five-minute habit that catches most of these issues before they reach real inboxes.

Cause 3: recipient engagement behavior

Gmail, Yahoo and Outlook watch how their users interact with a sender's mail — and adjust filtering accordingly, independent of authentication. If a significant share of recipients systematically ignores those emails (never opened, never clicked), or worse, reports them as spam, the filter learns to treat the entire flow with more suspicion, even messages to recipients who would be delighted to receive them.

It's a collective effect: the disengaged minority's behavior degrades deliverability for everyone. The fix is list hygiene — removing long-term inactives rather than continuing to solicit them indefinitely. The topic is developed in depth in Gmail deliverability: the complete guide.

Cause 4: an unusual sending volume or pace

A sudden sending spike — an exceptional campaign, a platform switch migrating the whole history at once — statistically resembles abusive behavior, even from an otherwise flawless sender. Filters react to pace anomalies, not just message content — the same volume that would go unnoticed as a steady trickle can look like an attack when it arrives all at once. A platform switch, or a sharp rise in volume, calls for a gradual ramp rather than a sudden change.

Cause 5: the domain or IP has been blacklisted

More radical: the domain or IP appears on a third-party blacklist (Spamhaus and equivalents), following a past incident — sometimes an unnoticed one, like a one-off compromise or that IP's prior use by another customer on shared infrastructure. Blacklists are checkable via dedicated online tools; most also offer a delisting procedure once the cause is fixed. The check is worth running even when it feels unlikely — it's a five-minute lookup, and being blacklisted unknowingly is precisely the kind of silent cause that keeps a well-authenticated sender stuck in spam for months.

Cause 6: missing or degraded transport encryption

A subtler but real signal with some strict receivers: the absence of TLS encryption during SMTP transport can count against a sender, especially against hardened security policies on the receiving side. Setting up MTA-STS guarantees the transport stays encrypted and prevents a forced downgrade to plaintext — see MTA-STS, what it is and what it's for. This usually isn't the main cause of an email landing in spam, but it's a factor that stacks with others among the most demanding receivers — banks, government agencies, large enterprises that apply strict security policies on inbound mail. Pairing it with TLS-RPT (see TLS-RPT explained) also gives visibility into encrypted-transport failures that would otherwise stay invisible, which is useful when a specific corporate recipient seems to be silently dropping the mail.

The case of isolated recipients vs. the whole flow

A practical distinction speeds up diagnosis: is it one specific recipient consistently getting the mail in spam, or a significant share of the flow? The causes aren't the same.

If it's one recipient (or a handful), the cause often sits on their side: a personal filter they set by mistake, an old spam report they made in the past that sticks to the sender's address in their mail client, or an overly aggressive corporate filtering rule on the receiving end. The fix generally involves asking them to check their own settings or add the address to their contacts — it can't be resolved unilaterally, and the most the sender can do is confirm its own configuration is clean.

If it's a significant share of the flow, the cause is structural — reputation, content, or engagement behavior — and deserves the full investigation described above. Optimizing for an isolated case in the belief that it settles a widespread problem is wasted time; and conversely, what's merely a personal setting at a single recipient's end shouldn't be treated as structural.

Filtering isn't global: each provider judges separately

Another reflex that speeds up diagnosis: "the emails go to spam" is never a single, uniform fact. Gmail, Outlook and Yahoo each run their own filters, their own reputation systems and their own engagement models — and they don't share verdicts. It's perfectly normal for the same campaign to land in the inbox at Gmail and in junk at Outlook, or the reverse. Before anything else, the observations get segmented by receiving provider. If a single provider is filtering, its specific levers are the ones that matter — its postmaster console where one exists, its known requirements, the sender's reputation history with it. If all of them filter at once, the cause is almost certainly on the sending side — reputation, content or list — and the structural causes reviewed above apply across the board.

Diagnostic method, in order

Facing a legitimate email that went to spam, the order of checks is:

1. Did that specific message actually fail DMARC (alignment), despite overall correct authentication? The aggregate report for that date and source settles it.
2. Is the IP/domain reputation degraded? Postmaster Tools and blacklists settle it.
3. Does this message's content contain warning signals (links, image-only, keywords)?
4. Has the list's recent engagement rate degraded?
5. Did volume or platform change recently without a gradual ramp?

Each of these causes has a different remedy — the mistake is to keep going back to the DMARC configuration thinking it must be at fault, when the problem lives elsewhere in the chain. Treating this as a diagnostic checklist, worked through in order rather than at random, saves considerable time — most cases resolve by finding the right cause among these six, not by chasing a seventh, exotic explanation.

What DMARC at p=reject can't fix

One limit needs to be clear: hardening a DMARC policy protects against spoofing of the domain, not against reputation or content problems in the sender's own legitimate mail. p=reject guarantees that what arrives authenticated in the domain's name genuinely comes from it — which, indirectly, helps reputation by eliminating an impersonator's pollution. But where the problem is list hygiene or content, DMARC won't change it. The two projects — authentication and behavioral deliverability — run in parallel, not one instead of the other. Many teams stop once DMARC is hardened, satisfied they've "handled email security," without realizing behavioral deliverability needs ongoing attention, not a one-off project to check off and forget.

To confirm the authentication layer is flawless and rule out that cause with certainty, a pass through the free DMARC analyzer is the reliable starting point before digging further into reputation or content — and often the fastest way to know whether to keep investigating on the DMARC side or move straight to the next step of the diagnosis — reputation, content, or engagement, whichever the evidence points to.