Why your email lands in spam: a diagnostic path to follow

Mail landing in spam has a small number of likely root causes, but guessing at the wrong one wastes time fixing something that wasn't broken. This is the order to check them in, from fastest-to-confirm to slowest.

Step 1: check authentication first

It's the fastest thing to confirm and the most common cause. Pull the headers of a message that landed in spam and look for the Authentication-Results line:

Authentication-Results: mx.google.com;
       dkim=fail (body hash did not verify) header.i=@example.com;
       spf=pass smtp.mailfrom=bounce@example.com;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.com

A dkim=fail here, with SPF passing, is a specific and fixable signal - something is altering the message body after signing (a forwarding rule, a link-tracking rewrite applied after DKIM signs, or a misconfigured selector). This is worth ruling out before looking at anything else, since it takes minutes to check and can explain the entire problem on its own.

Step 2: check the Postmaster Tools spam-rate band

If authentication passes cleanly, check whether the sending domain's spam-rate band in Google Postmaster Tools has moved - a jump from "0.00%-0.10%" to "0.10%-0.30%" or higher in the days before the affected send is a strong, specific signal that this is a reputation issue, not a one-off content problem.

Step 3: check for a recent volume or list change

Step 4: check content only after infrastructure is ruled out

Content-based filtering is real but is a smaller factor today than authentication and reputation for most legitimate senders. Checking content first - rewriting subject lines, removing links - without first confirming authentication and reputation are clean often "fixes" nothing, because the actual cause was never content.

When content genuinely is the cause, it's usually one of a short list: an image-only message with little or no text (a classic spam signature regardless of what the image shows), a link-to-text ratio skewed heavily toward links, a shortened or redirect-chained URL that the filter can't evaluate directly, or a subject line pattern matching known spam templates rather than any single "trigger word." Fix the structural issue, not just the wording - swapping one flagged word for a synonym rarely moves the needle if the underlying pattern (image-heavy, link-heavy, redirect-heavy) is still there.

Step 5: confirm with a seed-inbox test

Once a likely cause is identified and addressed, confirm the fix with an actual seed-inbox placement test rather than relying on open-rate recovery alone, since open rate is a lagging and partially unreliable signal (inflated by privacy-proxy prefetching, suppressed by Apple Mail Privacy Protection). Run the test against the same providers where the original placement problem showed up - a fix that restores Gmail placement but hasn't been checked against Outlook or Yahoo is only half confirmed, and providers don't always recover on the same timeline for the same underlying fix.

A quick-reference table

What not to do

• Don't start with a content rewrite before checking authentication and reputation - it's the slowest thing to verify and the least likely cause for most domains with any sending history.
• Don't diagnose from open-rate alone - check headers and Postmaster Tools data directly, since open rate is an indirect and increasingly unreliable signal.
• Don't assume the cause is permanent once identified - a DKIM signing issue, once fixed, typically resolves placement within days; a reputation-based cause takes longer and needs the gradual-recovery approach, not a quick content tweak.
• Don't skip confirming the fix with an actual placement test - assuming a fix worked because open rate ticked up again is exactly the kind of lagging-signal mistake that leads to repeat problems.

MailPilot runs seed-inbox placement tests across providers and checks SPF/DKIM/DMARC against mail as actually delivered - which turns steps 1, 2 and 5 of this diagnostic path into data you already have, rather than checks you have to run manually when something breaks.