More than one DMARC record published
Two or more DMARC records are published at _dmarc for this domain. The specification requires exactly one: when a receiver finds several, it discards all of them and treats the domain as having no DMARC policy at all. Your enforcement, your alignment requirements and your reporting all stop working, and no error is reported anywhere.
Check your own domainDMARC checker
What causes this
RFC 7489 permits exactly one DMARC record. When a receiver finds more than one TXT record starting with v=DMARC1 at the _dmarc name, the specification tells it to treat the domain as having no DMARC record at all. It does not pick one or merge them.
What it breaks
Your DMARC policy is not applied. Whatever enforcement level you configured (quarantine, reject) is ignored, and aggregate reports stop arriving.
What the receiving server does
A receiver queries TXT at _dmarc.yourdomain.com and filters the results for records beginning v=DMARC1. If more than one remains, the domain is treated as having no policy: receivers do not merge the records, and do not prefer the stricter or the more recently added. A domain that believed it was at p=reject is silently back to no protection. Because the failure produces no bounce and no report, it commonly persists for months.
Two records where one is required
This usually arises when a second tool is onboarded and adds its own DMARC record rather than editing the existing one, or when a record is duplicated during a DNS migration. Both records below are individually valid, and together they mean nothing.
How to fix it
Keep one record and delete the rest.
- List the DMARC records currently published at _dmarc.
- Decide which policy is correct, usually the more recently edited, stricter one.
- Delete every other TXT record at _dmarc that begins with v=DMARC1.
- Re-check to confirm exactly one record is returned.
If you send with
- Adding a DMARC reporting service
- Reporting vendors need their address in your rua tag, not a record of their own. The rua tag accepts a comma separated list of mailto: URIs, so add theirs alongside yours inside the single existing record.
- After a DNS migration
- Duplicate records frequently appear when zones are imported into a new provider and the old entries are recreated alongside the imported ones. Any audit after a nameserver change should count records at _dmarc explicitly.
Confirming the fix worked
- Query TXT at _dmarc.yourdomain.com and count the records beginning v=DMARC1. There must be exactly one.
- Merge the tags into a single record, combining rua addresses with commas rather than duplicating the record.
- Delete the surplus record outright rather than emptying it.
- Confirm aggregate reports resume. Their absence is often the first sign the policy was being ignored.
Common questions
- Which record wins if two are published?
- Neither. The domain is treated as having no DMARC policy at all. Receivers do not choose between them or merge them.
- Can I send reports to two different addresses?
- Yes, and that is the correct way to do it. The rua tag takes a comma separated list of mailto: URIs inside one record, which is what people are usually trying to achieve when they publish a second record by mistake.
- Is it a problem to have other TXT records at _dmarc?
- Only records beginning v=DMARC1 count. Other TXT records on that name are ignored for DMARC purposes, although there is rarely a good reason to have any.
- Does a subdomain policy conflict with the parent record?
- No. _dmarc.example.com and _dmarc.mail.example.com are separate names, each allowed one record. A subdomain policy overrides the parent for that subdomain, which is a supported arrangement rather than a duplicate.