Why your email goes to spam and how to diagnose it

Your mail lands in spam, there is no bounce, no error, no log line, and the cause is invisible. You can stare at the message all day and learn nothing, because the decision happened inside someone else's filter.

Spam placement is frustrating precisely because it is silent. A hard bounce gives you an SMTP code and a reason. A spam-foldered message gives you nothing: it was accepted, delivered, and quietly filed where nobody looks. So people guess. They reword subject lines, strip the word "free," add more text, and ship again, hoping. That is debugging by superstition, and it mostly does not work because the wording was rarely the problem.

This guide is a diagnosis procedure, not a checklist of myths. We go in the order filters actually weight things: authentication first, reputation second, content last. By the end you will know how to read the one header that explains most of it, where to look when the header is clean, and how to tell a real signal from folklore. Then, near the end, we show where a stack like Tinbox surfaces this data for you instead of making you dig.

How do I find out why my email went to spam?

Read the raw headers of a test message: send to a Gmail and an Outlook address you control, open the original source, and find the Authentication-Results header. That single line tells you whether SPF, DKIM, and DMARC passed at the receiver, and authentication failure is the most common reason mail is filtered. If it passes there, the cause is reputation or content, and you move to those.

Everything downstream depends on getting real data instead of guessing, so start with a controlled test rather than asking a colleague "did it look spammy." Send one message to each major receiver, open it, and view the source:

• Gmail: open the message, click the three-dot menu, choose "Show original."
• Outlook / Microsoft 365: open the message, File or the menu, "View message source" (or "View source" in the web app).
• Apple Mail: View, Message, Raw Source.

You are looking for one header. In Gmail's "Show original" view it is summarized at the top; in the raw source it looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=tbx1 header.b=Q3k9aZ2p;
       spf=pass (google.com: domain of bounce@yourdomain.com designates
         203.0.113.10 as permitted sender) smtp.mailfrom=bounce@yourdomain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Three words decide the next hour of your life: dkim=pass, spf=pass, dmarc=pass. If all three say pass, authentication is not your problem and you skip to reputation. If any says fail, softfail, none, or temperror, you have found your first cause and you fix it before looking at anything else. A clean-looking email with dmarc=fail will go to spam no matter how good the copy is.

What does it mean when SPF, DKIM, or DMARC fails?

Each failure means a different thing, and the fix is different for each. SPF fail means the sending IP is not authorized in your domain's SPF record. DKIM fail means the cryptographic signature did not verify, usually a wrong or missing public key in DNS. DMARC fail means that even if SPF or DKIM passed individually, the domains did not align with your visible From address.

Take them one at a time, because conflating them is how people "fix" the wrong record for an afternoon.

SPF fail or softfail. Your DNS TXT record lists which servers may send for your domain. If the IP that actually sent is not covered, you get a fail. Common causes: you switched sending providers and never updated the include:, or you have two v=spf1 records (which is a permanent error, and SPF fails outright). Check the current record:

dig +short TXT yourdomain.com | grep spf1

"v=spf1 include:_spf.google.com include:_spf.oldprovider.com ~all"

If you moved to a new sender, the new provider's include must be there and the old one removed. Keep exactly one v=spf1 record. A common failure mode is two records, which looks like belt-and-suspenders but breaks SPF entirely:

# BROKEN: two SPF records = permanent error, spf=permerror
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:_spf.newprovider.com ~all"

DKIM fail. Your provider signs each message with a private key and publishes the matching public key at a selector subdomain. A fail means the receiver could not verify the signature: the public key in DNS is missing, truncated, or for a different selector. The header tells you the selector (header.s=tbx1 above), so check that exact name:

dig +short TXT tbx1._domainkey.yourdomain.com

If that returns nothing, the key was never published or the selector is wrong. If it returns a key but DKIM still fails, the published key may not match the one your sender is actually signing with, which happens after a key rotation that DNS missed.

