A domain can have a DMARC record that looks perfectly valid in every way, sit at p=reject, cite a real reporting address, and still protect nothing. It happens the moment a second TXT record shows up at the same _dmarc hostname. The specification does not average the two, prefer the stricter one, or flag a conflict. It throws both out and treats the domain as if DMARC were never configured.
What the Specification Actually Requires
DMARC policy discovery is narrower than most people assume. A receiving mail server queries _dmarc.yourdomain.com for TXT records, and the rule that governs what comes back has been unchanged since the original RFC 7489 and carries forward into RFC 9989: there must be exactly one TXT record that begins with v=DMARC1. Zero matching records means no policy. More than one matching record also means no policy, full stop, regardless of what either record says.
This is not a corner case the drafters overlooked. It is a deliberate anti-ambiguity rule. If a receiver found two records, one saying p=reject and another saying p=none, there would be no principled way to decide which one the domain owner actually intended, so the specification refuses to guess. It discards both and falls back to no DMARC policy at all for that domain.
How Two Records End Up at the Same Domain
Nobody sits down and deliberately publishes a duplicate DMARC record. It accumulates through ordinary operational activity that nobody thinks of as touching DNS at the same time as someone else.
A security awareness or email authentication vendor runs a guided setup wizard during onboarding and writes a _dmarc TXT record as part of activation. Months later, a separate email marketing platform runs its own “authenticate your sending domain” wizard, does not check for an existing record first, and writes its own. Both tools believe they configured DMARC correctly, because from each tool’s isolated view, they did.
The same thing happens during DNS provider migrations, when a zone file is exported from one registrar and imported into another without deduplication, and an old record that should have been retired months earlier gets carried along next to its replacement. It happens after mergers and domain consolidations, when two IT teams each bring their own DNS conventions into a shared zone. It happens when a contractor sets up a temporary record for a migration project and nobody removes it once the migration finishes.
None of these people are making an obvious mistake. Each of them, on their own, published a syntactically correct DMARC record. The domain ends up unprotected because of what happens when those two individually correct actions land in the same DNS zone.
Why Nothing Tells You It Happened
A misconfigured DMARC record usually leaves a visible trace. A syntax error shows up if you run the record through a validator. A policy set to p=none is visibly permissive if you read it. A duplicate record produces neither signal, because there is no single record to inspect for the mistake; the mistake exists only in the relationship between two records that each look completely fine in isolation.
Run dig TXT _dmarc.yourdomain.com and you will see both entries printed back, one after another, and unless you are specifically counting how many of them start with v=DMARC1, two valid-looking policy strings read as reassuring, not alarming. Most DMARC record checker tools built for a quick manual spot-check display whichever record they parse first and never surface the second one as a conflict.
The reporting channel that would normally catch a misconfiguration like this is also compromised by the same failure. Aggregate reports are generated according to the policy a receiver believes is in effect, and a receiver that has correctly determined there is no valid policy has no obligation to treat that domain’s mail any differently, and often has no reason to keep sending detailed aggregate reports to an address tied to a policy it just discarded. The visibility mechanism that should reveal the gap is disabled by the exact condition that created it.
What This Costs You
While two records sit at _dmarc, the domain behaves, from every receiving mail server’s perspective, exactly like a domain that never adopted DMARC. SPF and DKIM alignment are not enforced, because alignment enforcement is a DMARC function and DMARC is not in effect. Spoofed mail claiming to be from the domain is evaluated purely on SPF and DKIM results with no alignment check tying them to the visible From header, which is precisely the gap DMARC exists to close. A domain that believes it is sitting at p=reject can be actively impersonated in phishing and business email compromise attempts with no enforcement acting on any of it, for as long as the duplicate persists.
What This Means for Your Program
Count the records, not just their content. Query _dmarc.yourdomain.com directly with dig or an equivalent tool and confirm there is exactly one TXT record beginning with v=DMARC1. Do not stop at confirming the policy value looks correct; confirm there is only one value to look at.
Treat every vendor’s “automatic DMARC setup” as a DNS write you need to verify, not trust. Any tool that offers to configure DMARC, SPF, or DKIM for you as part of onboarding is capable of writing a conflicting record if it does not first check what already exists. Verify the resulting DNS state after every such onboarding, not just after your own manual changes.
Re-check after DNS migrations and domain consolidations. A zone file import is exactly the kind of bulk operation that can silently carry forward a stale record alongside a current one. Audit _dmarc records for every domain in a zone immediately after any migration or merger, not just the domains someone remembers to check.
Monitor continuously, not just at initial setup. A record that was singular and correct on the day you configured DMARC can become duplicated months later by a completely unrelated team adopting a completely unrelated tool. A one-time verification at rollout tells you nothing about the state of your DNS six months on.
The Takeaway
DMARC failing to stop an attack usually makes for a dramatic story involving a clever bypass or a genuinely authenticated malicious sender. This failure mode has no attacker in it at all. Two well-intentioned teams, or one team and one vendor’s onboarding script, each do something reasonable in isolation, and the result is a domain that looks protected on a quick glance and is not protected at all. The fix costs nothing more than a dig command and a habit of counting.
A DMARC record that silently stopped working months ago looks identical to one that never did, until you know exactly what to check. Excello Mail continuously monitors your actual DNS state, not just the policy you configured once, so a duplicate record gets caught before an attacker finds the gap first. Sign up for free to Excello Mail and see your real authentication posture today.