Folderly Flash Send-readiness test

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.

Why mailbox providers enforce this

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

How to fix it

  1. 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.
  2. Send one representative message through the same domain, ESP, Return-Path, DKIM selector, tracking links and message type you plan to use in production.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Read placement only for provider families that reported with sufficient quorum. Pending or unavailable provider evidence is inconclusive, not a spam verdict.
  10. 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.

Next action Send one representative production-path message to Flash, start with the highest-confidence failed verdict rather than the total score, open the matching specific fix and run a comparable retest only after the change is observable.
Run a free test →

FAQ

Does spammy wording send emails to spam?
Message structure and destinations can contribute, but wording alone is not a complete diagnosis. Check authenticated identity, infrastructure, reputation and provider evidence alongside the received content.
Does DMARC need p=reject for Gmail?
No. Gmail's current bulk-sender minimum accepts a published DMARC policy of p=none, while the direct message must align through SPF or DKIM. A stricter policy is an anti-spoofing decision, not an inbox guarantee.
Do all emails need one-click unsubscribe?
No. Gmail applies the one-click requirement to marketing and promotional messages. Transactional messages are excluded, although their sending identity and other applicable requirements still need to be correct.
Why does one provider send the message to spam?
Providers use different reputation and recipient signals. Confirm that the result is repeatable for that provider, that enough seeds reported, and that the tested message matches the production path before escalating a provider-specific incident.

Related

Content record Owner: Folderly Flash content operations Reviewed: 2026-10-06 Maintenance trigger: Review when Gmail or Yahoo changes sender requirements, DMARC or RFC 8058 guidance changes, or Flash changes failure states, stable components or default fix routing.
Want a deliverability engineer to fix this for you? Hand it to Folderly →