DMARC fail with SPF and DKIM passing. This is the sneaky one. DMARC requires alignment: the domain in your visible From: header must match the domain SPF authenticated (smtp.mailfrom) or the domain that signed DKIM (header.d). You can pass both SPF and DKIM on a provider's domain and still fail DMARC because neither aligned with your From domain. The fix is to send so that either the bounce/return-path domain or the DKIM d= is your own domain, not the provider's shared one. If any of this is new, the full SPF, DKIM, and DMARC setup walkthrough covers the records and the alignment rules end to end.

My authentication passes but mail still goes to spam. Now what?

If SPF, DKIM, and DMARC all pass and mail still lands in spam, the cause is sender reputation: your domain or IP has a poor or nonexistent track record with the receiver. Reputation is the heaviest signal modern filters use, heavier than any word in your subject line, and it is built from your sending history, complaint rate, and blocklist status.

Reputation has three things to check, and the receivers hand you the data if you ask.

Domain reputation at the receiver. Google and Microsoft publish per-domain reputation to senders who register. Set up Google Postmaster Tools by adding your domain and a DNS TXT verification record. Within a few days of real volume you get dashboards for:

• Domain reputation (High / Medium / Low / Bad). Anything below High means Gmail is skeptical of you.
• Spam rate (the fraction of recipients marking you as spam). Gmail's bulk-sender bar is under 0.3 percent; above that and you will be filtered regardless of authentication.
• Authentication pass rates over time, which catches intermittent failures a single test misses.

If Gmail filters you specifically but other providers do not, this dashboard is almost always where the answer is, and the answer is usually the spam rate.

Blocklists. Your domain or sending IP may be on a public blocklist (Spamhaus, SpamCop, Barracuda). A listing silently kills delivery. Check it:

# Reverse the IP octets and query the Spamhaus zone
# IP 203.0.113.10 -> 10.113.0.203
dig +short 10.113.0.203.zen.spamhaus.org

# A returned 127.0.0.x address means LISTED. Empty means not listed.
127.0.0.4

A 127.0.0.x answer means you are listed; an empty response means you are clean. Also check the domain against domain blocklists (DBL). If you are listed, each list has a delisting process, and you fix the underlying cause (compromised account, spam trap hits) before requesting removal or you will be relisted. The full removal sequence, in order, is in the steps to get your domain off an email blacklist.

Newness. A domain you registered last week has no reputation, which filters treat as suspicious by default. There is no shortcut here: you build trust by sending consistent, wanted mail at a gradually increasing rate. That is the entire subject of warming up a new sending domain, and skipping it is the single most common reason a brand's first campaign goes straight to spam.

Do "spam trigger words" actually matter?

Mostly no. The lists of forbidden words ("free," "guarantee," "click here," "$$$") circulating in marketing blog posts are largely folklore left over from filters of fifteen years ago. Modern filters weight authentication and reputation far above wording. A well-authenticated domain with a clean reputation can say "free" in the subject and land in the inbox; a domain with a bad reputation will be filtered while talking about a software release.

That said, a few content and structural signals are real because they correlate with how actual spam is built:

• Image-only emails. A single large image with almost no text is a classic spam pattern (it hides the words from text filters). Always include real text and a meaningful text-to-image ratio.
• Missing plain-text part. A multipart/alternative message with both HTML and plain text looks normal; HTML-only is slightly more suspicious. Send both parts.
• Link shorteners and mismatched links. bit.ly and friends are heavily abused, and a link whose visible text says one domain while the href points elsewhere reads as phishing. Use your own domain for links.
• Broken or missing unsubscribe. Bulk mail without a working List-Unsubscribe header (and, for Gmail and Yahoo bulk senders, a one-click List-Unsubscribe-Post) is penalized. This is now a requirement, not a nicety. See the email deliverability guide for the header specifics.
• Sloppy HTML. Unclosed tags, gigantic inline styles, and tracking-pixel soup from a dozen vendors raise the spam score at the margins.

