DEV Community: Vadim Ivanov

Your email passes SPF and DKIM but still fails DMARC. Here's why

Vadim Ivanov — Tue, 14 Jul 2026 19:16:58 +0000

Your email passes SPF and DKIM but still fails DMARC. Here's why

You set up SPF. You set up DKIM. You send a test message and both come back pass. Then your DMARC reports show fail, or a receiver quarantines the mail anyway. It reads like a contradiction, and it's the single most common DMARC question I run into.

The short version: DMARC doesn't care that SPF or DKIM passed. It cares that they passed for your domain, the one in the From address your recipient actually sees. That extra requirement is called alignment, and it's where almost every "passes auth but fails DMARC" case lives.

What DMARC actually checks

SPF and DKIM each authenticate a domain, but not always the domain you'd assume.

SPF authenticates the Return-Path, the envelope sender (RFC5321.MailFrom) where bounces go. It has nothing to do with the visible From address.
DKIM authenticates whatever domain sits in the signature's d= tag. That can be your domain, or it can be your email provider's.

DMARC sits on top and adds one rule: at least one of those authenticated domains has to align with the domain in the visible From header. Per RFC 7489, a message passes DMARC when at least one mechanism produces a pass, and that pass is based on an identifier that is in alignment. One aligned pass is enough. You don't need both.

So you can have SPF pass for a Return-Path of bounces.sendgrid.net, and a valid DKIM signature with d=sendgrid.net, and still fail DMARC, because neither of those is your domain and your From header says you@yourdomain.com.

Relaxed vs strict, and the organizational domain

Alignment has two modes, set by the aspf and adkim tags in your DMARC record. Both default to relaxed.

Relaxed (the default): the two domains only need to share the same organizational domain, the registrable part. news.yourdomain.com aligns with yourdomain.com.
Strict: the fully qualified names must match exactly, so news.yourdomain.com would not align with yourdomain.com.

That organizational domain is worked out using the Public Suffix List, which is how a checker knows yourdomain.co.uk is the registrable name rather than co.uk. This matters more than it sounds: I've seen local DMARC filters reject legitimate subdomain mail purely because they had no Public Suffix List configured and couldn't reduce the two names to the same org domain.

Unless you deliberately set aspf=s or adkim=s, you are in relaxed mode, which is more forgiving than most people expect.

The failure patterns that actually bite

Nearly every real "passes auth, fails DMARC" case is one of these four.

1. Your provider sends with its own Return-Path and doesn't sign as you. This is the big one. Marketing and transactional platforms send from their own bounce domain, so SPF authenticates their domain. If they also sign with d= set to their domain instead of yours, nothing aligns with your From, and DMARC fails even though SPF and DKIM both technically passed. The fix lives in the platform: either a custom Return-Path under your own domain so SPF aligns, or an aligned DKIM signature with d=yourdomain.com. Most serious platforms support at least one. Turn it on.

2. Forwarding. A forwarder relays your message from its own servers, so SPF now checks the forwarder's IP against your SPF record and fails. SPF alignment is gone. If your only DKIM signature also got mangled in transit (a footer appended, headers rewritten), DKIM breaks too, and a message you genuinely sent fails DMARC. This is exactly why a DKIM signature that survives forwarding is worth more to DMARC than SPF is.

3. A broken DKIM signature leaves only SPF, and SPF doesn't align. If your aligned DKIM signature fails to verify, maybe a rotated key, a DNS TXT record split badly, or an intermittent DNS lookup failure, DMARC falls back to SPF. If SPF passes only for a non-aligned Return-Path, you fail. The pass you saw in a quick test was the wrong mechanism carrying you.

4. Strict mode you didn't mean to set. If aspf=s or adkim=s is in your record and you send from a subdomain, or your provider signs with the org domain while you send from a subdomain, exact-match rejects an alignment that relaxed mode would have accepted.

How to diagnose it in about two minutes

Open the raw headers of a message that failed and read the Authentication-Results line. Don't stop at spf=pass and dkim=pass. Look at the domains next to them.

For SPF, compare smtp.mailfrom (the Return-Path) with your From domain.
For DKIM, compare header.d (the d= tag) with your From domain.

If neither matches your From domain, even under the relaxed org-domain rule, that's your answer: authenticated, but not aligned. If picking through raw headers by hand isn't appealing, an email header analyzer will pull those domains out and show you whether SPF and DKIM line up with your From. Your DMARC aggregate reports (the rua address) show the same thing at scale. They break every sending source down by whether SPF and DKIM aligned, which is the fastest way to find the one stream that's failing.

The fix, in one line

