My emails go to spam even though SPF, DKIM and DMARC pass
Authentication is your ID card, not your entry ticket. SPF, DKIM and DMARC prove the message really is from you — they say nothing about the question that actually decides where it lands: do people want to receive it? What Gmail, Outlook and Yahoo look at next is your complaint rate, the quality of your list, whether one-click unsubscribe works, and your sending reputation.
But before you go hunting for your reputation, read the second half of this page: in about half the cases, the "all green" your tool is showing you is wrong. Three classic failures produce a perfect-looking result while authentication quietly fails at the recipient's end.
What we don't do: we don't promise anyone inbox placement, and we never touch your DNS zone. We tell you what the rest of the world sees, and what it means.
First: are you sure it's actually spam?
Two false alarms are common enough to rule out in thirty seconds:
- Gmail's Promotions tab is not the spam folder. Your email arrived. It's in the inbox. It's just been sorted. For a commercial newsletter, that's the tab it's designed for. If your goal is the Primary tab, that's a content and relationship problem, not a DNS one.
- Testing on yourself proves nothing. You email yourself, it lands in spam, you panic. A message an address sends to itself — or between two addresses on the same domain — doesn't go through the same filters as a real send. Test to real addresses, at several providers.
The thresholds everyone has been enforcing since 2024
Three major providers, near-identical rules, and published numbers. If you send 5,000 messages or more per day to any one of them, these stop being advice and become conditions of entry.
| What's required | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| SPF and DKIM | Both | Both | Both |
| Published DMARC | Yes, p=none is enough |
Yes, p=none is enough |
Yes, p=none is enough |
| DMARC alignment | SPF or DKIM aligned with the From: domain | DMARC must pass | At least one of the two aligned |
| Complaint rate | < 0.30%, aim for < 0.10% | < 0.30% | (not published) |
| One-click unsubscribe | Required (marketing and subscribed mail) | Required | (not explicitly required) |
| TLS connection | Required | — | — |
| Valid reverse DNS (PTR) | Required | — | — |
Read that complaint rate twice: Gmail's ceiling is 0.30%, which is 3 people in 1,000. Google recommends staying under 0.10% and "avoid ever reaching a spam rate of 0.30% or higher". The rate is calculated daily — a single badly targeted campaign can push you over for the day, and the consequences last weeks.
And the count is per primary domain, subdomains included: "messages sent from the same primary domain count toward the 5,000 limit". Splitting your sending between mail.yourdomain.com and news.yourdomain.com does not get you under the threshold.
What to add — two headers, not a DNS record
One-click unsubscribe doesn't live in your DNS. It's two headers your sending tool attaches to every message. If you use Mailchimp, Klaviyo, HubSpot, SendGrid, Brevo or any serious campaign tool, they're normally already there — your job is to check, not to write code.
List-Unsubscribe: <https://YOUR-TOOL/unsubscribe?id=IDENTIFIER>, <mailto:unsubscribe@YOUR-DOMAIN.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
What you must replace: the URL and the address are generated by your sending tool, one per recipient. The second line, by contrast, is literal — it's written exactly like that, and it's what separates true one-click unsubscribe (the RFC 8058 standard) from the old mailto: link Gmail no longer treats the same way.
How to check you have them: open one of your emails in Gmail, hit the "⋮" menu → "Show original", and search for List-Unsubscribe-Post. If it isn't there, it's a setting to enable at your sending tool — and it's probably your main cause.
Two things to know: the header isn't enough on its own. Google also requires "a clearly visible unsubscribe link in the message body". And once a request comes in, you have 48 hours to process it.
If you have no DMARC record at all, or one without a reporting address, you're flying blind: you'll never know what share of your messages fails or why. The minimum useful value is
v=DMARC1; p=none; rua=mailto:YOU@YOUR-DOMAIN.com— replace that address with one you actually read.
The path: go and see what Gmail thinks of you
Google publishes your reputation for free. It's the single most useful source on this page, and almost nobody opens it.
- Go to Google Postmaster Tools and sign in.
- Add your sending domain, and prove you own it by publishing the verification TXT record it gives you in your DNS zone.
- Wait 24 to 48 hours for data to appear.
The dashboards available, in Google's own words: Compliance status, Spam rate, IP Reputation, Domain Reputation, Feedback loop, Authentication (SPF, DKIM and DMARC pass rates), Encryption, Delivery errors.
The two to open first: Spam rate, to compare against the table above, and Authentication — if your DMARC pass rate isn't close to 100%, your problem isn't reputation, it's configuration, and you're on the wrong page (go read the three failures below).
Domain reputation comes in four grades, defined by Google as: Bad ("history of sending a high volume of spam regularly"), Low, Medium ("history of sending legitimate email, but occasionally sends spam") and High ("history of very low spam rates, and complies with Gmail's sender guidelines").
Two limits worth knowing before you worry about an empty chart. Google doesn't show data "on days when your outgoing email volume is low", to protect its users' privacy — a small sender will see a lot of gaps, and that's normal. And Google is replacing the interface with a new version (v2), in which the IP Reputation and Domain Reputation dashboards are being retired: Google considers them "not easily actionable for most senders". A new Compliance dashboard replaces them. If you can't find reputation any more, it isn't you.
The 3 silent failures behind a false "all clear"
1. Your SPF exceeds 10 DNS lookups — and stops working entirely
The nastiest failure in the whole subject: your SPF line looks perfect, every include: is legitimate, and SPF fails everywhere anyway.
The SPF standard caps the evaluation of a record at 10 DNS lookups. Every include:, a, mx or redirect consumes at least one — and include: values often contain more, invisibly to you. Past 10, the result isn't "partly fine": it's a permanent error (permerror), and your entire SPF is treated as failed.
You get there without noticing: your host, plus your office suite, plus your campaign tool, plus your CRM, plus last year's provider you never removed.
How you spot it: in your DMARC reports, SPF comes back as permerror or failing while the line looks correct. A checking tool tells you "too many DNS lookups". Supporting symptom: some recipients accept you, others don't, with no obvious pattern.
The fix: remove the services you no longer use — that's almost always where the excess is hiding. Only then consider moving some tools to a dedicated subdomain, which gets its own SPF record and its own budget of 10 lookups.
2. SPF passes, but it isn't aligned
Your provider shows you a green "SPF: OK". That's true — and it does nothing for DMARC.
DMARC doesn't ask "does SPF pass?", it asks "is the domain that passes SPF the same as the one in the From: header?" Plenty of tools send with their own envelope address, on their own domain, with their own valid SPF. SPF passes, brilliantly, for their domain. Yours isn't aligned, and DMARC fails.
How you spot it: in your reports, one row shows spf: pass and dmarc: fail together. That's the exact signature.
The fix: alignment is recovered through DKIM, and that's almost always the right answer — enable DKIM signing under your domain at that provider. It's how Mailchimp, Brevo and SendGrid work in the first place: they align through DKIM and don't need your SPF to mention them.
3. Your host's automatic setup never published DMARC
Several providers offer an "automatic" domain connection with reassuring green ticks. Two documented cases, and there are more: Hostinger's automatic setup publishes MX, SPF and DKIM — but DMARC is described in its own documentation as a record to configure "manually", and nothing in the flow requires you to. IONOS × Microsoft 365 automatic setup publishes domain verification, MX records and SPF — neither DKIM nor DMARC. And GoDaddy publishes no generic, provider-neutral help article about DMARC at all — its DMARC documentation only exists inside specific product flows.
The result: your domain shows "connected", "verified", "all green", and you have no DMARC record at all. Which puts you outside Gmail, Yahoo and Outlook's requirements since 2024, without a single screen ever telling you.
How you spot it: your provider's dashboard is green, but an independent scan finds no _dmarc record on your domain.
The fix: publish your DMARC record. Your provider's guide is linked below.
How long before it gets better
Here's the part nobody tells you: fixing the technical side is fast, repairing a reputation is slow.
- A DNS fix (SPF, DKIM, DMARC): visible in 5 minutes to 48 hours depending on your provider, and it applies to new messages immediately.
- Adding an unsubscribe header: effective from the next send.
- A damaged reputation: count several weeks of clean sending. The complaint rate is computed daily, but providers look at a trend, not a day. There's no reset button, and nobody can guarantee you'll get back to normal — the only method that works is sending less, to people who asked for it, and waiting.
- A new domain or a new IP: ramp up gradually. Google explicitly advises "increasing sending volumes gradually and monitoring recipients' spam reports". Going from 0 to 10,000 messages in a day is the best way to start out with a bad reputation.