The honest summary: content is a tiebreaker, not the main event. If you are reaching for a spam-words list before you have checked your Authentication-Results header and your Postmaster reputation, you are optimizing the least important variable. For the content signals that genuinely move the needle (rather than the folklore), the content triggers that raise your spam score separates the real from the superstition.

How does list hygiene affect spam placement?

A dirty list damages your reputation faster than any content choice, because sending to dead, mistyped, or spam-trap addresses generates the exact signals filters use to identify spammers. Bounces, complaints, and trap hits all feed back into the reputation score that decides your next send's placement.

Three list problems do real damage:

1. Stale addresses. Emailing addresses that have not engaged in a year or more raises bounces and lowers engagement, both of which filters read as a low-quality sender. Sunset unengaged subscribers instead of clinging to list size.
2. Spam traps. Recycled or pristine trap addresses exist only to catch senders who do not clean their lists or who scraped addresses. Hitting one tanks reputation. The defense is never buying or scraping lists, and using double opt-in so every address was confirmed by a real human.
3. High complaint rate. Every "mark as spam" click is counted. A confirmed-opt-in list with an obvious, working unsubscribe link keeps complaints low; a purchased list or a buried unsubscribe drives them up. Past Gmail's 0.3 percent line, placement collapses.

The structural fix is double opt-in at signup and automatic suppression of bounces and complaints so you never re-send to an address that already bounced or complained. Building that suppression by hand is a project; a stack that does it for you removes the most common slow-motion reputation leak.

Where does Tinbox fit in diagnosing spam placement?

Tinbox surfaces the diagnosis data this guide makes you collect by hand, because it runs the whole sending and receiving stack on your own Cloudflare account where it can see the headers, the authentication results, and the bounce and complaint events directly. Everything above is still how email works; what changes is that you are not screenshotting raw headers and cross-referencing three dashboards to find the cause.

Tinbox is a self-contained, tenant-deployed email stack: a transactional sender, a newsletter tool, and a human webmail inbox, all on D1, R2, Queues, and Workers in your account. Because the sender and the inbox are both yours, the authentication and reputation signals are first-party data, not a vendor's summary you have to request access to.

On the setup side, the bootstrapper prints the exact records that make Authentication-Results say pass, which removes the most common root cause before you ever send:

npx tinbox init yourdomain.com

✔ Provisioned D1 database (tinbox-yourdomain-db)
✔ Provisioned R2 bucket (tinbox-yourdomain-mail)
✔ Generated DKIM keypair (selector: tbx1)

Add these DNS records, then `npx tinbox deploy`:
  SPF    yourdomain.com         TXT  "v=spf1 ... ~all"
  DKIM   tbx1._domainkey...     TXT  "v=DKIM1; k=rsa; p=MIGf..."
  DMARC  _dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:..."

On the operational side, Tinbox handles the parts that turn into reputation problems if you neglect them: it sends a multipart/alternative body with a real plain-text part, attaches a compliant one-click List-Unsubscribe header to bulk mail, and maintains an automatic suppression list so a bounced or complained address is never sent to again. Those are exactly the list-hygiene and content signals from the sections above, handled by default instead of by discipline.

Two honest caveats. First, no tool can manufacture reputation: Tinbox makes authentication correct and content clean, but a new domain still has to be warmed gradually and a domain you previously burned still has to recover slowly. Second, the inbound interpreters and some routing are git-gated in the current build, so the diagnosis tooling is strongest on the sending side you control; treat the receiving-side classification as configured-in-code, not a turnkey dashboard. Owning the stack shrinks the guesswork, but it does not repeal how filters earn trust.

If you want the broader model of why running your own sender changes this calculus, the Tinbox overview lays it out. For the short, scannable version of the failures to avoid, the common Cloudflare email mistakes that land mail in spam collects them in one list. The diagnosis procedure in this guide is the durable skill; Tinbox just stops hiding the evidence.

Deploy this yourself: npx tinbox init yourdomain.com. Read the generated DNS records and the deliverability docs next, then send one test and read the headers.