How to Fix Email That Passes SPF but Still Fails DMARC

You set up SPF, you set up DKIM, and the test message comes back with both checks green. Then a receiver quarantines your mail anyway, or your DMARC reports show a long row of failures. Nothing is broken in the way you expect. SPF and DKIM can both pass and DMARC can still fail, because DMARC asks a different question from either of them. It does not ask whether some check passed. It asks whether a check passed for your domain, the one your recipient sees in the From address. That match is called alignment, and it is where almost every case like this lives.

What DMARC actually checks

SPF and DKIM each authenticate a domain, but not necessarily yours. SPF checks the sending server against the record for the Return-Path domain, the envelope sender where bounces go. That address is usually hidden from the recipient. DKIM checks the signature on the message, and the signature names its own domain in the d= tag. That domain can be your email provider's domain, not yours.

DMARC sits on top of both and adds one rule: at least one passing check must be aligned with the domain in the visible From header. One aligned pass is enough. You do not need both SPF and DKIM to align. But if SPF passes for your provider's bounce domain and DKIM passes for your provider's signing domain, and neither one is your domain, DMARC fails. The checks were real. They were just proving the identity of the wrong sender.

That is why this problem usually appears when mail goes through a third party: a newsletter platform, a CRM, an invoicing tool, a helpdesk, or a transactional mail service. Those services send on your behalf by default, using their own Return-Path and their own DKIM signature. Your own mailbox, sending directly, often passes DMARC fine. The third-party stream fails quietly until you tighten your DMARC policy or a receiver starts acting on it.

Read one message header before you change anything

Do not start by editing DNS records. Start by reading the authentication results on one real message that failed. In Gmail, open the message, choose Show original, and look for the Authentication-Results line. You need three values from the same message: the SPF result and its mailfrom domain, the DKIM result and its d= domain, and the DMARC result and its header.from domain.

The classic failing pattern looks like this: spf=pass for a bounce domain belonging to your vendor, dkim=pass with a d= domain belonging to the same vendor, and dmarc=fail for your own domain in the From header. If you see that pattern, you have your diagnosis. The vendor is authenticating itself, not you. No change to your SPF record will fix it on its own, because your SPF record was never the domain being checked.

If instead DKIM fails outright, or there is no DKIM signature at all, that is a different fault, and the fix is in the vendor's signing setup or the DNS record holding the public key. Run your domain through our SPF, DKIM and DMARC Checker first to confirm which records are actually published, so you are not chasing a header problem with a DNS change. The background to all three records is in our guide, SPF, DKIM and DMARC Explained.

The four patterns that cause this

Nearly every real case fits one of four patterns. Work through them in order, and stop at the one that matches your header. First, the third-party sender authenticates itself, as described above. Second, the vendor signs with your domain, but the signature does not verify. The public key may be missing, the selector may have changed after a key rotation, or the record may hold a typing error. Third, strict alignment is switched on. If your DMARC record sets aspf=s or adkim=s, subdomains no longer count as a match, so a Return-Path of mail.yourdomain.com will fail against a From domain of yourdomain.com, even though it would pass under the default relaxed mode. Fourth, forwarding broke a check that used to pass. A forwarder relays your message from its own server, so SPF checks the forwarder's address against your record and fails. DKIM can survive forwarding, which is exactly why aligned DKIM matters.

Fix the vendor setup, not your SPF record

For the most common pattern, the fix lives in the sending service, not in your DNS editor alone. Most reputable platforms offer a domain authentication or custom domain setup. It usually asks you to add one or two CNAME records they supply, and from then on the service signs with d=yourdomain.com instead of its own domain. That single change gives you aligned DKIM, and aligned DKIM alone is enough for DMARC to pass, even if the Return-Path still belongs to the vendor.

Where the platform also offers a custom Return-Path, sometimes called a custom bounce domain or custom MAIL FROM, take it as well. It puts the envelope sender on a subdomain of your own domain, so SPF aligns too. Do both when both are offered. Do the DKIM change first if you must choose, because DKIM survives forwarding and SPF does not.

While you are in the vendor's settings, check which From address the stream actually uses. A service sending from a subdomain, such as news.yourdomain.com, still aligns with the root domain under relaxed alignment, but not under strict alignment. Either keep alignment relaxed, or configure the service to sign for the exact From domain it sends from. Do not paper over this by loosening your DMARC policy. The policy is not the fault.

Check strict mode and key rotation

If your headers show a vendor domain that is a subdomain of your own, look at your DMARC record next. Open the record at _dmarc.yourdomain.com and look for aspf and adkim. If either is set to s, strict mode is on, and an exact match is required. Unless you have a specific reason to demand exact matches, and you have confirmed every sender uses the exact From domain, set it back to r for relaxed. Relaxed is the default when the tags are absent, and it is the right choice for most senders, because legitimate services routinely use subdomains.

If DKIM itself is failing, check the selector. The signature header names the selector, and the public key lives at selector._domainkey.yourdomain.com. If the key was rotated and the new record was never published, verification fails. Re-publish the exact record the service currently shows you, character for character. Keys copied by hand are a common source of silent errors. Copy, do not retype.

Roll out the fix without blocking your own mail

Resist the urge to jump straight to a reject policy to prove the fix worked. Until every legitimate sender shows an aligned pass in your DMARC reports, keep the policy at p=none and watch the rua reports. The reports list each sending source, its volume, and whether SPF and DKIM passed and aligned. Fix one source at a time, starting with the highest volume stream, and confirm in the next batch of reports that its failures have cleared.

When the reports are clean, step up gradually: quarantine first, and use the pct tag to apply the stricter policy to a small share of mail at first, then raise it in stages. Only move to reject when the reports have been clean for a full sending cycle, including monthly invoices and quarterly newsletters, not just daily mail. A sender you forgot about will only reveal itself in its own cycle. If deliverability still looks wrong after alignment is fixed, run an Email Deliverability Test to check for separate problems, such as a blacklist listing, rather than assuming DMARC is still at fault.

What to do first

Pick one failing message, read its Authentication-Results header, and write down the three domains: the Return-Path domain, the DKIM d= domain, and the From domain. If neither of the first two matches the third, open the sending service's domain authentication settings and set up custom DKIM for your domain. Verify it with a fresh test message, then check your DMARC reports over the next few days to confirm the failures for that source have stopped. That one sequence, header first, vendor setup second, reports third, fixes most cases of mail that passes SPF but still fails DMARC, without touching a record that was never the problem.