dmarc.policy Reviewed July 2026

Quick fix

Keep `p=none` only long enough to identify all legitimate senders.

What this finding means

SecuTest evaluates the `p` tag. `none` is appropriate for discovery, `quarantine` requests suspicious handling, and `reject` is the strongest published disposition. Receiver behavior is ultimately local, so DMARC expresses a request rather than an absolute guarantee.

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 Direct-domain spoofing and phishing

How the attack or failure scenario works

An attacker sends a message with the organization's visible From domain but without aligned SPF or DKIM. Under `p=none`, the domain owner requests no enforcement action, so the receiver may deliver the message subject only to its own filtering.

Conditions and limitations

  • The attacker can send mail using the visible From domain.
  • The message fails both aligned SPF and aligned DKIM.
  • The receiver does not independently block the message or chooses to honor the monitoring-only policy.

Why it matters

Security and business impact A monitoring-only `p=none` policy records abuse but does not ask receivers to quarantine or reject unauthenticated direct-domain mail.

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. Keep `p=none` only long enough to identify all legitimate senders.
  2. Fix SPF and DKIM alignment for every authorized platform.
  3. Move to `p=quarantine` with a controlled percentage if operational risk remains.
  4. Progress to `p=reject; pct=100` once reports show that legitimate traffic consistently passes DMARC.

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.

Quarantine example
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

Reject example
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

Verify the fix

  1. Review aggregate reports by source IP, envelope domain, DKIM domain, and disposition.
  2. Send test messages from all legitimate platforms and confirm `dmarc=pass`.
  3. Run a controlled unauthorized test and confirm the receiver applies quarantine or rejection.
  4. Continue monitoring after enforcement to detect new or forgotten senders.
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

  • Moving directly to `p=reject` without discovering third-party senders.
  • Leaving `p=none` indefinitely while describing the domain as protected.
  • Assuming every receiver will apply the requested disposition identically.

Authoritative references