Why Is My DMARC Failing? Five Common Causes and How to Fix Them
DMARC failures fall into five categories, and they're not equally common. This guide covers each one in order of frequency: what it looks like in your aggregate report, why it happens, and how to fix it.
Use the DMARC XML Analyzer to pull up your report while you read.
1. SPF alignment mismatch from an ESP using its own envelope-from
This is the most common failure, and it surprises developers who assumed "SPF passes, so DMARC passes."
What the report shows:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
<auth_results>
<spf>
<domain>mcsv.net</domain>
<result>pass</result>
</spf>
</auth_results>
SPF passed for mcsv.net (or sendgrid.net, or another ESP's shared domain). But the <domain> in auth_results is not your domain. That's the problem.
Root cause: DMARC requires SPF alignment: the envelope-from domain (the Return-Path) must match the domain in your From header. When you send through an ESP like Mailchimp, their servers use their own domain as the Return-Path. SPF passes the raw check for their domain, but alignment fails because mcsv.net != yourdomain.com.
Fix: Stop relying on SPF alignment for ESPs that use their own envelope-from. Configure DKIM instead. When the ESP signs outgoing mail with a key that traces back to your domain (via a CNAME record you add to your DNS), DKIM alignment passes and DMARC passes. Every major ESP has a domain authentication or sending domain configuration step that does exactly this.
2. DKIM signature broken in transit
What the report shows:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>fail</result>
</dkim>
</auth_results>
DKIM is listed, the domain is correct, but the result is fail. This points to a signature that was valid when sent but broke before delivery.
Root cause: DKIM signs the message body and certain headers. Any modification to the signed content invalidates the signature. Mailing lists are the most common culprit: they typically append a footer ([unsubscribe | list info]), which rewrites the body and breaks the signature. Some forwarders reformat or rewrap the message body for the same effect.
Fix: There is nothing you can configure on your end to prevent a mailing list from modifying a message. If you are subscribed to a mailing list that accepts submissions from your domain and you need those submissions to pass DMARC, you are mostly out of luck. ARC (Authenticated Received Chain) allows the mailing list to seal the original authentication results, but support is not universal. The practical takeaway: failures from mailing list traffic are expected. Watch the volume, not the raw pass/fail count.
3. Forwarded mail failing SPF
What the report shows:
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
SPF fails, DKIM passes, DMARC passes. You will see this pattern consistently in reports if you receive forwarded email.
Actually, wait: if DKIM passes, DMARC passes, so why is this on the list? Because when DKIM is absent or breaks at the forwarding hop, you end up with both failing, and the pattern looks identical to cause #1.
Root cause: Forwarding changes the sending IP to the forwarder's IP. Your SPF record does not include that IP, so SPF fails. If the original sender had DKIM and the forwarder did not modify the message body, DKIM survives the hop and DMARC passes via DKIM alignment.
Fix: Ensure your legitimate mail sources all have DKIM configured. SPF alone is not reliable after a forwarding hop. If you see SPF failures from forwarder IPs and no DKIM to compensate, the solution is to add DKIM to the original sending source, not to add every possible forwarder IP to your SPF record.
For a deeper explanation of this mechanic, including how ARC sealing works, see Email Forwarding and DMARC.
4. Subdomain sending mail with no DMARC record
What the report shows:
<record>
<row>
<source_ip>198.51.100.25</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>notifications.yourdomain.com</header_from>
</identifiers>
</record>
The <header_from> is a subdomain, and both authentication checks are failing.
Root cause: A DMARC record at the organizational domain (yourdomain.com) does not automatically cover subdomains unless you include an sp= tag. A subdomain like notifications.yourdomain.com or billing.yourdomain.com sending mail with no DMARC record of its own is effectively unprotected. The receiving server looks for a DMARC record at notifications.yourdomain.com, finds nothing, then falls back to the organizational domain. Whether that fallback applies, and with what policy, depends on whether sp= is set.
Fix: Two options. First, add a dedicated DMARC record to the sending subdomain:
notifications.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
Second, set the sp= tag on your organizational domain record so the subdomain policy is explicit:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@yourdomain.com"
The dedicated subdomain record is cleaner if you have one or two active sending subdomains. The sp= approach is easier if you have many.
5. Wrong rua= URI format (missing mailto:)
This one does not cause DMARC failures on outbound mail; it causes you to receive no aggregate reports at all, which means you can't see the other four problems.
What you notice: Your DMARC record has been live for weeks and no reports have arrived at your designated address.
Root cause: The rua= value must be a URI, not a bare email address. The correct format is:
rua=mailto:reports@yourdomain.com
The most common typo is:
rua=reports@yourdomain.com
Mail receivers silently skip delivery if the URI is malformed. No error, no bounce, just silence.
Fix: Check your published DMARC record with the DMARC Record Checker. Look at the raw TXT value and confirm the rua= value starts with mailto:. Update the DNS record if it doesn't.
While you're there, check the full record with the Email Auth Checker to confirm SPF, DKIM, and DMARC are all configured correctly.
Summary
| Cause | DKIM result | SPF result | Fix |
|---|---|---|---|
| SPF alignment mismatch (ESP envelope-from) | fail | fail (aligned to ESP domain) | Configure DKIM on the ESP |
| DKIM signature broken in transit | fail | fail | Expected from mailing lists; watch volume |
| Forwarded mail, no DKIM fallback | fail | fail | Add DKIM to the original sending source |
| Subdomain with no DMARC record | fail | fail | Add DMARC record to subdomain or set sp= |
Missing mailto: in rua= |
n/a | n/a | Fix the URI format |
FAQ
SPF passing is not the same as SPF alignment passing. DMARC requires the domain in the SPF check to match your From header domain. When an ESP uses its own domain as the Return-Path (envelope-from), SPF passes for their domain but alignment fails because it does not match yours. Use DKIM alignment instead.
Look at the <header_from> and <source_ip> fields in your aggregate report. Each record shows the sending IP, the From domain, and whether DKIM and SPF aligned. Paste your report into the DMARC XML Analyzer and look at the failing records. Cross-reference the IP against known sending services.
Yes. At p=none, DMARC failures do not affect delivery. The message lands normally, but the failure is recorded in your aggregate reports. That data is the only signal you have before you tighten to p=quarantine or p=reject, at which point the same failures start affecting inbox placement or causing bounces.
DMARCdrift is free for one domain. Point your rua= address at us and the first digest arrives within a week.