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

DMARC adoption is easy to start and hard to finish. Publishing a policy record takes minutes. Moving that policy to enforcement without blocking legitimate mail takes months of observation, and most stalled rollouts stall at the same point: the organisation has a p=none record, a monitoring report feed nobody reads, and no defined condition for moving to p=quarantine.

This is a sequencing problem, not a standards problem. The specifications are stable and well documented.

The three records and what each does

SPF (RFC 7208) authorises sending hosts by IP address. DKIM (RFC 6376) authorises messages by cryptographic signature. DMARC (RFC 7489) binds the two to the visible From domain and tells receivers what to do when neither passes.

DMARC is the only one of the three that carries an enforcement instruction. SPF and DKIM both have alignment problems: a message can pass SPF for an envelope domain that does not match the From domain, and a DKIM signature can be valid for a domain the recipient never sees. DMARC closes that gap by requiring alignment with the From domain.

Why p=none becomes permanent

The failure mode is organisational. A p=none policy produces aggregate reports, and aggregate reports are XML files that are unreadable without tooling. Without a defined owner and a defined exit condition, the policy stays at p=none indefinitely. It looks like progress and enforces nothing.

A rollout needs three things that a policy record does not provide:

1. A named owner for the report feed
2. A documented list of legitimate sending sources, including third parties
3. A written condition for each policy transition

Building the sending-source inventory

The inventory is the substantive work. For each source that sends mail as the domain, record:

• The sending service or host, and its business owner
• Whether it can be configured for SPF, DKIM, or both
• Whether it uses the organisational From domain or a subdomain
• The volume and the recipient population

Third-party senders deserve separate treatment. Marketing platforms, ticketing systems, CRM tools and payment processors frequently send on behalf of the domain and frequently cannot be configured for DKIM without a support request. Discovering them after moving to p=quarantine is the most common cause of a rollback.

Subdomains are the other common gap. A DMARC record on the organisational domain does not automatically apply to subdomains unless a sp= tag sets a subdomain policy or a wildcard record covers them. Many organisations have forgotten subdomains that send mail.

A transition sequence that holds up

A sequence that survives contact with a real mail estate:

1. Publish p=none with rua= reporting. Confirm reports are arriving and are being parsed.
2. Align SPF and DKIM for every known source. Fix alignment before changing policy. A source that passes SPF but fails alignment will fail DMARC.
3. Move to p=quarantine with a low percentage. The pct= tag allows partial application. Starting at a low percentage limits the blast radius of an unknown sender.
4. Increase pct= in steps. Each step should be followed by a defined observation period and a check of the aggregate reports for new failures.
5. Move to p=reject. Reject is the only policy that prevents delivery of unauthenticated mail using the domain.
6. Add sp=reject for subdomains once subdomain senders are inventoried.

Steps 3 through 5 are where the observation discipline matters. The reports are the control, not the policy record.

Where BIMI and other extensions fit

BIMI (Brand Indicators for Message Identification) requires an enforced DMARC policy as a precondition, along with a Verified Mark Certificate. It is a downstream consumer of DMARC enforcement, not a substitute for it. Organisations that pursue BIMI before enforcement are optimising the logo next to a message that is not yet authenticated.

Reading the reports without buying a platform

Aggregate reports are XML and are defined in RFC 7489 Appendix C. They can be parsed with a short script, and the fields that matter for a rollout decision are limited: the source IP, the count, the SPF result, the DKIM result and the disposition. A rollout decision needs the count of messages that would fail under the proposed policy, grouped by source. That is a small amount of data extracted from a large amount of XML.

Failure modes worth naming

Enforcing before aligning. Moving to p=quarantine while a legitimate source still fails alignment causes delivery failures that look like an outage.

Ignoring subdomains. The organisational domain enforces, the subdomain does not, and the subdomain is what a phishing campaign uses.

Treating reports as a compliance artefact. If nobody reads the reports, the policy transition has no evidence behind it.

Skipping the third-party inventory. External senders are the most common source of unexpected failures and the hardest to fix quickly because the fix usually depends on another organisation.

What enforcement actually buys

An enforced DMARC policy does not stop all phishing. It stops unauthenticated mail that uses the domain in the visible From field. Attackers respond by moving to lookalike domains, display-name spoofing and compromised legitimate accounts. Those are different problems with different controls.

What enforcement buys is a bounded, verifiable claim: mail claiming to be from the domain is either authenticated or rejected. That claim is worth having, and it is the precondition for a set of downstream controls including BIMI and stricter receiver-side handling. Getting there is a sequencing exercise with a report-reading discipline attached.

References

• IETF, RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).
• IETF, RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email.
• IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF, RFC 8617: The Authenticated Received Chain (ARC) Protocol.
• CISA, Binding Operational Directive 18-01: Enhance Email and Web Security.
• BIMI Group, BIMI implementation requirements.