dmarc.single_record Reviewed July 2026

Quick fix

Review the exact evidence and identify the authoritative system that owns this control.

What this finding means

SecuTest evaluates single dmarc record as part of the DMARC control family. The finding should be interpreted with the technical evidence in the report and validated against the intended production configuration.

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

Why it matters

Security impact A weakness in single dmarc record can reduce the reliability of the domain's external security controls.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the domain.
  • The outbound mail platform or email-security gateway when signing or sender authorization is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Review the exact evidence and identify the authoritative system that owns this control.
  2. Apply the narrowest configuration change that resolves the reported condition.
  3. Validate the change in a controlled environment before production rollout.
  4. Repeat the external assessment after DNS, certificate, proxy, or application propagation completes.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, or provider values shown in your SecuTest evidence.

Inspect public DNS
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com

Inspect a DKIM selector
dig +short TXT selector._domainkey.example.com

Verify the fix

  1. Re-run the relevant dig, curl, TLS, or mail-authentication command from an external network.
  2. Confirm the previous finding no longer appears and no legitimate workflow regressed.
  3. Run a fresh SecuTest assessment and compare the complete evidence.
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

  • Changing an unrelated layer while the public edge continues to serve the old configuration.
  • Treating a scanner result as a substitute for controlled functional testing.
  • Failing to account for DNS or CDN propagation before re-testing.

Authoritative references