DMARC Fail: Why It Happens and How to Fix It

Somewhere in your test results or your inbox headers sits the verdict dmarc=fail, and the confusing part is that it rarely means what it sounds like. Most DMARC failures are not forgery. They are legitimate email that authenticated as the wrong domain: SPF vouching for your ESP instead of you, DKIM signed with a shared key, or a forwarder rewriting just enough to break both checks at once.

The direct answer first: DMARC fails when a message cannot show even one authentication check that both passes and matches the domain in your From header. Everything else in this guide is the diagnosis and the repair: what the verdict is made of, the seven causes I see over and over in spam test results, the fix for each one, and how to tighten your policy once the failures stop.

Failing also puts you in the majority. Across the checks run through Unspam, 90% of senders pass SPF and 88% pass DKIM, but only 55% pass DMARC. It is by far the weakest link in the authentication chain, and the causes below are the reasons for that gap.

What dmarc=fail actually means

DMARC does not inspect content, links, or sending volume. It asks exactly two questions about a message claiming to be from yourbrand.com:

1. Did SPF pass, and is the domain it passed for aligned with the From domain? SPF validates the envelope sender (the Return-Path address used during the SMTP conversation), which the reader never sees. Alignment means that hidden domain and your visible From domain match.
2. Did DKIM pass, and is the signing domain (the d= tag in the signature) aligned with the From domain?

One aligned pass is enough. SPF can fail completely and DMARC still passes if an aligned DKIM signature verifies, and the other way around. That single OR is the most practical fact in this whole topic, and it is also why so many failures confuse people: both checks can pass individually while DMARC fails, because neither passed for your domain.

DMARC never asks "did authentication pass?" It asks "did authentication pass for the domain the reader actually sees?"

By default, alignment is relaxed: any subdomain of the same organizational domain counts, so mail signed by mail.yourbrand.com aligns with a From of yourbrand.com. Your record can demand strict alignment (adkim=s, aspf=s), requiring an exact match, which is a deliberate hardening choice and a common self-inflicted failure, as we will see. For a deeper comparison of how the two underlying checks differ, see DMARC vs DKIM.

First, find out why yours is failing

Do not fix blind. Every DMARC verdict comes with the evidence attached, in three places.

Run a pre-send test. The free Unspam spam test authenticates the exact message you are about to send and shows the SPF, DKIM, and DMARC results side by side, including which domains each check evaluated, next to the SpamAssassin, blacklist, and content checks. This is the only route that catches the failure before a subscriber sees it.

Read the Authentication-Results header. On any delivered message, the receiving server writes its verdict into the headers. In Gmail, open a message and choose Show original; the summary at the top and the raw Authentication-Results line tell the whole story:

This example is the single most common real-world failure. Both checks pass, and DMARC still fails, because bounce.esp-mail.com and esp-mail.com do not align with yourbrand.com. The header hands you the diagnosis: the domains after smtp.mailfrom= and header.d= are the ones that earned the pass, and neither is yours.

Read your aggregate reports. If your DMARC record includes a rua address, receivers email you daily XML summaries of every source that sent mail as your domain: the IPs, the volumes, and how each authenticated. Reports are the only way to see failures on mail that never crossed your desk, including forwarded copies and spoofing attempts.

Before touching anything else, also point the free DMARC checker at your domain to confirm the record itself is present and syntactically sane.

The seven reasons DMARC fails, and the fix for each

Nearly every dmarc=fail traces back to one of these. They are ordered by how often I see them, so work from the top.

1. Your ESP authenticates as itself, not as you

Out of the box, most sending platforms use their own infrastructure domains: the envelope sender is something like bounce.esp-mail.com so they can process your bounces, and the DKIM signature uses their shared key with their domain in d=. Both checks pass, for them. Your From domain gets no aligned pass, and DMARC fails as shown in the header above.

The fix is the setting every serious platform offers under a name like custom domain authentication, domain verification, or branded sending: you publish a few CNAME records they give you, and from then on messages are DKIM-signed as yourbrand.com (or a subdomain, which aligns under relaxed mode) and use a custom bounce domain like bounce.yourbrand.com for SPF alignment. Do DKIM first; an aligned DKIM signature alone flips DMARC to pass even while the SPF side still points at the ESP.

2. A forwarder broke SPF

When someone auto-forwards your email (a university address forwarding to Gmail, an old domain forwarding to a new one), the forwarding server delivers it from its IP, which is not in your SPF record, so SPF fails. Forwarders that "fix" this by rewriting the envelope sender to their own domain make SPF pass again, but for their domain, which breaks alignment instead. Either way, the SPF lane is dead on forwarded mail, permanently and by design.

The fix is to stop depending on SPF alone. A DKIM signature travels inside the message and verifies no matter which server relayed it, so a clean forward keeps an aligned dkim=pass and DMARC still passes. If your aggregate reports show a tail of SPF-only failures from mailbox providers' own IP ranges, that is forwarding, it is normal, and it is precisely why you should never publish an enforcing DMARC policy on the strength of SPF alignment alone.

3. A mailing list rewrote the message

Discussion lists are the harder cousin of forwarding: they typically add a subject tag like [members], append an unsubscribe footer, and resend from the list's own address. The footer and subject edits change the signed content, so your DKIM signature no longer verifies. The list's envelope breaks SPF alignment. Both lanes fail on mail that everyone involved wanted delivered.

The fix is mostly out of your hands, and honesty beats hand-waving here. Modern lists mitigate it themselves, either by rewriting the From header to the list's domain (taking your domain out of the DMARC equation) or by adding an ARC seal that lets receivers vouch for the original authentication results. On your side: keep DKIM aligned so plain forwarding survives, and expect a small, harmless residue of list-related failures in your reports. If you run the list, enable its DMARC mitigation options.

