Few email problems are as confusing as a domain that is sending mail correctly yet still shows dmarc=fail in the headers. The good news is that DMARC failures are almost always explainable, and the mechanism is simpler than the acronyms suggest. This guide walks through what a DMARC failure actually means, the handful of causes that produce nearly all of them, how to diagnose yours from your aggregate reports, and how to fix each case.
For the site owner (plain English)
A DMARC failure means some mail sent using your domain could not prove it was really yours. It is worth fixing, but it is rarely an emergency — and it usually points at one specific service, not your whole domain. The most common cause is a tool you send through (a newsletter platform, a CRM, an invoicing app) that was never set up to authenticate as you. The way to find the culprit is to add a reporting address to your DMARC record (the rua= part) and read the daily summaries, which name every source and whether it passed. Once you know which service is failing, the fix is a small DNS change following that provider's instructions — usually adding them to your SPF line or adding a DKIM record they give you. No developer required.
What does a DMARC failure actually mean?
DMARC sits on top of two older authentication checks: SPF and DKIM. On its own, neither SPF nor DKIM tells the receiving server anything about the domain a human reads in the From: header. DMARC closes that gap. Per RFC 7489, a message passes DMARC when at least one of SPF or DKIM both passes and aligns with the visible From domain.
Passing and aligning are two separate requirements, and conflating them is the single biggest source of confusion. A check passes when the cryptographic or DNS test succeeds — the SPF record authorises the sending IP, or the DKIM signature verifies against the published public key. A check aligns when the domain that passed matches the From domain. DMARC only counts a check if both are true at once.
- SPF alignment compares the From domain against the domain in the envelope sender (the
Return-Path, also called the MAIL FROM or bounce address). - DKIM alignment compares the From domain against the domain in the
d=tag of a verified DKIM signature.
So a DMARC failure means neither path succeeded: SPF failed or did not align, and DKIM failed or did not align. Identifying which of those two broke — and why — is the whole job.
What causes DMARC to fail?
In practice, almost every DMARC failure traces back to one of four situations. Often more than one is in play across different mail streams.
An unauthorised third-party sender
You send mail through a service — a marketing platform, a help desk, an invoicing tool, a CRM — that uses your domain in the From address but was never configured to authenticate as you. Its IP is not in your SPF record, and it either does not sign with DKIM at all or signs with its own domain. Both DMARC paths fail because neither test ties back to your From domain.
New SaaS tools are the most frequent offenders, because it is easy to set a From address and forget the authentication setup that the provider documents separately.
An alignment mismatch — relaxed versus strict
Here the check passes but does not align. DMARC offers two alignment modes per mechanism. Relaxed (the default) requires the two domains to share an organisational domain, so mail.example.com aligns with example.com; strict requires an exact match.
A message can pass SPF for bounces.vendor.com and still fail DMARC for example.com because those domains do not share an organisational domain at all. Switching to strict mode (aspf=s or adkim=s) without verifying every sender uses an exact subdomain is a common self-inflicted failure.
An SPF record over the 10-lookup limit
SPF allows a maximum of ten DNS lookups when evaluating a record. Mechanisms like include:, a, mx, and redirect each cost lookups, and nested includes from large providers add up fast. Exceed ten and the receiver returns a permerror, which counts as an SPF failure regardless of whether the sending IP was actually authorised. If SPF was your only passing path, DMARC fails with it.
A mailing list or forwarder breaks SPF (but DKIM survives)
When a message is forwarded or relayed through a mailing list, the final hop comes from the forwarder's servers, not yours. SPF checks that last IP against your record and fails, because the forwarder is not in it. DKIM, however, signs the message body and selected headers cryptographically, so it usually survives forwarding intact — unless the list rewrites the subject or body, which invalidates the signature. This is why DMARC built in the "at least one" rule: a valid, aligned DKIM signature carries the message through a hop that SPF cannot.
Return-Path), not the visible From domain. Most third-party senders set the Return-Path to their own domain — so SPF passes for them, but it does not align with your From domain, and DMARC fails. The fix is to make the sender use a custom return-path on your domain, or to set up a DKIM CNAME so the signature's d= aligns instead.How do I diagnose my own failures?
You do not have to guess. DMARC's most useful feature is the rua tag, which tells receiving servers where to send daily aggregate reports. Add an address and you start receiving XML summaries from every major mailbox provider:
v=DMARC1; p=none; rua=mailto:dmarc@example.comAggregate reports do not contain message content. Instead, each report groups every message your domain sent, by source IP, and tells you for each group: how many messages, whether SPF passed and aligned, whether DKIM passed and aligned, and the resulting DMARC disposition. Reading them per source is what turns a vague "DMARC is failing" into a precise diagnosis.
- Group the report data by source IP or sending service. A failure isolated to one IP points to a single misconfigured tool, not a domain-wide problem.
- For each source, check whether SPF and DKIM passed at all, and separately whether each aligned. A pass-without-alignment pattern is the signature of the return-path problem above.
- Watch for sources you do not recognise. These are either forgotten tools to authorise or, occasionally, spoofing you will want to block.
The raw XML is hard to read by hand, so most teams pipe reports into a parser or monitoring dashboard. The principle stays the same: find the source, then determine which of the two paths failed and whether the failure was a true pass-fail or an alignment gap.
Enter your domain and we will show which senders pass, which fail, and whether SPF and DKIM align with your From domain.
Check why your domain fails DMARC →How to fix each cause
Once you know which source is failing and why, the remedy follows directly from the diagnosis.
Authorise the sender via SPF and DKIM
For a legitimate third-party tool, follow the provider's authentication setup. That usually means adding their include: mechanism to your SPF record and publishing the DKIM public key (or a CNAME pointing to theirs) at the selector they specify. DKIM is the more durable of the two because it survives forwarding, so prioritise getting DKIM working even where SPF already passes.
Fix alignment with a custom return-path or DKIM CNAME
When a sender passes but does not align, you need the authenticated domain to match your From domain. Two standard approaches:
- Custom return-path: configure the service to use a subdomain of yours (for example
bounce.example.com) as the envelope sender, then publish the DNS records it requires. SPF then aligns under relaxed mode. - DKIM CNAME: point a selector like
s1._domainkey.example.comat the provider's host so the signature'sd=tag reads your domain. DKIM then aligns.
Trim your SPF record below ten lookups
If you are hitting permerror, audit every include: and remove services you no longer use. Replace broad includes with the specific IP ranges where a provider documents them, or use SPF flattening to collapse nested lookups into a static set of addresses. Keep the count comfortably under ten so future additions do not push you over again.
After any change, give DNS time to propagate, then watch your next few aggregate reports. A fix is confirmed only when the affected source shows a passing, aligned result across real traffic — not just in a one-off test message. Once every legitimate source passes and aligns, you can safely move your policy from p=none toward p=quarantine and eventually p=reject.
For the full picture of how SPF, DKIM, and DMARC fit together, see the email authentication guide. If your reports look clean but your domain still is not protected, the issue may be your policy itself — read why a DMARC policy of p=none does not protect you. For provider-specific setup, see the Google Workspace and Microsoft 365 DMARC guides.