Newsletter emails failing DMARC
Newsletter emails failing DMARC
Open a delivered copy of your last campaign, choose Show original or View headers, and read the Authentication-Results line. If it says dmarc=fail with header.from= set to your own domain, while spf=pass and dkim=pass on the same line sit against the platform’s domain, your platform authenticated itself and nothing authenticated you. The fix is the platform’s custom domain authentication feature: its DKIM CNAMEs in your DNS, plus a custom bounce domain where one is offered, so the signature carries your domain and DMARC has something to align with.
The line that tells you what happened
Here is the shape of the header you’re looking for, with the domains generalised:
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounce.platform.example;
dkim=pass header.d=platform.example;
dmarc=fail header.from=yourdomain.com
Read it as three separate verdicts. SPF passed, for the platform’s bounce domain. DKIM passed, for the platform’s signing domain. DMARC then looked at the domain in your From header, found that neither of those passes belonged to it, and failed the message.
The platform’s dashboard is telling the truth when it shows a green tick. From where it stands, authentication is working. The receiver is also telling the truth, because the authentication it saw was for a domain that isn’t yours.
Why the dashboard and the receiver disagree
Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header. That’s the address bounces go to, and out of the box an ESP puts its own bounce domain there so it can process the bounces for you. SPF passes, cleanly, for the platform.
DKIM is a signature, and the signer chooses which domain the signature names. Without custom domain authentication, most platforms sign with their own domain. DKIM passes, again for the platform.
DMARC doesn’t care whether SPF or DKIM passed in the abstract. It asks whether either one passed for the domain in the From header, and that match is called alignment. One aligned leg is a full DMARC pass, so aligned DKIM on its own is enough where the platform offers no custom bounce domain. With neither leg aligned, your From domain fails DMARC, and whatever policy you’ve published (or whatever the receiver assumes when you haven’t) decides what happens next.
The switch that moves the DKIM signature onto your domain is a single feature in the platform, and it produces a handful of CNAME records. Before you add them, look at what your domain publishes today, because the fix lands differently depending on whether you already have a DMARC record and what its policy says.
What the switch is called on each platform
Each platform has the same feature under a different name, and the thing that identifies it is the output: a small set of CNAME records for your DNS.
In Mailchimp the feature is called Domain authentication. It produces DKIM CNAMEs at k2._domainkey and k3._domainkey. Mailchimp is DKIM-only alignment and no longer uses an SPF include, so don’t add one. A leftover include:servers.mcsv.net in your SPF record does nothing for DMARC and burns DNS-lookup budget you may need elsewhere.
In Brevo the feature is called Authenticate your domain. It produces a DKIM CNAME set plus a verification record, the TXT string that begins brevo-code. That string is common enough to count: in the September 2026 census, brevo-code sits on 1,286,721 domains that carry at least one apex TXT record.
In Klaviyo the feature is called Dedicated sending domain. It produces DKIM CNAMEs plus a bounce (Return-Path) subdomain, and because the bounce domain is yours, the dedicated domain gives you SPF alignment as well as DKIM.
In SendGrid the feature is called Domain authentication, with automated security switched on. It produces a CNAME set covering both DKIM and the return-path, and needs no SPF include.
None of these platforms wants an include: added to your SPF record. Modern ESP authentication is CNAME-delegated, and that’s deliberate: the platform rotates its DKIM keys behind the delegated names without you touching DNS again. If you’ve been adding includes out of habit, the SPF pillar covers what the lookup limit costs you when the record fills up.
Adding the CNAMEs without mangling them
The commonest way this fix fails is the DNS panel appending your zone to a host you’ve already written in full. You paste k2._domainkey.yourdomain.com into the host field, the panel adds the zone, and the record that lands is k2._domainkey.yourdomain.com.yourdomain.com. The platform’s verification then looks for a name that doesn’t exist.
Check which convention your panel uses before you paste. If it appends the domain, enter the host part only, k2._domainkey, and let the panel finish the name. If it wants the fully qualified name, paste the whole thing. Either way, query the finished name afterwards and confirm it answers with the platform’s target.
Where the platform offers a custom bounce domain, set it. That puts your subdomain on the Return-Path, so SPF aligns too and DMARC has two ways to pass instead of one. Where the platform doesn’t offer it, aligned DKIM alone carries the message, and that’s a full pass rather than a partial one.
The From address has to be on your own domain. A freemail From address can’t be rescued by any DNS record: freemail domains publish strict DMARC policies, the ESP can never align with them, and the mail is rejected or junked. Move the campaign to something like [email protected] before you verify, or the verification will pass and the campaign will still fail.
What changed in February 2024
Until then, riding the platform’s own authentication and sending from anything mostly worked, because few receivers checked alignment for bulk mail and fewer acted on it. In February 2024 Google and Yahoo began enforcing bulk-sender requirements: aligned authentication for the From domain, a published DMARC policy, one-click unsubscribe, and spam-rate limits.
Campaigns without aligned authentication started landing in spam or bouncing outright, which is why every serious ESP now pushes custom domain authentication during onboarding. The requirement also closed the freemail route for good, since no ESP can align with a mailbox provider’s domain.
A published DMARC policy is part of that list, and it’s the part most domains are still missing. Of the 316,600,902 domains carrying a grade in the September 2026 census, 238,156,049 (75.2%) have no DMARC record at all. If your domain is one of them, the platform fix above aligns your signature, and a DMARC record is the next ten minutes. The DMARC pillar walks through the record itself.
Still failing after you turned it on
Three causes account for most of the cases where domain authentication is on and the header still reads dmarc=fail. The CNAMEs were mangled by a zone-appending panel, so the platform is signing with a key the receiver can’t fetch. The campaign’s From domain doesn’t match the domain you authenticated, which happens when a brand sends from one domain and authenticated another, or from a subdomain the platform doesn’t know about. Or a different sending source is failing alongside the newsletter, and the failure you’re reading belongs to a CRM, a helpdesk or an invoicing tool rather than the campaign platform.
Pull the headers from a fresh test campaign and look at header.d= on the DKIM line. If it names your domain, the platform’s leg is fixed and the failures you’re seeing come from somewhere else. If it still names the platform, the CNAMEs haven’t landed or the From domain isn’t the one you authenticated. The DKIM pillar shows how to query a selector by hand when the platform’s verification is ambiguous.
Domain authentication removes unaligned mail as a cause of spam placement. It doesn’t fix list quality. Complaint rates and a missing one-click unsubscribe keep mail in spam even when authentication is correct, so if the headers are clean and placement hasn’t moved, the next place to look is the list itself.
The order that works
Turn the feature on in the platform. Add the CNAMEs, host part only where the panel appends the zone. Set the custom bounce domain if one is offered. Move the From address onto your own domain if it’s still on freemail. Verify in the platform, then send yourself a campaign and read the headers: dkim=pass with header.d= on your domain, and dmarc=pass on the same line.
Then run the free scan on your domain. It reads what your DNS publishes for SPF, DKIM and DMARC from the outside, which is the view the receiver has, and it tells you whether the DMARC record you’re relying on is there and what its policy will do to the next unaligned message.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.