4. Strict alignment when you need relaxed

If your record sets adkim=s or aspf=s, only an exact domain match counts: mail DKIM-signed by mail.yourbrand.com with a From of yourbrand.com passes relaxed alignment but fails strict. Teams enable strict mode as a hardening measure, forget that their newsletter platform signs with a delegated subdomain, and manufacture their own failures.

The fix: check whether your record carries adkim=s or aspf=s (the DMARC checker shows every tag). If the domains that legitimately send for you include any subdomain, either drop back to relaxed (delete the tag; relaxed is the default) or reconfigure the sender to sign with the exact From domain. Strict alignment is worth having only after your reports show a long, clean run with every source exactly matched.

5. SPF permerror: the ten-lookup limit

SPF records are evaluated with a hard budget: mechanisms that trigger DNS lookups (include, a, mx, redirect, exists) may not exceed ten in total, counted recursively through every nested include. Stack enough tools (an ESP, a CRM, a helpdesk, an old include nobody remembers), and evaluation aborts with permerror. A permerror can never become an aligned pass, so the SPF lane goes dark for every receiver, on every message.

The fix: run your domain through the SPF checker, which counts the lookups for you. Remove includes for services you no longer use, and consider consolidating or flattening the rest. While you are in there, make sure the record ends in ~all or -all; a +all tells the world anyone may send as you, which defeats the point of the whole authentication stack.

6. The DMARC record itself is broken

A surprising share of failures happen before any message is evaluated, in the DNS record:

• Two DMARC records. Merging domains, or two teams each adding one, leaves multiple TXT records on _dmarc. The standard is unforgiving: receivers that find more than one record apply none of them.
• Wrong host. The record must live at _dmarc.yourbrand.com, not at the root and not at dmarc. without the underscore.
• Syntax slips. The record must start with v=DMARC1, tags are separated by semicolons, and rua addresses need the mailto: prefix. A typo like p=non invalidates the policy.

The fix: paste your domain into the DMARC checker and fix what it flags. If you would rather not hand-assemble the string, the free DMARC record generator builds a valid one from dropdown choices.

7. Someone really is spoofing your domain

Once the six misconfigurations are ruled out, what remains in your aggregate reports (unknown IPs, often geographically improbable, failing both checks on volume you never sent) is DMARC doing its job: catching forgery. This is the failure you want.

The fix is to resist the wrong one: do not loosen your policy because the reports look scary. Confirm the sources are not yours (shadow IT is real; that unknown IP is sometimes the billing system someone connected in 2019), then let your p=quarantine or p=reject policy eat the fakes. This protection is the reason sender reputation and DMARC enforcement go hand in hand.

"No DMARC record found": the five-minute fix

Tools and postmaster pages report this when there is no TXT record at _dmarc.yourdomain.com at all. It is not a failure of any single message, but it stopped being a cosmetic gap in 2024: Gmail and Yahoo now require senders of bulk email (Google draws the line at about 5,000 messages a day to Gmail) to publish at least a minimal DMARC policy, with SPF or DKIM aligned to the From domain, and Microsoft applies the same requirement to Outlook consumer domains since May 2025. No record now means throttling, junking, or outright rejection at the biggest mailbox providers, which shows up as exactly the undelivered mail people then spend days chasing.

The starter record is one line, published as TXT on the _dmarc host:

v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com

It enforces nothing, satisfies the mailbox providers' minimum, and starts collecting the aggregate reports you need for everything else in this guide. Generate yours with the record generator mentioned above if you want the syntax handled for you.

What receivers do with a failing message

The consequence of dmarc=fail is whatever your own record requests, applied at the receiver's discretion:

Two footnotes that matter in practice. First, receivers may override your policy in either direction; a pct tag also lets you apply quarantine or reject to only a sampled share of failing mail while you gain confidence. Second, p=none is not consequence-free: filters at Gmail and Outlook weigh authentication results as a reputation signal regardless of your policy, so a stream with chronic DMARC failures gets progressively worse inbox placement even while every message is technically delivered.

How to fix DMARC failures, step by step

This is the order that works, whether you are clearing one failing campaign or a whole domain:

1. Publish or repair the record, at p=none, with a rua address. Verify it with the DMARC checker. Enforcement comes last, not first.
2. Inventory your senders. Give the aggregate reports two to four weeks, then list every service that sends as your domain: ESP, transactional mail, CRM, helpdesk, billing, the office printer.
3. Align DKIM everywhere first. For each legitimate sender, enable custom domain signing so d= is your domain. DKIM survives forwarding, so it is the alignment that keeps working after the message leaves your hands.
4. Align SPF second. Set up custom bounce domains where the platform supports them, and get your record under the ten-lookup limit with the SPF checker.
5. Verify per message, not per domain. Send a real message from each platform through the spam test and check all three verdicts with the DKIM checker alongside. Records can be perfect while a specific mail stream still signs with the wrong key.
6. Ratchet up the policy. When reports show your legitimate sources passing, move to p=quarantine (optionally sampled with pct), watch, then p=reject. That final step is the point of the whole exercise: it is what actually stops your customers from receiving fake invoices with your name on them.

Check the verdict before your subscribers do

A DMARC fail discovered in an aggregate report already cost you a campaign. The free Unspam spam test shows the same verdict before you send: SPF, DKIM, and DMARC evaluated on your exact message, with the domains each check saw, next to the spam score, blacklist, and content checks, in about 30 seconds, no signup required. If it says pass and aligned, send. If it says dmarc=fail, you now know which of the seven causes to fix, and none of them takes longer than an afternoon.