Fix: multiple DMARC records

22 June 2026 · 4 min read

If a receiver finds two DMARC records at _dmarc.example.com, it does not choose the stricter one or the newer one. The DMARC standard, RFC 9989, tells receivers to discard every record at that name when more than one is returned. For your main domain, that leaves no DMARC policy at all: your p=reject stops applying and receivers stop sending you aggregate reports, with no error anywhere. The fix is to merge the two into one record.

What the standard says

When a receiver looks up _dmarc.example.com, it ignores any TXT record that does not start with v=DMARC1. Of what remains, RFC 9989 section 4.10 says that if multiple DMARC policy records are returned for a single name, they are all discarded. The receiver then carries on looking at parent names:

• On your organisational domain (example.com), the next name up is the top-level domain, which normally has no DMARC record. The receiver applies no DMARC to your mail.
• On a subdomain (shop.example.com), the receiver moves up to example.com and uses that record instead, so the subdomain silently gets the parent's policy rather than its own.

The older RFC 7489 had the same outcome for the main domain: multiple records meant no DMARC action. Either way, the content of the two records is irrelevant. A p=reject record next to a p=none record does not mean "reject"; it means neither.

Some things are not duplicates:

• Other TXT records at _dmarc, such as an old verification token, are ignored rather than counted. They are clutter, not the cause.
• A record at _dmarc.example.com and another at _dmarc.shop.example.com are a domain policy and a subdomain policy. That is allowed.
• One long record split into several quoted strings is still one record.

How a second record gets there

• A new reporting service. A vendor's setup page says "add this DMARC record" with its own rua address, and you add it next to the one you already had.
• An email platform's automatic setup. Some platforms write their own DMARC record when you authenticate a domain with them.
• A DNS panel that adds instead of editing. Entering the host as _dmarc once and _dmarc.example.com another time can create two entries at the same name.
• A DNS migration. The imported zone already contained a DMARC record, and the new provider's setup added another.

Check for duplicates

Query the name directly:

dig +short TXT _dmarc.example.com

On Windows, use nslookup -type=TXT _dmarc.example.com. Count the answers that start with "v=DMARC1. More than one is the problem. The DMARC checker reports how many DMARC records it found and warns when there is more than one, and the TXT record checker lists everything else published at the name.

A sudden stop in aggregate reports from every receiver at once is the indirect sign. Without a valid record, receivers have no rua address to send reports to.

Merge into one record

1. Copy both records exactly

"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
"v=DMARC1; p=none; rua=mailto:reports@vendor.example"

2. Decide the policy

Keep the policy you were really at. If you had reached p=reject and it was working, keep p=reject. Do not let a vendor's p=none record pull you back down.

3. Combine the report addresses

The rua tag accepts several addresses separated by commas:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:reports@vendor.example

If a report address is on a different domain from the one publishing the policy, that domain must authorise it by publishing a TXT record such as example.com._report._dmarc.vendor.example containing v=DMARC1;. Reporting services normally do this for you. Without it, receivers may not send reports there. The mechanism is defined in RFC 9990, the DMARC aggregate reporting standard.

4. Replace, do not append

In your DNS panel, delete every TXT record at _dmarc that starts with v=DMARC1, then add the single merged record. Editing one and leaving the other is how many zones end up with two. Build the value with the DMARC generator if you are unsure of the syntax.

While you are there, remove pct= if your old record had it. RFC 9989 removed the tag. If you want receivers to treat a new policy as a trial, use t=y instead.

5. Check again after the TTL

Resolvers may return the old answer until the record's TTL expires. Once it has, dig should show exactly one v=DMARC1 line, and aggregate reports should start arriving again within a day or two.

Two related edge cases

• A CNAME at _dmarc. Some hosted DMARC services ask you to point _dmarc at their record with a CNAME. A name with a CNAME cannot also hold a TXT record, so pick one approach: the CNAME or your own TXT record, not both.
• Several email platforms each wanting "their" DMARC record. Brevo, for example, asks for a DMARC record with its own rua address. Add that address to your existing record rather than publishing the platform's record alongside it. The Brevo guide shows the merged value.

One name, one DMARC record: edit it in place, never add a second. To keep it that way without checking by hand, hosted DMARC publishes a single record for you and alerts you to regressions. For the meaning of each policy level, read p=none vs quarantine vs reject.