Duplicate DMARC records: how to find and fix a policy collision

You open your DNS dashboard and see a DMARC policy. A second team says it has also configured DMARC for the same domain. Both records look reasonable in isolation, but neither may be usable. A receiver queries the TXT records at _dmarc.example.comand has to choose one policy for mail claiming to be from example.com.

The current DMARC specification says that when a lookup returns multiple DMARC policy records for one target, all of them are discarded. The receiver does not merge their tags or choose the stricter one. This rule is in RFC 9989, Section 4.10.

First, count DNS records rather than quotation marks

Query the exact name for the domain in the message's visible From address. For example:

dig +noall +answer TXT _dmarc.example.com

An answer with two separate TXT records beginning v=DMARC1 is a collision. Ordinary TXT records at that name that do not start with the DMARC version tag are ignored for DMARC selection. A long single TXT record can appear as several quoted strings on one answer line; DNS joins those strings into one value. Do not delete it just because your DNS tool shows several quoted pieces.

_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:reports@example.com"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject"

The example above has two policy records at the same name. Publishing a policy at _dmarc.example.com and another at _dmarc.mail.example.comis different: those are separate DNS names, and an explicit subdomain policy can be legitimate.

What the collision changes

A duplicate does not mean every receiver will reject your mail. It means the competing records are unusable for policy discovery at that name. The receiver may continue the DNS Tree Walk to look for an applicable parent or public-suffix policy; if it finds no applicable record, it cannot apply your requested DMARC policy. Local spam and abuse checks can still affect delivery. Do not infer your protection state from one test message arriving in an inbox.

The symptom is often a validator reporting multiple records or a receiver showing a DMARC policy error, while your DNS console displays a plausible p=rejectvalue. A report gap alone is not proof: receivers do not all send aggregate reports, and reporting addresses can fail for other reasons.

Repair one policy, then verify the public answer

1. Find the owner of each record. A second record often comes from a mail provider, security tool, or an old DNS migration. Record the current values before changing anything.
2. Choose the policy your sending inventory actually supports. Preserve needed tags, including rua, in one DMARC TXT record. Do not jump from monitoring to p=reject solely to fix the duplicate; first confirm legitimate senders align.
3. Remove the extra policy record at that exact name. Check the authoritative DNS servers and then public resolvers after the TTL has elapsed. The expected answer is exactly one TXT record beginning v=DMARC1 at that name.
4. Send a fresh message to a mailbox you control and read its trusted receiver's Authentication-Results. Continue watching aggregate reports for the domains and senders affected by the change.

Keep ownership explicit in DNS change procedures: one team maintains the DMARC policy, while mail vendors provide the DKIM and return-path settings their traffic needs. That prevents a well-meant vendor setup wizard from creating the next collision. For the standards detail, see RFC 9989's policy discovery rules.

Disclosure: AI tools were used in the process of creating this blog post.