From p=none to Enforcement: A Working Sequence for DMARC Rollout

A DMARC policy at p=none reports what is happening to the domain without changing delivery. That makes it useful for discovery and useless as a control. The step from monitoring to enforcement is where organisations stall, often for months, because the move from observation to action surfaces all the legitimate mail streams that were never inventoried.

What DMARC does and does not do

Domain-based Message Authentication, Reporting and Conformance, defined in RFC 7489, coordinates two alignment checks. It asks whether the message passed SPF, an authorisation of sending hosts published as a DNS record, and whether it passed DKIM, a cryptographic signature over selected headers and the body. The domain is aligned when the authenticated domain matches the From domain.
Three things follow from that definition. DMARC does not itself authenticate anything. It depends on SPF or DKIM passing and aligning. It does not protect the display name or the friendly-from text in a client, which is a separate interface question. And it does not prevent spoofing of subdomains unless the record is published for those subdomains or a sp= tag sets an explicit subdomain policy.

Building the inventory without guessing

Aggregate reports are the inventory. Each report lists the IP addresses that sent mail claiming your domain, the SPF and DKIM results, and the disposition that was applied. The practical sequence is to collect reports for long enough to cover monthly and quarterly mail flows, which for most organisations means more than one billing cycle.

• Publish a p=none record with rua reporting to a mailbox you actually read.
• Parse the reports and build a list of every sending source, including marketing platforms, ticketing systems, and devices that relay mail.
• For each source, establish whether it is legitimate and whether it should align with the From domain.
• Fix or retire sources that cannot be made to align. Sources that treat your domain as a redirect rather than a From domain are the common false alarm. They generate SPF failures and appear in the reports without being a spoofing attempt.

Tightening in controlled steps

Move through three policy values rather than jumping to reject. Publish p=quarantine with a percentage below one hundred, watch what changes, then raise the percentage, then move to p=reject. Each step is reversible, and the reports tell you immediately whether a legitimate stream was misclassified.
Two technical items are worth fixing before enforcement rather than after. Ensure SPF resolves within the DNS lookup limit, because a record that exceeds it fails closed and silently breaks enforcement. And confirm DKIM key length and rotation practices, since a key that is too short or a selector that no longer resolves produces failures that look like spoofing.

Defensive implications

• Use the reports as an inventory task first, and enforcement as a second task with an owner.
• Set a subdomain policy deliberately. Leaving sp unset while feeling protected at the apex is a common gap.
• Add DMARC to the domain portfolio and to any newly registered name at registration time, not later.
• Monitor the transition weeks closely, because enforcement changes behaviour for third parties who were never informed.
• Keep the p=none record alongside a new policy during a migration so reporting is not interrupted. The limitation to state honestly: DMARC protects the From domain that publishes the policy. It provides no protection for a lookalike domain that an attacker registers, and it does not defend the display name. Where an attacker registers a similar domain, the From domain is genuinely theirs and the policy is genuinely theirs too. That is a brand monitoring problem, not an authentication problem.

References

• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489
• BIMI Group, Brand Indicators for Message Identification. https://bimigroup.org/