Get one identifier to align with your From domain, and prefer DKIM. An aligned DKIM signature with d= set to your domain survives forwarding and doesn't depend on the Return-Path, so it is the sturdier of the two. Align SPF as well if your platform makes it easy with a custom Return-Path under your domain, but if you only fix one thing, make it DKIM.

Alignment isn't DMARC being pedantic. It is the whole point of the standard. SPF and DKIM prove that some domain authorized the mail; alignment is what ties that proof to the name your recipient actually reads in the From line. Without it, a spammer could pass their own SPF and DKIM all day long and still drop your brand into the From field.

97.8% of the top 10,000 domains have no MTA-STS. Here's how to be in the other 2%

Vadim Ivanov — Sat, 04 Jul 2026 19:17:19 +0000

Of the 10,000 most-visited domains on the web, 97.8% have no MTA-STS policy at all. Not misconfigured. Not weak. Just absent. I scanned the Tranco top 10,000 in June and MTA-STS is the single most-ignored email-security control I measured, by a wide margin.

For comparison, in the same scan a third of those domains had no DMARC, which people already treat as a problem worth writing about. Missing MTA-STS is nearly three times as common as that, and almost nobody mentions it.

What MTA-STS actually protects

SMTP encryption is opportunistic. When one mail server hands a message to another, it tries STARTTLS to upgrade the connection to TLS, but if the upgrade fails it usually just delivers in plaintext instead of refusing. That fallback is the hole. An attacker positioned between the two servers can strip the STARTTLS offer, or present a bad certificate, and the sending server shrugs and delivers over an unencrypted connection anyway. The mail goes through, and nobody sees a downgrade happen.

MTA-STS (RFC 8461) closes that hole. You publish a policy that says, in effect, "mail for my domain must be delivered over TLS, to a server whose certificate actually validates and matches one of my listed MX hosts." A sending server that supports MTA-STS reads that policy and, in enforce mode, refuses to deliver if the connection can't be secured. Downgrade stripped? Certificate wrong? The message is held, not leaked.

TLS-RPT (RFC 8460) is the companion. It's a DNS record that asks other providers to send you a daily report of how TLS negotiation went for mail to your domain, including failures. It's how you find out something is wrong before it becomes a habit. In the scan, 97.1% of domains had no TLS-RPT record either, so almost everyone who skips the policy also skips the reporting that would tell them they need one.

Why adoption is this low

Two reasons, and neither is that MTA-STS is hard to understand.

The first is moving parts. DMARC is one DNS record. MTA-STS is a DNS record plus a policy file served over HTTPS at a fixed well-known URL on a dedicated subdomain, plus your MX hosts presenting valid certificates that match the policy. That's a web endpoint, a DNS entry, and mail-server TLS all having to agree. None of it is difficult, but it's more surface than pasting one TXT record, and more surface is where adoption goes to die.

The second is that nothing forced it. DMARC adoption jumped when Google and Yahoo made authentication a requirement for bulk senders, a hard deadline with deliverability consequences. MTA-STS has no equivalent forcing function. No inbox provider bounces your mail for lacking it, so it sits permanently at the bottom of the list, behind every task that has a deadline attached.

Here's the part that surprised me: it isn't a small-domain problem. Among the top 1,000 domains, 96.9% still have no MTA-STS, barely better than the long tail. And the few that do adopt it tend to mean it. Of the roughly 220 domains publishing a policy, 59% run it in enforce mode and most of the rest in testing. So this isn't a case of people turning it on and leaving it half-configured. It's a case of almost nobody turning it on at all.

How to be in the other 2%

The rollout mirrors DMARC's, and you should treat it the same way: report first, enforce later.

Stand up the policy file. Serve https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with your MX hosts listed, max_age set, and start at mode: testing. Testing mode changes nothing about delivery yet; it just makes your policy visible.
Publish the DNS record. Add the _mta-sts TXT record with a version and an id. You bump the id whenever the policy changes so senders know to refetch.
Turn on TLS-RPT. Add the _smtp._tls TXT record pointing at a mailbox. Now you get reports about TLS successes and failures to your domain.
Read the reports, then enforce. Watch a couple of weeks of TLS-RPT data. If your MX hosts are negotiating TLS cleanly, flip the policy from testing to enforce. If something's failing, you'll see it in the reports before it can hurt you, which is the whole point of starting in testing.

The certificate on your MX hosts has to be valid and has to match a name in your policy, so the most common snag is a mail server with a self-signed or mismatched cert that was fine under opportunistic TLS and isn't fine under a policy that checks. Testing mode surfaces exactly that, which is why you don't skip it.

