Why do your outbound emails go to spam and how can you fix it?
ChatGPT
Claude
Gemini
Perplexity
GrokIn brief
Stop outbound email going to spam: read the delivered message's Authentication-Results, fix the failing layer, then retest on the same path.
This guide is for senders trying to improve placement of email they send, not for recipients who need to block or safelist incoming mail. Outbound email goes to spam when the receiving mail system scores the message as risky. To stop it, treat placement as evidence, not luck: open a delivered message and read its Authentication-Results header to see whether SPF, DKIM, and DMARC passed and aligned, then check your sending reputation, complaint rate, and mailbox-provider requirements. Fix the one layer the evidence flags, then send a fresh test on the same path and reread the header.
At a glance
Quick takeaways
- Spam placement is a filter score, so diagnose it from the delivered message's own evidence rather than guessing at wording.
- The Authentication-Results header shows whether SPF, DKIM, and DMARC passed and aligned, and a receiver adds it inside its own trust boundary.
- Sending reputation and the spam-complaint rate move placement even when authentication passes.
- Gmail and Yahoo have bulk-sender requirements for authentication and aligned identities. Their one-click-unsubscribe rules apply to the covered marketing, subscribed, or promotional messages, not every message type.
- Relaxing a DMARC policy can change the domain's requested handling of DMARC-failing mail, but it does not repair authentication or guarantee placement. Aggregate reporting is configured separately, so keep repair separate from policy changes.
- Fix the single failing layer, then retest on the same sending path and reread the header.
What does the failure mean?
A receiving provider can accept a message and still place it in spam or junk rather than the inbox. The exact decision process is not published. Start with the evidence a provider exposes: the delivered authentication results and any sender-quality data in its postmaster tools.
The strongest input you control is authentication. When a provider runs SPF, DKIM, and DMARC on your message, it records the outcome in the message's Authentication-Results header. RFC 8601 defines that header, and the receiving system adds it as the message crosses the receiver's border, not you. A conforming server also deletes any Authentication-Results field that falsely claims to have been added inside that server's own trust boundary, so trust only the header written by the mailbox that actually received the message. Reading that header is the difference between fixing the failing layer and guessing.
Placement also depends on wider email deliverability factors that sit outside a single message: your domain and IP reputation, your spam-complaint rate, and whether you meet each mailbox provider's sender rules.
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounce@mail.sender.net designates
198.51.100.24 as permitted sender) smtp.mailfrom=mail.sender.net;
dkim=none;
dmarc=fail (p=none dis=none) header.from=example.com
In that illustrative example the return-path domain (mail.sender.net) passes SPF and DKIM is absent, so nothing authenticates the visible From domain (example.com). DMARC fails because neither passing identifier aligns with header.from. That result tells you to repair authentication before you draw conclusions about placement.
What usually causes it?
Authentication or alignment is failing
One diagnosis is that the message never produces an aligned pass. DMARC needs at least one of SPF or DKIM to both authenticate and align with the domain in the visible From address, a rule RFC 9989 defines as identifier alignment. A sending platform can pass SPF on its own return-path domain while your From domain stays unauthenticated, so SPF passes but DMARC still fails. A missing or broken DKIM signature has the same effect. When DKIM fails alignment, fix the alignment gap before changing content or policy.
Sending reputation or complaint rate is too high
Google's sender guidelines tell senders to keep the spam rate reported in Postmaster Tools below 0.3%, with below 0.10% as the recommended target. Use the provider's own postmaster evidence to decide whether sender quality is part of this specific placement problem; it does not replace the delivered-message authentication check.
You do not meet Gmail and Yahoo bulk-sender rules
Since February 1, 2024, senders of more than 5,000 messages a day to Gmail must meet Google's bulk-sender authentication and alignment requirements. Its one-click-unsubscribe rule applies to marketing and subscribed messages. Yahoo's sender best practices similarly cover bulk marketing and subscribed messages, while describing the RFC 8058 POST method as highly recommended. Check the provider's current guidance for the exact message type and threshold that apply to your send.
List evidence: complaints and opt-outs
Review the bounce, complaint, and opt-out evidence from your own sending platform before you send again. For covered mail, Google requires one-click unsubscribe and Yahoo requires honoring an unsubscribe request within two days. This list evidence does not substitute for checking the delivered authentication results.
Content and formatting raise the score
Google and Yahoo publish sender requirements, not a complete scoring formula. As an operational inference, treat a content or formatting change as one controlled test only after the header and provider-quality evidence are clean; do not guess at a universal list of spam words or formatting rules. Google's guidance and Yahoo's best practices remain the documented requirements to meet first.
How do I diagnose the failure?
Work the evidence in order, from the message the recipient actually received to the broader signals. The flow below shows the path.
1. Read the Authentication-Results header of a delivered message
Ask a recipient at the affected provider to forward the message as an attachment, or send yourself a seed message, then open the original source. Find the Authentication-Results line the receiving provider added and note the spf, dkim, and dmarc results and the header.from domain. This is the receiver's own verdict on your message, so it outranks any check you run against your own DNS.
2. Confirm SPF, DKIM, and DMARC alignment for your From domain
If dmarc shows fail, one of two things is usually true: neither SPF nor DKIM passed, or a mechanism passed but on a domain that does not align with your From domain. Check your published records and posture with Palisade's email security score, and confirm your DKIM signing domain matches the From domain you actually send from.
3. Check sending reputation and the spam-complaint rate
If authentication is clean but mail still lands in spam, look at reputation. Review your spam-complaint rate and bounce rate in the provider's postmaster tools. For Gmail, use the Postmaster Tools rate as evidence to investigate sender quality alongside the delivered header.
4. Confirm you meet the Gmail and Yahoo bulk-sender rules
If you send in volume, verify the provider's current requirements for your message type. Google and Yahoo apply their one-click-unsubscribe expectations to covered marketing, subscribed, or promotional messages, alongside their broader authentication and sender-quality rules.
How do I fix it?
Fix authentication and alignment first
Publish or correct SPF, DKIM, and DMARC so at least one mechanism produces an aligned pass for your From domain. Confirm your SPF record authorizes every service that sends for you, enable DKIM signing at each platform with the signing domain aligned to your From domain, and keep a DMARC record in place. Do not relax your DMARC policy as a technical repair: changing p=reject or p=quarantine to p=none changes the domain's requested handling of DMARC-failing mail, but it does not repair the authentication gap or guarantee placement. Each receiver still applies local analysis. Aggregate-report requests are configured separately from the policy disposition.
Reduce complaints and protect reputation
Use the provider's spam-rate and complaint evidence to decide whether sender quality is part of the problem. For Gmail, keep the Postmaster Tools spam rate below 0.3% and aim under 0.10%, then retest after any list or cadence change.
Meet the bulk-sender requirements
If you send bulk marketing, subscribed, or promotional mail to Gmail or Yahoo, apply the provider's current authentication, alignment, unsubscribe, and sender-quality requirements to that message type. For Google, the more-than-5,000-messages-per-day threshold applies to Gmail accounts; Yahoo defines its own bulk-sender scope.
Clean the list
Honor opt-outs and use the bounce and complaint evidence from your own platform before you change another variable. For covered Yahoo bulk mail, honor each unsubscribe request within two days; for covered Gmail mail, provide the required one-click unsubscribe mechanism.
Adjust content only after the evidence is clean
As an operational inference rather than a provider rule, change content only as one controlled test after the delivered header and provider-quality evidence are clean. Keep a record of the message version and retest on the same sending path so you can tell whether the change helped.
How do I validate the repair?
Validate on the same sending path you are trying to fix, not a lab domain.
- Confirm DNS: check that your SPF, DKIM, and DMARC records resolve as published through a public resolver.
- Send a real message: send from the same platform and account to a seed inbox at the affected provider.
- Read the header again: open the delivered message and confirm Authentication-Results now shows an aligned SPF or DKIM pass and dmarc=pass.
- Watch the aggregate evidence: review DMARC aggregate reports and provider postmaster data over later reporting windows to corroborate the same source-level authentication trend.
Make SPF, DKIM, and DMARC easier to manage
Once you know which layer is failing, check the published configuration you can verify before your next send. Run your domain through Palisade's email security score to review SPF, DMARC, and related public DNS signals, plus any DKIM selector you provide. A public check cannot discover every DKIM selector or production sending source; it does not control a receiver's filtering decision or guarantee inbox placement.
For broader authentication issues, Palisade's DMARC Agent processes incoming DMARC reports and creates actionable tickets when it detects an issue. Each ticket identifies the affected sending source and recommends a course of action; your team reviews the evidence and applies the fix. Get started
Evidence
Sources and further reading
Questions readers ask
Frequently asked questions
Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →
