Adding a second DMARC policy is not a way to update the first one. The two values do not become a combined instruction, and DNS does not supply an ordered “newest policy wins” rule for them.
The repair begins with the complete TXT record set at the affected name. Identify how many current-version policy candidates exist, distinguish their boundaries from display formatting and reconcile the owner's intended policy before editing.
Inspect the exact DNS owner
Start from the domain in the message's From address. Query the applicable _dmarc name and record the authoritative and relevant recursive answers with timestamps.
A root-domain policy and an explicit subdomain policy are published at different names. They are not duplicates merely because both exist. Their relationship is governed by discovery and scope. The subdomain-policy guide explains how to assess that relationship.
Likewise, a policy TXT at the domain root is not a substitute for the relevant _dmarc name. Repair the intended owner rather than adding records in several places and hoping the receiver chooses one.
Distinguish a record from its character strings
A single TXT resource record can contain more than one character string. DMARC concatenates those strings in order before parsing under RFC 9989 §4.5. Displayed quotes around the strings are normally the lookup tool's representation.
This synthetic zone-style fixture is one TXT record:
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; " "rua=mailto:reports@example.com"Its concatenated value contains a separator and space between the p and rua tags because those characters were included inside the strings. A resolver does not invent a missing separator when it joins them.
By contrast, two separate TXT resource records are two records. Do not concatenate them in a spreadsheet or incident note and then analyse that invented value.
Filter before counting policy candidates
The RFC 9989 §4.10 DNS tree walk discards records that do not start with the v tag identifying the current version. If multiple DMARC policy records are returned at one target, it discards all of them at that target.
An unrelated TXT value at the same name is therefore not automatically a second DMARC policy. Count the relevant candidates after preserving each original record and applying the defined filtering.
The following are synthetic fixtures, not live lookup results:
- Record set at one target: One current-version DMARC candidate; Interpretation to investigate: Parse that candidate and its policy semantics
- Record set at one target: One DMARC candidate plus unrelated descriptive TXT; Interpretation to investigate: Unrelated TXT is not a second DMARC policy candidate
- Record set at one target: Two separate records starting with v=DMARC1; Interpretation to investigate: Competing policy candidates; no merging or last-record selection
- Record set at one target: One record made of two character strings; Interpretation to investigate: Concatenate its strings in order, then parse
Under RFC 9989 §4.7, the version tag must appear first with the exact value DMARC1. A string that merely mentions that text later is not a replacement for the defined record identification.
Trace the consequence instead of promising one error label
Multiple policy candidates at an initial lookup can leave no valid policy at that name. Under RFC 9989 §4.10.1, current discovery may then continue through the applicable DNS tree walk. A usable policy found elsewhere can affect the message.
For example, in a fictional subdomain fixture, two candidates at _dmarc.alerts.example.com are discarded. If discovery subsequently finds an applicable valid policy at an organisational domain, that policy can apply. If the complete discovery finds none, DMARC does not apply to the message.
Do not promise that every duplicate produces the same Authentication-Results label or SMTP response across implementations. Preserve the receiver's actual result and its applicable discovery path.
Reconcile one approved policy before changing DNS
Determine which values are intentional. Two records may have been created by different teams, by an old reporting integration or by a migration that added instead of replacing data.
Build one coherent approved value. Preserve intended report destinations and review alignment, subdomain scope and testing settings. If several aggregate recipients are authorised, a comma-separated rua destination list defined in RFC 9989 §4.7 in one policy can express that request; it does not require multiple policy TXT records.
Verify any required external reporting permission separately under RFC 9990 §4. Combining destination addresses does not grant permission at a destination you do not control.
Make and verify the correction
Save the before-state, complete approved after-state, owner name, TTL and change authorisation. Replace the competing candidates with the intended single policy at that name.
Then check authoritative servers for the new record set and examine relevant recursive views. Cached earlier values may remain for a time, so one current authoritative answer is not evidence that every receiver has discarded the old set.
Run a representative message test and inspect its trusted authentication and policy results. DNS correction establishes a valid configuration dependency; it does not make an unrelated DKIM signature align or correct an application's envelope identity.
Use the record workflow to connect publication and message verification.
Prevent the same conflict on the next integration
Give the domain a policy owner and require integrations to propose a diff to the existing record rather than add another policy blindly. Retain the business purpose and lifecycle of each reporting destination.
A useful migration handoff names who removes obsolete configuration and who verifies the resulting record set. The durable fix is one intentional policy at each relevant name, with discovery, reporting and actual mail behaviour understood.
Keep the decision and evidence separate
For the split-string fixture, the first string ends with a semicolon and space, so joining it with rua yields one coherent value. Two separate records instead remain two candidates, regardless of display order. Keep the full-discovery result distinct from the single-name defect. RFC 8767 §4 also means TTL expiry is not a guaranteed global removal deadline for cached data. The fixture was not published or queried.