The takeaway

MTA-STS is the rare control where the hard part is genuinely just doing it. The spec is stable, the failure mode it prevents is real, and adoption is at 2% not because it's controversial but because nothing makes anyone finish it. If you already run DMARC, you've done the harder conceptual work; MTA-STS is mostly plumbing on top. The 2% who bothered aren't smarter, they just got to it.

I published the full aggregate from this scan as an open dataset (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI across the Tranco top 10,000, aggregate only) here: https://github.com/relaymetry/state-of-email-authentication — it's CC BY 4.0, so use the numbers however you like.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker. If you want to check your own domain's MTA-STS policy and TLS-RPT record, Relaymetry walks through it here, no signup required.

SPF's 10-lookup limit: why your SPF silently fails, and how to fix it

Vadim Ivanov — Fri, 03 Jul 2026 13:53:40 +0000

Your SPF record can be perfectly valid, publish without a single error, and still fail every time it is checked. The reason is a rule most people never learn until it bites them: SPF is allowed at most ten DNS lookups per evaluation, and going over does not degrade gracefully. It fails outright.

In a scan I ran across the top 10,000 domains earlier this year, 1.7% were already over the limit. That sounds small until you realize these are among the most-managed domains on the web, and the number only goes up as a domain adds senders. It is the kind of problem you grow into without noticing.

What the limit actually is

RFC 7208, the SPF spec, caps the number of mechanisms that require a DNS lookup at ten per evaluation (section 4.6.4). The mechanisms that count are include, a, mx, ptr, and exists, plus the redirect modifier. The ones that do not count are ip4, ip6, and all, because they are answered from the record itself without another query.

Cross ten lookups and the evaluation returns permerror. That is not a soft "neutral" result you can ignore. A permerror means SPF produced no usable answer, so it cannot give you a pass. For DMARC that counts the same as a fail, and many receivers treat a standalone SPF permerror as a failure on its own.

Why it is silent

Nothing warns you. The record is syntactically fine, so it publishes cleanly and looks correct in your DNS panel. The count is only evaluated at the receiver, at send time, by expanding every include down its full chain. You do not see the failure; your recipients' mail servers do, and the only symptom is mail that quietly stops authenticating.

Why it creeps up on you

The culprit is almost always include: chains. An include does not cost one lookup, it costs however many the included record costs, recursively. include:_spf.google.com is around four lookups on its own, because it chains to several sub-records. Add Microsoft 365, a marketing platform, a helpdesk, an invoicing tool, and each one brings its own chain. Nobody adds "six lookups" on purpose; you add include:sendgrid.net, it looks like one line, and you are quietly over.

How to check

Count resolved lookups, not lines. Reading the record by eye undercounts badly because the expensive part is hidden inside the includes. Use a checker that expands every include and reports the real total against the limit of ten. That one number tells you whether you have a problem and how much headroom is left.

How to fix it

In rough order of how much they buy you:

Remove what you no longer use. The fastest win is usually deleting includes for senders you stopped using a year ago. Audit the list against who actually sends your mail.
Drop redundant mechanisms. a and mx each cost a lookup. If your MX hosts do not send outbound mail, you do not need mx in SPF at all.
Use the provider's consolidated include. Some providers replaced a sprawl of sub-records with one: Microsoft 365 is the classic example, where a single include:spf.protection.outlook.com replaces the old pile of entries.
Flatten stable senders. Replace an include: with the actual ip4:/ip6: ranges it resolves to. Those do not count toward the limit, so every include you flatten frees its lookups. The catch is maintenance: if that provider changes its IPs, your record is silently wrong until you update it, so only flatten senders whose ranges are stable. Your own infrastructure is a safe candidate; a big cloud provider's is not, keep those as includes.
Split senders onto subdomains. The limit is per record. If a source only ever sends as mktg.example.com, give that subdomain its own SPF record and move its includes there, freeing lookups on your main domain.

The part people miss

SPF is not your only authentication leg, and it is the one with this limit. Aligned DKIM has no lookup cap and survives forwarding, where SPF breaks anyway. If you are fighting to squeeze a sender under the SPF limit, the better move is often to make sure that sender signs with aligned DKIM instead, and stop relying on SPF for it. DMARC only needs one of the two to pass and align, so a sender you cannot fit into SPF can still authenticate cleanly on DKIM.

The takeaway

The ten-lookup limit is a slow-motion failure: nothing breaks the day you cross it, and by the time you notice, some of your mail has been quietly failing for a while. Check your real resolved-lookup count now, trim what you do not need, flatten the stable senders, and lean on aligned DKIM for the rest. That cleanup is worth the hour: it is the difference between SPF that passes and SPF that silently does not.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker that expands your includes and shows the real lookup count. I wrote up the fixes in more detail here if you want to work through your own record.

