Why DMARC fails, and how to fix it

How to find out why a message failed DMARC

You have two sources of evidence, and they answer different questions.

• DMARC aggregate reports tell you which sources fail and how much mail they send. Each row gives a sending IP, a message count, the DMARC verdict for SPF and DKIM, and the raw results with the domains that were checked. Upload a report to the DMARC report analyzer to see it as a table, or read how to read DMARC aggregate reports.
• Message headers tell you why one message failed. Send a test to a Gmail or Outlook.com mailbox, open the original message (“Show original” in Gmail) and find the Authentication-Results header added by the receiver.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp-mail.example.net header.s=s1;
       spf=pass (google.com: domain of bounce-123@esp-mail.example.net designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce-123@esp-mail.example.net;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Read it in three steps. Did SPF and DKIM pass at all? For which domain (smtp.mailfrom for SPF, header.d or header.i for DKIM)? Does that domain match header.from? Here both pass, but for esp-mail.example.net, not example.com. That is an alignment failure, and it is the single most common reason DMARC fails. DMARC alignment explains the rule in detail.

DMARC failure symptoms, causes and fixes

Third-party senders that aren’t aligned

Marketing platforms, help desks, CRMs and billing tools send mail with your address in From, but out of the box they sign DKIM with their own domain and use their own bounce address for SPF. Both checks pass, so the mail looks fine to the vendor, but neither domain is yours, so DMARC fails. In reports you see a source with a vendor’s reverse DNS, spf and dkim both fail under policy_evaluated, while auth_results shows passes for the vendor’s domains.

The fix is the vendor’s domain authentication (sometimes called “sender authentication” or “domain verification”). You add DKIM records (usually CNAMEs) for your domain, and often a CNAME that makes the return path a subdomain of yours. DKIM is the one to prioritize: it aligns on its own and survives forwarding. There are step-by-step guides for SendGrid, Mailchimp, HubSpot, Salesforce, Amazon SES, Mailgun, Postmark, Brevo and Klaviyo.

Google Workspace or Microsoft 365 without your own DKIM

Both platforms sign outgoing mail even if you never set up DKIM, but with a domain of their own. Microsoft 365 signs with your tenant’s initial *.onmicrosoft.com domain; Google Workspace signs with a gappssmtp.com domain. The signature verifies, so headers show dkim=pass, but it doesn’t align with your From domain. Your mail then passes DMARC on SPF alone, and fails the moment it’s forwarded.

In reports, look for your own mail platform’s IPs with DKIM passing for the wrong domain. The fix is to publish the DKIM record and turn on signing for your domain: see the Google Workspace and Microsoft 365 guides. Zoho Mail has the same pattern (Zoho guide).

SPF PermError: more than 10 DNS lookups

SPF allows at most 10 mechanisms that need a DNS lookup (include, a, mx, ptr, exists and redirect), counted recursively through every include. Go over and the result is permerror, which DMARC treats as a failure for SPF. Every sender that relies on SPF breaks at once, typically right after someone adds one more include. Headers show spf=permerror; reports show permerror in auth_results. The SPF checker counts your lookups, and fixing too many DNS lookups covers the options. DMARC Dojo refuses SPF changes that would go over the limit, so this can’t happen by accident on a hosted record.

SPF passes, but for the vendor’s bounce domain

SPF checks the envelope sender (Return-Path, smtp.mailfrom), not the From header. Most services use a bounce address on their own domain so they can process bounces. Adding the vendor’s include to your SPF record doesn’t change this: SPF is checked against the vendor’s bounce domain, not yours, so the include does nothing for DMARC. Either configure a custom return path (a subdomain like bounce.example.com CNAMEd to the vendor, where offered) or rely on aligned DKIM and skip the include, which also saves SPF lookups.

Forwarded mail: SPF breaks, DKIM usually survives

When a recipient forwards mail automatically (a university alias, a rule to a personal account), the forwarding server resends it from its own IP. That IP isn’t in your SPF record, so SPF fails. DKIM signs the message itself, so if the forwarder doesn’t change the content, DKIM still passes and DMARC passes on it. In reports, forwarding shows up as a scatter of low-volume sources at other mail providers, with SPF failing and DKIM passing and aligned. That is expected and needs no fix, provided every legitimate stream signs with aligned DKIM. It’s why DKIM matters more than SPF before you enforce.

Mailing lists that modify messages

Discussion lists often add a subject tag or a footer, which breaks the DKIM signature, and they resend from their own servers, which breaks SPF. With both gone, DMARC fails. Two things help. Many list servers rewrite the From address to the list’s own domain when the author’s domain has a strict DMARC policy, which avoids the failure entirely. And ARC (Authenticated Received Chain) lets the list record the results it saw on arrival, so receivers that trust the list can accept the message despite the DMARC failure. Gmail and Microsoft both use ARC. You can’t fix a list server from your side, so expect a small, persistent failure rate from lists and don’t let it block enforcement.

Subdomain senders with strict alignment

With the default relaxed alignment, mail.example.com aligns with example.com. With adkim=s or aspf=s, the domains must match exactly, so a vendor that signs as mail.example.com for a From address at example.com fails. The symptom is a sender that passed until you made alignment strict. Unless you have a specific reason for strict mode, use relaxed.

DNS typos and duplicate records

• Two SPF records. A domain may have only one TXT record starting with v=spf1. Two give permerror. Merge them.
• Two DMARC records. Receivers ignore both, so you have no policy. Keep one.
• Wrong host name. Many DNS hosts append the domain for you, so typing _dmarc.example.com creates _dmarc.example.com.example.com. Enter _dmarc.
• Syntax errors. A missing v= tag, a stray quote, a typo like inlcude: or smart quotes pasted from a document all break the record.

These errors affect every message at once, so they appear in reports as a sudden drop in pass rate across all sources.

Deleted, expired or rotated DKIM keys

A DKIM signature can only be verified while the public key is published at selector._domainkey.example.com. If someone deletes the record during a DNS cleanup, a vendor rotates to a new selector you never published, or a migration drops the CNAMEs, signatures stop verifying. Depending on the receiver, headers show dkim=fail, dkim=permerror or dkim=neutral with a note such as “no key for signature”. The s= tag in the DKIM-Signature header names the selector to look up; check it with the DKIM checker. When you rotate keys yourself, publish the new key, switch signing, and leave the old key in DNS for a few days so mail in transit still verifies.

When the failures aren’t yours

Not every failure is a problem to fix. Sources with no connection to you, reverse DNS on residential or hosting networks, and both SPF and DKIM failing are usually spoofing or spam using your domain. Those are exactly what DMARC enforcement is for. DMARC Dojo labels each source in your reports by provider and reverse DNS so you can separate your own senders from impostors quickly.