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.

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?
How do I find out why my emails go to spam?
Do spam trigger words still matter?
How do I stop my emails from going to spam in Gmail?
Will getting delisted from a blocklist fix my deliverability?
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.