How to safely move your DMARC policy from p=none to p=reject

Vadim Ivanov — Thu, 02 Jul 2026 00:27:26 +0000

Publishing a DMARC record is the easy part. Most domains do it: in a scan I ran across the top 10,000 domains earlier this year, two thirds had a DMARC record, and only about half of those actually enforce it. The hard part, the part most never finish, is moving off p=none.

p=none monitors and enforces nothing. It asks receivers to report what they see and take no action on failures, which is exactly the right first step and exactly where most deployments quietly stall. A record stuck at p=none looks like protection and provides none: anyone can still spoof your domain and receivers will deliver it. The whole point of DMARC, stopping unauthenticated mail that uses your From address, only kicks in at p=quarantine or p=reject.

Here is how to get there without blocking your own legitimate mail on the way.

What the three policies actually do

p=none: report only, no enforcement.
p=quarantine: mail that fails DMARC is treated as suspicious, usually sent to spam.
p=reject: mail that fails DMARC is rejected outright at the SMTP layer.

DMARC fails for a message when neither SPF nor DKIM produces a result that both passes and aligns with the domain in the visible From header. So the safe path is really one task: make sure every legitimate source of your mail produces an aligned pass before you turn on enforcement.

Why you can't just flip to p=reject

If you jump straight from p=none to p=reject, every legitimate sender that is not yet aligned starts getting rejected. That is almost never zero senders. Your marketing platform, your helpdesk, your invoicing system, that one server someone set up in 2019, mail forwarded by employees to personal accounts: all of these can be sending as your domain without aligned authentication. p=reject on day one turns those into hard bounces, and the first you hear of it is a customer who never got their receipt.

The reports are what let you find those senders before they become a problem.

Step 1: publish p=none and collect reports

Start with:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

rua is the aggregate-report address. Receivers send a daily XML summary of every source sending as your domain and whether it passed SPF, DKIM, and alignment. Leave it running at least a couple of weeks so you capture the monthly senders (billing, newsletters) as well as the daily ones. You can add ruf for per-message failure reports, but most receivers do not send them and they can contain message content, so aggregate rua is what you will actually work from.

Step 2: read the reports and inventory your senders

Aggregate reports are XML and painful by eye past a handful. Feed them to a DMARC report viewer and you get a clean list: for each source, how many messages, and whether SPF and DKIM passed and aligned. Sort every source into two buckets: legitimate senders you recognize (your servers, your ESPs, your SaaS tools), and everything else. For each legitimate one, ask: does it produce an aligned pass on SPF or DKIM? You only need one of the two to align, not both.

Step 3: fix each legitimate source until it aligns

This is the real work. For each legitimate source that is not yet aligned:

ESPs and SaaS senders (Mailchimp, SendGrid, your helpdesk): almost all support aligned DKIM by publishing a CNAME under your domain pointing at their signing key. Turn it on. Aligned DKIM is the better fix because it survives forwarding, where SPF breaks.
Your own servers: put their IPs in SPF and, ideally, DKIM-sign with a key published under your domain.
Anything that cannot align (a legacy system, a notifier with no DKIM support): move it behind a relay that can sign, give it its own subdomain so it does not affect your main domain's policy, or retire it.

Keep watching the reports. As you fix sources, their aligned-pass rate climbs. When every source you recognize is passing and aligned, you are ready to enforce.

Step 4: ramp to quarantine, then reject

Do not go straight to reject even now. Move to quarantine first:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Watch the reports for a week or two. Quarantine is forgiving: a sender you missed lands in spam rather than vanishing, so you get a warning instead of a catastrophe. Fix what shows up, then move to reject:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Some guides suggest the pct tag to enforce on a fraction of mail first (pct=25, then 50, then 100). It can help, but receiver support for it is uneven, so treat the quarantine-then-reject progression itself as the reliable ramp and pct as a nice-to-have, not the plan.

A few things that bite people

Subdomains: a subdomain with no DMARC record of its own falls back to your organizational domain's policy, so p=reject does cover them by default. Use the sp= tag if you want subdomains to have a different policy, and don't assume without checking.
Forwarding and mailing lists: these break SPF always and DKIM when they modify the message, so some forwarded copies of your mail will fail DMARC no matter what you do. That is expected. Aligned DKIM survives clean forwarders, and ARC-aware receivers honor a trusted forwarder's chain. Don't weaken your policy over forwarded failures; they are noise, not your problem.
Keep reading the reports after you reach reject. New senders appear (a new tool, a new campaign), and you want to catch them before someone complains.

