Can you have multiple DMARC records?
Published 15 Nov 2025
Updated 17 Oct 2026
12 min read
Summarize with
Updated on 17 Oct 2026: We clarified how to diagnose duplicate DMARC records and merge settings without losing reports or unexpectedly restoring enforcement.
No. Publish only one DMARC policy record at each DMARC DNS name, such as _dmarc.example.com. If DNS returns two records that both start with v=DMARC1 for the same lookup target, RFC 9989 says receivers discard both records. A receiver does not choose the newest or strictest value, so the policy and reporting destinations at that host cannot be relied on.
Do not choose the record that looks best and delete the other blindly. First identify what each record is trying to do, merge the valid tags into one record, publish one TXT resource record, then confirm the result with DMARC monitoring so real mail can be checked after DNS propagation.
One DMARC record per lookup target
You can have only one DMARC policy record for a specific DMARC lookup target. For example.com, that record lives at _dmarc.example.com. You can also have separate DMARC records for separate subdomains, such as _dmarc.mail.example.com, because that is a different DNS name.
Duplicate records break local policy discovery
When a receiver finds more than one DMARC policy record at the same lookup target, RFC 9989 requires all of them to be discarded. A higher-level policy can still be found during the DNS Tree Walk, but the duplicated local policy is not applied.
- One host: Publish one DMARC policy record at the same DNS name.
- Two hosts: A root domain and a subdomain can each have their own DMARC record.
- Two report URIs: Multiple reporting addresses can live inside one record when formatted correctly.
- Two policies: A single record cannot have two active p tags. Use one policy value.
If you are unsure what your DNS currently returns, use a DMARC checker before changing anything. A checker should show whether there is one DMARC record, no DMARC record, or more than one DMARC policy record at the target.
What counts as multiple DMARC records
A duplicate DMARC setup means the TXT record set at one lookup target contains more than one DMARC policy record beginning with v=DMARC1. It does not matter whether one says p=none and another says p=reject. The receiver does not infer which record is newer or safer.
Invalid duplicate DMARC recordsdns
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:d@example.com" _dmarc.example.com TXT "v=DMARC1; p=none;"
This often happens when vendor instructions say to add a basic v=DMARC1; p=none; record without checking the existing DNS answer. That instruction is safe only when no DMARC policy record already exists at the target. If one exists, preserve its intended settings and merge any required reporting URI into it instead of publishing another record.
|
|
|
|---|---|---|
Two DMARC policy records at one target | No | Both are discarded at that target |
One DMARC record plus unrelated TXT data | Yes | Only the record starting with v=DMARC1 is used for DMARC |
One TXT record with multiple tags | Yes | Normal DMARC syntax |
One TXT record split into quoted strings | Yes | One resource record after concatenation |
Root and subdomain records | Yes | Separate DNS names |
Multiple report addresses | Yes | Use one record |
How common DMARC setups should be interpreted.
A domain can request aggregate reports at more than one destination, but those destinations belong in the same rua tag. Separate the full URIs with commas and include mailto: before each email address. When a reporting URI uses another organizational domain, the report consumer must authorize that external destination in DNS or receivers ignore the URI, as specified in RFC 9990, Section 4.
How RFC 9989 handles duplicate records
RFC 9989, the current DMARC standard often called DMARCbis, says in Section 4.10 that all DMARC policy records returned at one lookup target are discarded when more than one remains. Older implementations based on RFC 7489 stop policy discovery when they encounter multiple records. Neither behavior makes the duplicated local policy dependable.
A higher-level policy can still apply
Under RFC 9989, discarding duplicate records at one target does not necessarily end the DNS Tree Walk. A receiver can continue toward the organizational domain or public suffix domain and use a valid higher-level policy. The local policy and local reporting destinations are still ignored.
Several TXT strings can be one record
A long TXT resource record can contain several quoted character strings. Receivers concatenate those strings in order without inserting a separator, so they do not count as separate DMARC policy records. Check structured DNS output or the provider's record rows before deleting anything.
Valid DMARC record stored as two stringsdns
_dmarc.example.com TXT ( "v=DMARC1; p=reject; " "rua=mailto:d@example.com" )
This example has one TXT resource record and one DMARC policy record. By contrast, two separate TXT rows that each begin with v=DMARC1 are duplicates. Count complete TXT resource records rather than quoted strings or visual wrapping in a DNS panel.
How to check for multiple DMARC records
For a "multiple DMARC records found" error, query TXT records at the DMARC name for the domain in the visible From address. Replace example.com with your domain. Use either command below.
Look up DMARC TXT records with digbash
dig TXT _dmarc.example.com. +noall +answer
Look up DMARC TXT records with nslookupbash
nslookup -type=TXT _dmarc.example.com.
In the dig answer, each TXT resource record has its own line. Two complete values beginning with v=DMARC1 at the same name indicate duplicates. Several quoted strings on one TXT answer line belong to one record. Ignore unrelated TXT values when counting DMARC records. If the answer is empty, rerun dig without the display options to distinguish a missing record from a DNS error.
Save the original values and TTL before editing. After the correction, confirm that the authoritative nameservers return one DMARC record, then recheck public resolvers after the previous TTL expires. If authoritative servers disagree, compare their zone data and check the delegation. Lowering the TTL during the edit does not clear older cached answers.
How to merge duplicate DMARC records
Choose the merged policy after reviewing authentication reports, rather than automatically selecting the strictest value. A duplicate p=none record can prevent a working p=reject record from being used at that target because both are discarded. Keep the intended policy and reporting destinations in a single DMARC policy record.
Wrong approach
- Add anyway: Publishing a vendor's DMARC snippet beside the existing record creates a duplicate.
- Pick randomly: Deleting one record without reading it can remove reporting or weaken policy.
- Assume override: DNS does not treat the latest TXT value as the active DMARC record.
Right approach
- Read both: Save every record and its TTL, then list the policy, report addresses, and optional tags.
- Merge once: Build one TXT resource record with one policy and the required reporting destinations.
- Verify after: Check DNS and real DMARC results after the record propagates.
Merged DMARC record with two aggregate report destinationsdns
_dmarc.example.com TXT ( "v=DMARC1; p=reject; " "rua=mailto:d@example.com,mailto:sec@example.net" )
Review existing sp and np subdomain policies, plus adkim and aspf domain-matching settings, before merging. Keep each tag once and resolve conflicting values with the domain owner. A change to strict matching can make legitimate mail fail DMARC. If ruf is already used for failure reports, merge its approved destinations separately from rua.
Fixing duplicates can restore enforcement
Publishing one valid p=reject or p=quarantine record can activate enforcement that the duplicates prevented. Check legitimate sending sources before restoring that policy. If authentication is unverified, use an agreed temporary p=none policy with aggregate reporting while investigating.
- Find records: Look up TXT at the exact DMARC owner name, not the root domain.
- Choose policy: Keep the intended policy value after checking current mail sources.
- Preserve reports: Carry forward valid aggregate report destinations into one rua tag.
- Publish one: Remove only the extra DMARC TXT resource records and leave one valid record. Preserve unrelated TXT data.
- Monitor results: Confirm that legitimate sources still pass DMARC after DNS updates.
Do not rely on an old pct value to limit enforcement after the merge. RFC 9989 removed percentage-based policy sampling, so pct=10 does not provide a 10% rollout under that standard.
Separate DMARC records for subdomains
Separate subdomain records follow the same one-record-per-name rule. You cannot have two DMARC policy records at _dmarc.example.com. You can have one record there and another at _dmarc.news.example.com because those are different DNS lookup targets.
DMARC policy lookup for a subdomain with its own record or an inherited organizational domain policy.
If a subdomain has its own valid DMARC record, that record is used for mail with the subdomain in the visible From address. If it does not, an RFC 9989 receiver continues the DNS Tree Walk toward parent labels to find an applicable policy. When the policy is found at the organizational domain, the sp value applies to an existing subdomain when present; otherwise the p value applies. For a subdomain that does not exist in DNS, np is used when present; otherwise sp applies if present, followed by p.
A subdomain record is not a duplicate
A separate record for a subdomain is valid when it is published at the subdomain's own DMARC host. The useful question is whether subdomains need records for your sending model, not whether records can be stacked at one host.
DMARC record count rule
The count is evaluated at each DNS lookup target, not across the domain portfolio.
Zero records
Continue
Policy discovery can continue toward a higher-level domain.
One record
Valid
One record is usable when its syntax and tag values are valid.
Two or more
Discarded
All DMARC policy records at that target are discarded.
What to do when a vendor asks you to add DMARC
Many sending platforms provide generic authentication instructions that include SPF, DKIM, and a basic DMARC value. That is useful for a domain with no policy, but it is risky when a record already exists. Treat those instructions as a prompt to check the current state, not as permission to add another TXT resource record.
- If none exists: Publish one DMARC record, usually starting at p=none while you collect reports.
- If one exists: Do not add another. Confirm whether the vendor only needs SPF or DKIM setup.
- If reports change: Add the new reporting destination inside the existing record, separated correctly.
- If policy changes: Review the effect first, especially before moving to quarantine or reject.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health checker helps identify DNS configuration issues. A DNS lookup alone does not prove that real mail passes DMARC. Confirm each sending service with a test message and its receiver-added Authentication-Results header, then review aggregate reports after the change.
Monitor duplicate DMARC records with Suped
Suped's DMARC reporting and email authentication platform detects duplicate records, explains the DNS correction, and connects the change to aggregate report data.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Add the domain, configure its reporting destination, then use Suped diagnostics to correct the duplicate record and review incoming reports. If DNS access is split between internal teams and an agency, hosted DMARC can reduce the number of places where people edit raw TXT strings.
For MSPs and teams managing multiple domains, review missing or duplicate records alongside sending sources that fail DMARC. Recheck both DNS diagnostics and incoming reports after each correction.
Common fixes and mistakes
The fix is to leave one valid DMARC policy record at the intended owner name. Check the published DNS answer, because a record saved under an unintended name does not provide policy for the intended domain.
Do not split DMARC by sender
One visible From domain should not have one DMARC record for marketing mail and another for billing mail. SPF and DKIM authenticate sending services. DMARC publishes one policy for the visible From domain.
- Wrong host: Some DNS panels append the domain automatically, so typing the full name can create an unintended owner name.
- Quoted strings: Several strings in one TXT resource record are valid, but separate DMARC records are not.
- Policy reset: A generic vendor record can unintentionally replace a deliberate quarantine or reject policy.
- Report loss: Removing a record without merging rua destinations can stop useful aggregate reporting.
A related issue can occur inside one record: each tag name must appear only once. A repeated p or rua tag is a syntax problem inside one TXT value. Merge reporting addresses into one comma-separated rua value rather than repeating the tag.
When someone asks why multiple records fail, the answer is that DNS returns an unordered record set. DMARC needs one policy at each lookup target, so the receiver cannot infer intent from conflicting records.
Views from the trenches
Best practices
Check for an existing DMARC record before adding vendor-provided DNS instructions.
Merge valid report destinations into one DMARC record before deleting any old TXT value.
Validate the exact DMARC host after DNS changes, then confirm reports still arrive.
Common pitfalls
Adding a vendor sample record beside an existing policy can disable working protection.
Typing the full host in a DNS panel that appends the domain can publish the wrong name.
Treating root and subdomain DMARC records as duplicates causes unnecessary deletion.
Expert tips
Keep a change log for DMARC policy edits so later vendor setup does not reset policy.
Use separate subdomains for high-risk senders when policy staging needs isolation.
Review aggregate reports after each DNS change to catch broken authentication quickly.
Marketer view
Marketer from Email Geeks says vendor instructions should tell users to add DMARC only when the domain does not already have a record.
2025-01-17 - Email Geeks
Marketer view
Marketer from Email Geeks says support guidance needs to account for customers who already have a working DMARC policy.
2025-01-18 - Email Geeks
