DMARC Policy and Reporting

A published DMARC record with p=none is common, easy to set up, and provides essentially no protection against domain spoofing — it only produces visibility. Understanding the difference between having DMARC and having enforced DMARC is the single most consequential distinction in this entire topic area.

The policy tag: what actually happens on failure

The p= tag is DMARC's core instruction to receiving servers:

• p=none — take no enforcement action; deliver the message normally regardless of authentication result. This is a monitoring-only mode.
• p=quarantine — route messages that fail DMARC to spam/junk instead of the inbox.
• p=reject — refuse delivery of messages that fail DMARC outright.

A domain with SPF and DKIM both correctly configured but DMARC set to p=none (or no DMARC record at all) has no enforced protection against visible-From spoofing — the authentication signals exist, but nothing acts on a failure.

sp=: subdomain policy

The sp= tag sets a separate policy specifically for subdomains, independent of the main policy. This matters because subdomains are a common gap: an organization might have p=reject on its root domain while every subdomain used by a marketing tool, staging environment, or legacy system defaults to inheriting a weaker or absent policy. Without an explicit sp= tag, subdomains inherit the main p= policy — but many organizations discover subdomains they'd forgotten existed once DMARC reporting starts surfacing sending activity from them.

pct=: partial rollout

The pct= tag specifies what percentage of failing messages the policy actually applies to — a gradual-rollout mechanism. pct=50 with p=quarantine means roughly half of DMARC-failing mail is quarantined and half is delivered normally, evaluated per-message. This exists specifically to let organizations step into enforcement gradually rather than as an all-or-nothing switch, and is a legitimate part of a careful rollout, not a misconfiguration on its own — but a pct well below 100 left in place indefinitely after the initial rollout period usually means the rollout was never completed, not that a permanent partial-enforcement state was intended.

Reporting: rua and ruf

• rua= (aggregate reports) — specifies an address to receive periodic (typically daily) XML summaries of DMARC evaluation results in aggregate: which sources sent mail as your domain, how much passed or failed, and why. This is the primary operational visibility mechanism and should be configured on essentially every DMARC record.
• ruf= (forensic reports) — specifies an address to receive per-message failure reports containing more detail about individual failing messages. Forensic reporting has real, well-documented privacy and support limitations: many major mail providers do not send forensic reports at all due to the message-content privacy concerns involved, and the reports that are sent may be redacted. ruf should not be relied upon as the primary visibility mechanism — treat aggregate (rua) reporting as the operational baseline and forensic reporting as a supplementary, inconsistent signal.

Without a configured rua address, an organization has no visibility into who is actually sending email as their domain — legitimate services and potential spoofing attempts alike — making it effectively impossible to safely progress toward enforcement, since there's no way to confirm all legitimate senders have been identified first.

The safe enforcement progression

Do not move directly to p=reject. This is the single most common way organizations trying to "just turn on DMARC properly" break their own legitimate outbound mail — a marketing platform, a billing system, or a helpdesk tool sending as the domain without being included in SPF or configured for DKIM will have its mail rejected outright the moment enforcement takes effect, often without any warning before the rollout.

The standard, safe progression:

1. Monitor (p=none with rua configured) — collect real data with zero delivery impact.
2. Analyze — review aggregate reports over a meaningful window (typically 30-60 days, long enough to catch monthly/quarterly sending patterns like billing runs) to identify every legitimate sending source.
3. Remediate — add every legitimate source to SPF and/or configure it for DKIM signing before enforcement begins.
4. Quarantine (p=quarantine) — step into enforcement with a reversible outcome (spam folder, not outright rejection) while confirming no legitimate mail is being affected.
5. Reject (p=reject) — full enforcement, once quarantine has run long enough to confirm the remediation was complete.

Practical next steps

Run IT KORR's SPF/DKIM/DMARC Checker to see your domain's current DMARC policy, alignment configuration, and reporting setup. For the SPF and DKIM configuration this progression depends on, see SPF Configuration and Troubleshooting and DKIM Configuration and Troubleshooting. IT KORR's Compliance & Governance service can help align email authentication enforcement with HIPAA, SOC 2, and NIST requirements where DMARC enforcement is a documented control.