All posts Deliverability

Why your emails go to spam (and how to fix it)

A diagnostic guide to why emails go to spam: how spam filters actually decide, where to find the evidence (message headers, Google Postmaster Tools, Microsoft SNDS, blocklist checks), and the five causes behind most spam placement, each with the signs that identify it and the fix.

Erik Vlčák
Erik Vlčák
Customer Success Engineer
10 min read

A message that lands in spam produces no error, no bounce, and no notification, and mailbox providers do not report why they filed it there. The causes are enumerable, though, and each one leaves evidence in a specific place. This guide is a diagnostic: how the filtering decision works, where to look for the evidence, and the five causes that account for most spam placement, each with the signs that identify it and the fix. For building a compliant setup from scratch, the deliverability checklist is the companion piece; this article is for when mail is already going to spam and the question is why.

How a spam filter decides

Knowing what the filter weighs tells you where to look. Gmail describes its filtering as machine learning trained on user feedback, examining the sending IP, the domain, authentication, and how users react to a sender's mail; marking a message as spam, or rescuing one from the spam folder, trains the model directly. Microsoft's SmartScreen documentation lists the same inputs: sending IP, domain, authentication, list accuracy, complaint rates, and content. The practical reading of both lists is an order of operations: authentication acts as a gate, sender reputation sets the default disposition, and user signals move it over time. Content sits last, as a tiebreaker.

One structural point explains most confusion: the sender is the unit being judged, not the message. The same newsletter lands in the inbox from one domain and in spam from another, because the domains carry different histories. This is why diagnosing starts with the sender's evidence rather than with rewriting the email.

Find the evidence before changing anything

Each diagnostic below takes minutes and rules causes in or out. Run them in this order:

  • Send a test to a Gmail address and open "Show original" (the three-dot menu on the message). The summary at the top shows SPF, DKIM, and DMARC as pass or fail for that exact message. Any fail here is cause 1, and nothing else matters until it passes.
  • Check Google Postmaster Tools for the sending domain. The compliance dashboard grades the domain against Gmail's sender requirements, and the spam rate, domain reputation, and IP reputation dashboards separate cause 2 from cause 3. Low-volume senders may see no data, which is itself informative: the domain has little history.
  • For Outlook and Hotmail placement, register the sending IPs in Microsoft SNDS (Smart Network Data Services). It reports complaint volume, spam-trap hits, and the filter's verdict per IP.
  • Run the domain and IPs through a blocklist check such as MXToolbox, with one caveat: it queries around a hundred lists and most of them do not matter. A Spamhaus listing is significant; an obscure list nobody queries is noise.
  • For a placement answer rather than a cause, run a seed test (GlockApps and similar services deliver to real mailboxes across providers and report where each copy landed). Single-message scanners like mail-tester check the message and DNS setup, which catches configuration issues but cannot see reputation.

Cause 1: authentication fails or doesn't align

This is the first thing to rule out because it is binary and enforced. Since February 2024, Gmail requires every sender to pass SPF or DKIM, and bulk senders (5,000 or more messages a day) need SPF, DKIM, and DMARC together, with the visible From domain aligned to the domain that SPF or DKIM validated. Unauthenticated mail may be rejected outright with a 5.7.26 error, and since May 2025 Microsoft rejects unauthenticated high-volume mail with 550 5.7.515. Yahoo enforces the same standard.

The failure that slips past experienced senders is alignment: SPF and DKIM both pass, but for a different domain than the one in the From address, so DMARC fails anyway. The special case worth naming is the freemail From address: mail sent from an @gmail.com or @yahoo.com address through an email provider fails DMARC by construction, because the provider cannot authenticate for Google's or Yahoo's domain (Yahoo has published a reject policy since 2014). The fix is sending from a domain you own, with the records from the SPF, DKIM, and DMARC guide published and verified.

Cause 2: recipients mark the mail as spam

Complaints are the strongest negative signal a filter learns from, and they are the one metric with a published, enforced threshold. Google requires the spam rate reported in Postmaster Tools to stay below 0.3% and recommends staying below 0.1%; a sender above 0.3% is ineligible for support mitigation until the rate stays below the line for seven consecutive days. Yahoo publishes the same 0.3% ceiling.

The measurement has a diagnostic subtlety. Gmail's spam rate counts messages that reached the inbox and were then marked as spam, so a low spam rate does not clear a sender whose mail already lands in spam (mail in the spam folder generates no complaints). A rising spam rate means inbox recipients are turning against the mail. The causes are usually consent and expectations: recipients who never signed up, mail arriving far more often than promised, or an unsubscribe that is harder to find than the spam button. The fix is one-click unsubscribe (required for bulk senders anyway), honest sending frequency, and cutting the segments that never engage.