The takeaway

None of this is hard, it is just patient. The domains stuck at p=none are not stuck because the last step is difficult; they are stuck because nobody went back to read the reports and finish. Block out the couple of weeks, work the sources one at a time, and you get real protection instead of a record that only looks like it.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker. I wrote a step-by-step version with the exact record changes here if you want a checklist to work from.

What 10,000 domains actually publish for email authentication in 2026

Vadim Ivanov — Sat, 27 Jun 2026 09:51:27 +0000

Email authentication has been "solved" on paper for years. SPF, DKIM, and DMARC are old standards, every deliverability guide repeats them, and Google and Yahoo made DMARC effectively mandatory for bulk senders in 2024. So I expected the top of the web to be in good shape.

In June 2026 I ran SPF, DKIM, DMARC, and MTA-STS checks across the Tranco top 10,000 domains, using public resolvers (1.1.1.1 and 8.8.8.8) and the same checks my own tool runs. The records are public DNS, so anyone can reproduce this. The picture is worse than the "solved problem" framing suggests, and the interesting part is not adoption, it is where people stop.

A third of the top 10k still have no DMARC

3,318 of the 9,937 domains that resolved (33.4%) publish no DMARC record at all. These are not obscure sites, they are the most-visited domains on the web. Without DMARC a receiver has no published instruction for what to do when SPF and DKIM fail, and you get none of the aggregate reporting that tells you who is sending as you.

It does get better at the very top. Among the top 1,000 domains, 28.4% have no DMARC, versus 34% across the rest of the 10k. Better, not good.

The real problem is p=none, not missing records

This is the number that actually matters. Of the 6,619 domains that do publish DMARC, only 46.5% are at p=reject. About a quarter (26%) are still sitting at p=none.

p=none is monitor-only. It asks receivers to report what they see and to enforce nothing. It is the correct first step: publish p=none, collect aggregate reports, fix the sources that should be passing, then tighten the policy. The trouble is that p=none is also where most deployments quietly stop. The reports start arriving, nobody reads them, and the domain sits unprotected behind a policy that does nothing while looking like progress.

Moving from p=none to p=reject is the step that turns DMARC from a dashboard into a defense, and it is the step most people never finish. I wrote up the safe way to make that move, since it is the question I get most often: read your aggregate reports until every legitimate source aligns, go to p=quarantine, then p=reject, raising pct if you want to ease in.

SPF is widespread but quietly broken on some domains

25% of the domains have no SPF record, higher than I expected for the top of the web. A smaller but more interesting group, 1.7%, publish an SPF record that exceeds the 10 DNS-lookup limit from RFC 7208. Once you cross that limit the record returns a permerror, so SPF effectively fails even though a record exists and looks fine to the eye. This usually creeps in through include: chains: you add a few SaaS senders, each brings its own includes, and one day you are over ten lookups without having changed anything visible. It is the kind of failure you only catch if you count.

Transport security is basically unused

This is the most lopsided result in the scan. 97.8% of the domains have no MTA-STS policy (RFC 8461), and 97.1% publish no TLS-RPT. MTA-STS is what lets a sending server insist on TLS and a valid certificate when delivering to you, closing the downgrade gap that plain STARTTLS leaves open. Nearly the entire top 10k has skipped it. Some of that is fair, MTA-STS needs a policy file served over HTTPS on an mta-sts. subdomain plus a DNS record, so it is more work than a single TXT entry. But "more work" does not explain a 2% adoption rate at the top of the web.

BIMI is still early

8.9% of domains publish a BIMI record, climbing to 15.7% in the top 1,000. That fits: BIMI rewards brands that already enforce DMARC and have budget for a verified mark. It is the one area where low adoption is genuinely fine, BIMI is optional and brand-driven, not a security baseline.

What I take from this

The headline is not "people don't adopt email auth." Most of the top 10k publish SPF and DMARC. The gap is follow-through: a DMARC record stuck at p=none, an SPF record one include over the limit, a transport-security feature nobody enabled. Each of these looks like a configured domain and behaves like an unconfigured one.

If you own a sending domain, the highest-value 20 minutes you can spend is checking which of these you are actually in: is your DMARC enforcing or just watching, is your SPF under the lookup limit, and have you ever published an MTA-STS policy. The records are public, so the answer is one DNS lookup away.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker, which is the tool I used to run this scan. The numbers are from a June 2026 crawl of the Tranco top 10,000; happy to share more on the methodology if anyone wants it.