Why your emails go to spam — and what to check first
Emails go to spam when a receiver distrusts the sender, the message, or both. Start with the evidence from one representative send: rejection code, SPF/DKIM/DMARC verdicts, infrastructure and content findings, then provider-specific placement. A warning is not proof that it caused spam placement.
Mailbox providers combine authenticated identity, sending infrastructure, user-reported spam, recipient engagement, message structure and provider-specific reputation. Gmail's current bulk-sender rules require both SPF and DKIM, DMARC alignment through at least one of them, valid forward and reverse DNS, TLS and a published DMARC policy whose minimum can be p=none. One-click unsubscribe applies to marketing and promotional traffic, not every transactional message. Meeting those requirements improves eligibility; it does not guarantee inbox placement.
Primary sources for this guidance
- Gmail email sender guidelines
- Gmail email sender guidelines FAQ
- Yahoo Sender Hub best practices
- RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance
- RFC 8058 — Signaling One-Click Functionality for List Email Headers
How to fix it
- Identify the observed failure before editing anything. Separate an SMTP rejection from spam-folder placement, a promotions-tab result, a recipient complaint or a sender-reported impression.
- Send one representative message through the same domain, ESP, Return-Path, DKIM selector, tracking links and message type you plan to use in production.
- Read authentication as verdict plus alignment. A message can pass SPF for an ESP bounce domain yet fail SPF alignment; DMARC can still pass through an aligned DKIM identity.
- Treat a valid DMARC record with p=none as monitoring, not as an authentication failure. Move to quarantine or reject only after legitimate senders and indirect-mail risks are understood.
- For marketing and promotional mail, verify RFC 8058 one-click unsubscribe headers and the actual suppression path. Do not apply that provider requirement to transactional messages by default.
- Check dedicated sending infrastructure for valid forward and reverse DNS, HELO/EHLO identity, TLS and confirmed blocklist events. Do not penalize a sender for shared provider relays it does not control.
- Inspect the received MIME structure, links, image/text balance and destination behavior. Content findings can explain a message defect, but a clean body cannot repair broken identity or reputation.
- Use provider diagnostics, complaint and bounce trends, permission and engagement evidence for reputation questions. One received message and one seed observation cannot establish domain recovery or list quality.
- Read placement only for provider families that reported with sufficient quorum. Pending or unavailable provider evidence is inconclusive, not a spam verdict.
- Choose one highest-confidence failure class, assign its owner, make one observable change and run a comparable production-path retest.
Limitations
This page helps triage one representative received message. It cannot prove why every recipient saw spam, measure list permission or long-term reputation, represent providers without sufficient seed evidence, or guarantee future inbox placement.