Cause 3: the sender's reputation is low or nonexistent

Postmaster Tools grades domain and IP reputation on four levels (bad, low, medium, high), and Google's documentation is blunt about the bottom of the scale: mail from a bad-reputation sender is almost always marked as spam or rejected. Reputation problems have three usual shapes: a new domain with no history sending real volume on day one, a sudden volume increase on an established domain (Google's guidance after deferrals is to grow daily volume by 25% to 100%, not multiples), and inherited trouble from shared infrastructure, since the activity of every sender on a shared IP affects all of them.

One aggregation rule matters for anyone running subdomains: Gmail counts subdomain traffic toward the primary domain's bulk-sender status and evaluates compliance at the primary-domain level, so a misbehaving marketing subdomain can affect how the organization's mail is classified even when transactional mail is clean. A new or cold domain needs a gradual warm-up; an established domain with a reputation dip needs the volume held steady while causes 2 and 4 are fixed.

Cause 4: the list itself

List quality shows up in the filter's inputs as engagement and in the worst case as spam traps: addresses that exist to catch senders with bad list practices. A pristine trap never belonged to a person, so hitting one means the list was bought or scraped. A recycled trap is an abandoned mailbox that hard-bounced for an extended period before being reactivated as a trap, so hitting one means bounces are not being removed. Microsoft SNDS reports trap hits directly, which makes them one of the few list problems that can be measured rather than inferred.

The fix is mechanical and covered step by step in the bulk email guide: double opt-in at the front door, immediate removal of hard bounces, and a sunset policy for recipients who have not engaged in months. Google's own guidelines recommend both of the last two.

Cause 5: the content (a smaller factor than assumed)

Content is the most rewritten and least decisive factor. Static lists of "spam trigger words" are folklore; for an authenticated sender in good standing, no single word decides placement, and deliverability practitioners have largely stopped treating word lists as meaningful. What Google actually documents as content requirements is narrower and checkable:

  • No hidden content. HTML or CSS that conceals text from the reader is an explicit spam signal.
  • Honest subject lines. No "Re:" or "Fwd:" on messages that are not replies or forwards, and no misleading claims.
  • One message type per message. Google specifically warns against mixing content types, such as promotions inside a receipt.
  • Visible, comprehensible links. Link text should match where the link goes. URL shorteners are not banned, but they hide the destination domain, and a shortener whose domain sits on a blocklist donates that reputation to the message.
  • Standards-compliant formatting. RFC 5322 structure, a valid Message-ID, and well-formed HTML.

FAQ

Why are my emails going to spam all of a sudden?
A sudden change usually means a threshold was crossed, not that content changed. The usual suspects are an authentication record that broke (check a test message's Show original), a complaint rate approaching 0.3%, a volume jump the domain's history does not support, or a new blocklist entry. Postmaster Tools narrows it down fastest.
How do I find out why my emails go to spam?
Collect evidence in three places. Send a test to Gmail and read the SPF, DKIM, and DMARC verdicts in Show original; check compliance, spam rate, and reputation in Google Postmaster Tools; and run the domain and IPs through a blocklist check. Each cause of spam placement leaves a mark in one of them.
Do spam trigger words still matter?
Barely. Modern filters weigh authentication, sender reputation, and user behavior far above vocabulary. Google's documented content rules are about deception instead: hidden text, fake "Re:" subjects, mixed message types, and misleading links. A reputable sender does not need to write around a word list.
How do I stop my emails from going to spam in Gmail?
Pass Gmail's published requirements, then fix whichever cause the evidence points to. That means SPF, DKIM, and DMARC with an aligned From domain, one-click unsubscribe on bulk mail, a spam rate below 0.3% (ideally 0.1%), steady volume, and a list of people who opted in. The compliance dashboard in Postmaster Tools grades each item.
Will getting delisted from a blocklist fix my deliverability?
Only if the listing caused the problem, and only if the root cause is fixed first. Gmail, Outlook, and Yahoo rely primarily on their own reputation systems, not public blocklists; a Spamhaus listing matters, but most of the hundred lists a checker queries do not. Delisting without fixing the underlying practice leads to relisting.

Bottom line

Spam placement always has a cause, and the cause leaves evidence: an authentication verdict in the headers, a complaint rate or reputation grade in Postmaster Tools, trap hits in SNDS, a listing on a blocklist that actually matters. Diagnose in that order, fix the one thing the evidence names, and resist rewriting subject lines while the real cause sits in DNS or in the list.

A managed sending platform removes several causes outright: Lettr authenticates every domain it sends for, adds one-click unsubscribe to campaigns, suppresses bounces and complaints automatically, and its deliverability alerts report reputation problems and blocklistings as they happen rather than after a quarter of silent spam placement. Create a free account and run the first authenticated test message through it today.