dmarc.single_record Reviewed July 2026

Quick fix

Export all current DMARC records and identify unique tags from each.

What this finding means

DMARC requires one effective policy record at the `_dmarc` owner name. SecuTest flags multiple `v=DMARC1` values because receivers must treat the policy as invalid rather than merging it.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type DMARC policy invalidation

How the attack or failure scenario works

When multiple DMARC records are published, receivers cannot determine which policy is authoritative. The result is typically a permanent policy error, which can reduce enforcement against forged visible From domains and disrupt reporting.

Conditions and limitations

  • Two or more logical `v=DMARC1` records exist at the same `_dmarc` name.
  • Receivers follow RFC-compliant policy discovery.
  • Abuse impact increases when the domain depends on DMARC rejection to block direct spoofing.

Why it matters

Security and business impact Multiple DMARC records make the policy invalid, so receivers cannot reliably enforce the intended anti-spoofing controls.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Export all current DMARC records and identify unique tags from each.
  2. Merge the required policy, reporting, alignment, and subdomain settings into one record.
  3. Remove every duplicate value from the authoritative DNS zone.
  4. Validate external reporting authorization if `rua` or `ruf` points to another domain.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Find duplicates
dig +short TXT _dmarc.example.com | grep -i 'v=DMARC1'

Merged example
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@example.com"

Verify the fix

  1. Query at least two public resolvers and confirm exactly one logical DMARC record.
  2. Parse the merged record and confirm `v` is first and `p` is present.
  3. Verify aggregate reports continue arriving at the intended destination.
  4. Send controlled legitimate and unauthorized messages and inspect receiver results.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Treating DNS TXT string fragments as separate records.
  • Deleting the record that contains the active reporting destination.
  • Leaving one duplicate at a secondary DNS provider that remains authoritative.

Authoritative references