Common causes of DMARC failure
Aggregate reports make failures visible, and the first look is always unsettling: mail you know you sent, listed as failing. The reassuring part is how short the list of explanations is. Eight causes account for nearly everything a normal domain sees, most of them are configuration you can correct, and each one leaves a recognisable trace in the data. This page is the short answer to why DMARC fails.
A DMARC failure means a message arrived claiming to be from your domain without an authentication result that ties it to that domain: neither SPF nor DKIM passed and aligned. It says nothing about who sent the message — only that nothing proved it was you.
The eight common causes, ranked by how often they show up in reports
The ranking below is a rough one — your mix depends on how many services send as your domain — but the order holds for most domains in their first months of monitoring. Read the middle column first: it is the column you can match against what is actually on your screen.
| Cause | What it looks like in your reports | Fix |
|---|---|---|
| An email service provider sending as you, unaligned. The newsletter, CRM, helpdesk or transactional platform authenticates as itself, which is its out-of-the-box behaviour | A named provider group failing DMARC while its own SPF and DKIM pass — the checks succeed, they just belong to the provider's domain | Publish the ESP's custom return-path and DKIM records — Third-party senders and DMARC |
| Google Workspace or Microsoft 365 not signing with your domain. DKIM is off, or still signs with the provider's default domain | High-volume mail from Google or Microsoft infrastructure, DKIM either absent or signing for a domain that is not yours | Switch DKIM to your own domain — Google Workspace or Microsoft 365 |
An SPF record that is incomplete or over the ten-lookup limit. A sender was never added, or the record's nested include: chain exceeds what the specification allows | SPF failing across several senders you do recognise at once, sometimes with a permerror result rather than a plain fail | Add the missing sender, or flatten the chain and re-count — What is SPF? |
| Forwarding and mailing lists. The relaying server delivers from its own address, and discussion lists edit the message on the way through | SPF failing from universities, ISPs and list servers with aligned DKIM still passing; on content-modifying lists, both checks fail | No record-level fix exists — Why SPF fails on forwarded mail |
| Someone spoofing your domain outright. The only cause on this list that is an attack rather than a mistake | Both checks failing, your From domain used exactly, countries you do not operate in, volume that probes or bursts rather than hums | Nothing to fix on the sender; enforcement is the fix — Why sources show as Unknown |
A record with no usable policy — p= missing, invalid, or set to none | Failing rows arriving steadily, every one of them with a disposition of none, because nothing is being blocked anywhere | Advance the policy once your senders are clean — DMARC policy not enabled |
Tag mistakes in an otherwise healthy record — a forgotten sp=none, a stray pct=25, a malformed rua | Subdomain traffic unenforced while the apex domain looks clean, or a fraction of failing mail handled one notch softer than your policy asks — delivered under p=quarantine, quarantined under p=reject | Audit every tag against the reference — DMARC record tags explained |
| No DMARC record published at all, or published at the wrong host name | Nothing at all — no reports arrive, because no record tells receivers where to send them | Publish v=DMARC1; p=none; rua=mailto:… at _dmarc — What is DMARC? |
Those are the causes. The mechanics of a single failing row — which check failed, whether it aligned, and what each verdict label means — are covered separately in DMARC pass and fail, explained.
Authentication failure is not the same as a breach
Failure is a strong word, and in a DMARC report it does not mean what people fear it means. A DMARC authentication failure is a statement about evidence, not about access: this message could not be tied to your domain by an aligned, authenticated check. It does not mean your mail server was compromised, that an account was taken over, or that anything left your building. Putting your domain in a From header takes no access to your systems at all — it is a text field an attacker types, which is precisely why DMARC exists.
Sorted by what you can actually do about them, the eight causes fall into three groups:
- Misconfiguration. Most of the list. Unaligned providers, an incomplete SPF record, Workspace or Microsoft 365 signing with the wrong domain, tag mistakes, a missing or unenforced record — all of them are your own DNS and provider settings, and all of them are fixable.
- Structural. One of them. Forwarding and mailing lists break authentication as a property of how relaying works, not as a fault in your setup, and there is no record you can publish that stops it. Aligned DKIM carries most forwarded mail through anyway; the residue is a known, accepted cost, explained in Why SPF fails on forwarded mail.
- Attack. Exactly one. Spoofing is somebody else sending mail you never wrote, and nothing in your DNS makes them stop. What your record decides is whether their mail is delivered.
The practical consequence is worth stating plainly: a sudden spike in failures is far more often a DMARC misconfiguration — a new marketing tool somebody signed up for on Tuesday — than an incident. Treat it as an inventory question first, and check the disposition column before you escalate, because failing mail is frequently delivered anyway for reasons that are entirely mundane. DMARC fails but mail still delivered covers that gap between what you asked for and what receivers did.
Which cause is yours? A five-minute triage
Work the four checks in order. Each one either names your cause or hands the question to the next step.
- Read your own record. Run your domain through the DMARC checker: is a record published at
_dmarc, and doesp=carry a real policy? If nothing is published, orp=is missing or set tonone, you have found your cause without opening a single report. If there is noruaaddress either, stop here and add one — until reports arrive there is nothing to triage. - Open a report. Drop an aggregate attachment into the DMARC report analyzer — it takes
.xml,.xml.gzand.zip, parses in your browser with nothing uploaded, and returns a compliance rate plus a per-source table ordered by volume, naming the sending provider wherever it can identify one and giving every source its own verdict. Work down from the top and stop at the first failing row. - Check SPF for that source. The SPF checker resolves your
include:chain recursively and reports how many DNS lookups the record costs in total. Over ten is a permanent failure for every sender at once, not just the one you were investigating, so it outranks whatever you started with. - Check DKIM for that source. Take the selector from the report and confirm a key is published on your own domain with the DKIM lookup; leave the selector blank and it tries the common ones. A selector that returns no key usually means custom-domain DKIM was never finished. Whose domain actually signed the message is in the report rather than in DNS — the
dkimresult'sdomainfield — and if that reads as your provider rather than you, the cause is an unaligned sender: the ESP row or the Workspace and Microsoft 365 row above.
Four checks, one named cause. If the source you landed on is not one you recognise at all, judge it on the fingerprint rather than the name, and only then conclude it is spoofing.
Frequently asked
Which of the following are common causes of DMARC and sending email breaches?
The recurring ones, in the order you are most likely to meet them:
- An email service provider or SaaS tool sending as your domain without aligned SPF or DKIM.
- Microsoft 365 or Google Workspace still signing messages with the provider's own domain instead of yours.
- An SPF record that is incomplete, or that exceeds the ten DNS lookups the specification permits.
- Forwarding and mailing lists, which break SPF on every hop and DKIM whenever the message is edited.
- Outright spoofing — someone putting your domain in the From header of mail you never sent.
The first three are misconfiguration, and each has a fix in DNS or in a provider's admin console. The fourth is structural — forwarding and mailing lists break authentication as a property of how relaying works, and there is no record you can publish that stops it; aligned DKIM is what carries most forwarded mail through. The fifth is the attack DMARC was designed to stop, and a missing or p=none record is what leaves it unblocked.
How many DMARC failures are normal?
There is no universal number, and a permanent residue is expected: forwarded mail and spoofing attempts both count as failures, and neither ever falls to zero. What matters is the composition rather than the count. Failures from sources you own or pay for are the ones to work through, because those are the messages that would be lost at enforcement. Failures from relays you have never heard of, and from senders that are plainly not you, are the system reporting exactly what it was built to report.
Do I have to fix every failing source before moving to p=reject?
Every source you own or pay for, yes — that is the whole point of the monitoring phase, and it is the work that makes enforcement safe. Sources you do not control are a different matter: you cannot fix a forwarder, and you should not want to fix a spoofer. Once your own senders authenticate cleanly, the remaining failures are the ones enforcement is supposed to catch, and you can climb the ladder described in DMARC policy: none, quarantine, reject.
Matching a cause to a row is much faster when the sources are already grouped, named and scored for you — which is what a monitor does with the same reports. You can start monitoring free, or look at the shapes above on realistic data first in the live demo.