When a domain publishes more than one DMARC record, receivers throw all of them away and apply no DMARC policy for it. See every record at your _dmarc name below, get a merged record to replace them with, and check the fix with dig or nslookup.
Last verified 30 September 2026.
A domain’s DMARC policy lives in a TXT record at _dmarc. plus the domain, for example _dmarc.example.com. The standard allows exactly one record there that starts with v=DMARC1. Checkers report “multiple DMARC records” when they find two or more.
Receivers don’t pick one, merge them or use the strictest. They discard the lot:
The practical effect is the same as publishing no DMARC record at that name: your p=quarantine or p=reject isn’t enforced, spoofed mail using your domain in the From: address gets no DMARC treatment, and no aggregate reports reach your rua addresses. A published DMARC record is also part of the Gmail, Yahoo and Microsoft bulk sender requirements.
One difference between the two versions: under RFC 9989 the lookup then continues up the DNS tree as if the name had no record (§4.10.1), so duplicates on a subdomain such as _dmarc.mail.example.com make it fall back to the organizational domain’s record and its sp= policy. Under RFC 7489 discovery simply stops. Either way, the policy you wrote for that name is never used.
_dmarc nameEnter the domain in your From: address. The lookup runs in your browser against public DNS and lists every TXT record at _dmarc, including the ones receivers ignore.
Suggested single record (combines the tags above; read the notes under “Merge them into one record” before you publish it):
This reads what your DNS publishes right now through Cloudflare’s public resolver. If you just changed a record, an old answer can stay cached until its TTL runs out. For the full A–F grade with SPF, DKIM, MTA-STS, BIMI and DNSSEC, use the DMARC checker.
Two TXT records at _dmarc that both start with v=DMARC1 | Multiple records. Both are discarded. This is the error, even when the two are identical. |
|---|---|
| One TXT record made of several quoted strings | Fine. DNS stores long TXT values as chunks of up to 255 characters, and receivers join them in order into one record (RFC 9989 §4.5). In dig it’s one line: "v=DMARC1; p=reject; " "rua=mailto:dmarc@example.com". |
One v=DMARC1 record plus a TXT record that doesn’t start with it | Not multiple. Records that don’t start with v=DMARC1 are discarded first (RFC 7489 §6.6.3 step 2, RFC 9989 §4.10 step 2), and the one DMARC record applies. Remove the stray record anyway: it does nothing, and anything in it is lost (see the split-record cause below). |
One record at _dmarc.example.com and one at _dmarc.mail.example.com | Fine. Different names. Each subdomain can have its own single record. |
The most common case. You signed up for a DMARC reporting service, or followed a mail provider’s setup guide, and added the record it gave you without removing the one that was already there. Now there are two, often with different p= values and different rua= addresses. Some registrars also create a default DMARC record when you turn on their email or DNS, which then sits next to the one you add later.
Two people or teams each “added DMARC” without checking. Or the domain is served by two DNS providers at once (name servers at both), and each zone was edited separately: resolvers get whichever provider answers, so a checker can report different records from one run to the next. Keep one authoritative copy of the zone, or make sure both providers hold the same single record.
A long record pasted as two separate TXT records instead of one TXT record with two strings. If both halves start with v=DMARC1, that’s multiple records. If only the first does, the second half is silently discarded as not-DMARC, so the tags in it (often the rua= address) never take effect and you get no reports. Put the whole value in one record; if your DNS host needs it split, split it into quoted strings inside that one record.
_dmarcSome DMARC services host your policy for you: you point _dmarc.example.com at their name with a CNAME, and they publish the record. A CNAME can’t share its name with any other record (RFC 1034 §3.6.2). Many DNS hosts refuse the combination. Where both exist, answers depend on which server and resolver you ask: some lookups return the vendor’s record, some return yours, and a checker can see both. Choose one: keep the CNAME and delete your TXT record, or delete the CNAME and publish one TXT record yourself.
_dmarcA v=spf1 record published at _dmarc by mistake. Receivers discard it for DMARC purposes (it doesn’t start with v=DMARC1), so it doesn’t cause the error on its own, but some checkers count every TXT record at the name and report it as a duplicate. It also means SPF isn’t where it should be: SPF belongs on the domain itself (example.com), not on _dmarc. Delete it from _dmarc and make sure the root has exactly one SPF record.
Say _dmarc.example.com has these two records, an older one of your own and one a reporting vendor gave you:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=none; rua=mailto:abc123@rua.vendor.example; fo=1Replace both with one:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com,mailto:abc123@rua.vendor.example; fo=1v=DMARC1, first, exactly once.p=: the policy you actually mean to enforce, normally the stricter of the two (reject over quarantine over none). Do the same for sp= and np= if either record has them; a record without sp= applies its p= to subdomains, so count that as its sp=.rua= tag, separated by commas. RFC 9989 defines rua as a comma-separated list of URIs (§4.6, §4.7), and a report should go to each. Do the same for ruf=.adkim=s or aspf=s, keep it._dmarc, including stray non-DMARC ones.Check the policy before you publish. While the duplicates were live, no policy was applied at all. The moment you publish a single record with p=quarantine or p=reject, receivers start enforcing it, and any sending service that doesn’t pass DMARC starts landing in spam or bouncing. If you haven’t read aggregate reports that show all your legitimate mail passing, publish the merged record with p=none first, watch the reports for a week or two, then raise it.
A rua address on a different domain from yours (a vendor’s, like the example above) only receives reports if that domain authorizes it with a record at example.com._report._dmarc.rua.vendor.example (RFC 9990 §4). The vendor publishes that on its side; you don’t add anything.
If an old record has pct=: RFC 9989 removed that tag and replaced it with t=y for testing mode (Appendix A.6). pct=100 is the default, so you can simply leave it out.
From a terminal on macOS or Linux:
dig +short TXT _dmarc.example.comYou want exactly one line starting "v=DMARC1. One line with several quoted parts is one record split into strings, which is fine. Two lines that each start "v=DMARC1 is the error. If the first line is a host name, _dmarc is a CNAME and the records below it come from that name.
On Windows:
nslookup -type=TXT _dmarc.example.comEach record appears as its own text = entry; you want one. To skip your local cache and ask two public resolvers directly:
dig +short TXT _dmarc.example.com @1.1.1.1
dig +short TXT _dmarc.example.com @8.8.8.8If you still see the old records, the resolver is serving a cached answer: wait for the record’s TTL (often an hour or less) and check again, or run the checker above.
No. A single TXT record can hold several quoted strings, and receivers join them in order into one record (RFC 9989 §4.5). In dig it shows as one line with several quoted parts. Multiple records means two or more separate TXT records at _dmarc that each start with v=DMARC1; dig shows each on its own line.
They discard both. Under RFC 7489 §6.6.3, policy discovery stops and DMARC is not applied to the message. Under RFC 9989 §4.10, all the records at that name are discarded and the lookup moves on as if the name had none, so a subdomain can fall back to its organizational domain’s record, but the domain’s own policy and reporting addresses are never used.
Yes. _dmarc.example.com and _dmarc.mail.example.com are different names, so each can hold one record. The rule is one v=DMARC1 record per name.
List both addresses in one rua tag, separated by a comma: rua=mailto:dmarc@example.com,mailto:reports@vendor.example. RFC 9989 defines rua as a comma-separated list. Don’t publish a second record for the second address.
If you manage domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with SPF, DKIM, DMARC and an A–F grade. Duplicate DMARC records show up as a dmarc_multiple_records issue with the record count, ready to filter in a CSV export. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Related: fixing Outlook’s 550 5.7.515 bounce and fixing SPF “too many DNS lookups”.