Can You Have Two DMARC Records? What Breaks When You Do

This is a genuinely nasty failure mode, because every surface lies to you. Your DNS provider shows two healthy records. Your email vendor’s setup wizard shows a green tick, because it found the record it asked you to add. Nothing bounces. The only visible symptom is that forged mail claiming to be from your domain keeps getting delivered, and your aggregate reports stop arriving — and neither of those is something you notice on a Tuesday.

Check it in one command

dig +short TXT _dmarc.yourdomain.com

# or, without dig:
nslookup -type=TXT _dmarc.yourdomain.com

Count the lines that begin v=DMARC1. One is correct. Two or more is the problem in this article. Zero means you have no DMARC at all, which is a different article.

One important nuance: other TXT records at the same name are harmless. Receivers filter the set down to records starting with v=DMARC1 before counting, so a domain-verification string sitting at _dmarc does not trigger this. Only genuine DMARC records count.

Why the standard makes it fail closed

It looks harsh. It is the only safe option available. Consider what a receiver would have to do otherwise: given p=none and p=reject at the same name, merging them means inventing a rule the domain owner never expressed. Picking the stricter one means an attacker who can add a DNS record could not weaken you — but picking the more permissive one means anyone who can add a record can switch your protection off. Picking the first means the answer depends on the order a DNS server happened to return, which is not stable.

Faced with an ambiguous policy, the specification chooses "no policy" over a guess. That is the same instinct behind every fail-closed decision in infrastructure: a visibly absent answer is better than a confidently wrong one.

How you end up with two

• You added a second sending provider. The new vendor’s onboarding said "add this DMARC record", you added it, and the first one was still there. This is by far the most common cause.
• Someone set DMARC up months ago and nobody remembered. A record added during a deliverability push a year earlier is invisible until the day someone adds another.
• Your DNS provider allows duplicate TXT records at one name without warning. Most do — it is legal in DNS generally, just not for DMARC.
• A migration copied a zone file into a provider that already had records for the same domain.
• A subdomain policy was added as a second record at the apex instead of at _dmarc.sub.yourdomain.com, where it belongs.

Merging them correctly

The fix is one record that expresses what you actually want. It is not concatenation — DMARC has no equivalent of SPF’s include:, and each tag may appear once.

Say you found these two:

_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"
_dmarc  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@vendor.example"

1. Choose one policy. Take the weaker of the two — here p=none — unless you already know your mail is fully authenticated. You are about to turn DMARC on for the first time in practice, even though it has "been there" for months, and you do not want to discover your gaps by having real mail rejected.
2. Keep both reporting addresses. rua accepts a comma-separated list, and this is the one place where combining is genuinely supported.
3. Delete both records, then create one. Editing one and leaving the other is how people end up back here.
4. Verify with dig again. Confirm exactly one line begins v=DMARC1.

_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com,mailto:dmarc@vendor.example"

One caveat on that second address: if it is at a different domain, that domain has to authorise the reports, or receivers will not send them. The mechanism is a TXT record at yourdomain.com._report._dmarc.vendor.example containing v=DMARC1. Vendors that ask for a rua at their own domain normally publish it for you, but not always — ShipReady reports unauthorised external DMARC reporting when the authorisation is missing, because the symptom otherwise is simply that reports never arrive.

Once there is one record, you have a working starting point rather than a working-looking one. Moving from `p=none` to `p=reject` is the next step, and the reports you just started receiving are what makes it safe.

The DNS provider trap that creates duplicates

Worth knowing before you edit anything, because it is responsible for a large share of duplicate records — and for records that appear to vanish.

DMARC lives at the name _dmarc.yourdomain.com. Most DNS control panels ask for the name relative to your zone and append the domain themselves, so the value you type into the Name field is _dmarc. Some panels do not append anything and expect the fully qualified name. A few accept either and guess.

The double-append case is the one that produces duplicates. Someone adds a record, checks with dig, sees nothing, adds it again in a different format, and the second attempt works. The first is still there — invisible in a lookup of _dmarc.yourdomain.com, so it looks harmless. It usually is, since it is at a name nothing queries. But if both attempts landed at the correct name in different formats, you now have two, and neither of them is doing anything.

Always verify by querying the fully qualified name rather than by reading the control panel. dig +short TXT _dmarc.yourdomain.com tells you what receivers actually see; the panel tells you what you typed.

SPF has the same rule, and it is even easier to trip

Publishing two SPF records is the same class of mistake with the same outcome. RFC 7208 §4.5 requires a receiver that finds more than one v=spf1 record to return permerror, which in practice means SPF is not evaluated at all.

SPF trips more often because adding a sender genuinely does mean adding something to the record — so the instinct to paste a second line is stronger. The correct move is to merge the mechanisms into the single record:

# Wrong — two records, SPF disabled
@  IN  TXT  "v=spf1 include:_spf.google.com ~all"
@  IN  TXT  "v=spf1 include:sendgrid.net ~all"

# Right — one record, both senders authorised
@  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

While merging, watch the ten-lookup limit: each include: costs at least one DNS lookup and nested includes cost more, and exceeding it produces the same permerror you were trying to avoid. If you are close to the limit, drop include: entries for services you no longer use rather than adding more.

The full picture of what each record proves — and why SPF and DKIM alone do not protect the address your recipients see — is in SPF, DKIM and DMARC: what each one actually proves.

How ShipReady detects it

ShipReady resolves _dmarc for the domain you scan, filters for records beginning v=DMARC1, and reports more than one DMARC record with the count it found. It reports duplicate SPF records the same way. Both are rated high severity, because the practical effect is not a weakened policy — it is no policy, on a domain whose owner believes it has one.

It reads public DNS only, exactly as a receiving mail server would. Scan your domain free to see the whole Email pillar at once, or browse every email check individually.