Can a domain have multiple DMARC records?

A domain should have one DMARC policy record at a given DMARC owner name, such as _dmarc.example.com. If a DNS lookup returns multiple DMARC policy records for the same target, RFC 9989 says they are all discarded. The fix is to merge the intended tags into one valid record, remove the duplicates, wait for DNS caches to update, and confirm that public resolvers return a single record beginning with v=DMARC1.

Quick takeaways

• Publish one DMARC policy record at each DMARC owner name.
• Two TXT strings can form one DNS record, but two complete DMARC records are invalid.
• Multiple returned policy records are discarded during DMARC discovery.
• Merge policy, reporting, and alignment tags into one record instead of adding another.
• Check several public resolvers after the change because cached answers can differ temporarily.

Who is affected?

This affects any domain where two administrators, vendors, or DNS migrations create separate records at the same owner name. It is common when a reporting service says to add a DMARC record even though one already exists.

It can also confuse dashboards that display every TXT value without distinguishing separate resource records from quoted chunks in one record. Start with the DMARC overview if the owner name or tag structure is unfamiliar.

What are the requirements?

The DMARC Policy Record format places the record at the DMARC owner name and begins with the exact version tag v=DMARC1. Policy, aggregate-reporting, failure-reporting, and alignment preferences belong in that one tag-value record.

RFC 9989 says that when multiple DMARC Policy Records are returned at one target, all are discarded. That means two apparently sensible policies do not combine. Receivers do not choose the strictest one, the first one, or the newest one.

One DNS TXT resource record may contain several quoted character strings because of DNS presentation limits. Those chunks are joined as one record by DNS software. The error is multiple separate DMARC policy records, not a long record split into chunks.

When does the requirement take effect?

The single-record behavior applies every time a receiver performs DMARC policy discovery. It is not tied to a provider rollout date. RFC 9989 is the current DMARC protocol reference and retains an explicit multiple-record discard rule.

DNS changes are not instantaneous for every resolver. During a migration, some receivers may still see a cached old answer until its TTL expires.

How do I implement the requirement?

1. Query the exact DMARC owner name

Look up TXT records at _dmarc followed by the domain in the visible From address. Record every returned resource record before making a change.

2. Choose the intended policy and destinations

Confirm the policy, aggregate-report address, optional failure-report address, subdomain policy, and alignment modes with the domain owner. Do not copy a second vendor's entire example over the existing policy.

3. Merge the tags into one valid record

Create one record that starts with v=DMARC1 and contains each intended tag once. Preserve authorized reporting destinations and remove obsolete or conflicting values.

4. Delete the duplicate records

Remove only the extra DMARC resource records at that owner name. Do not delete unrelated TXT records used for site verification or another service.

How do I validate compliance?

Query the owner name through at least two public resolvers and confirm that exactly one DMARC policy record remains. Parse its tags, confirm the reporting addresses, and send a test through a real source. Then review aggregate data to make sure receivers are applying the intended policy.

Use Palisade's DNS lookup tool for the public answer and Email Security Score for a broader configuration check. Neither replaces approval of the policy and report destinations by the domain owner.