Moving to DMARC enforcement without disrupting legitimate email.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is now a baseline expectation. Google requires senders of more than 5,000 messages per day to Gmail accounts to publish a DMARC record, although it accepts a policy of p=none.¹ Federal civilian agencies were directed to reach p=reject under CISA Binding Operational Directive 18-01.² A record at p=none satisfies the first requirement, but it only requests reports. It does not ask receiving servers to act on mail that fails authentication, so it provides no protection against direct spoofing of the domain.

Organizations often hesitate to advance the policy because enforcement affects every system that sends mail on the domain's behalf. A billing platform, applicant tracking system, or marketing tool that is not correctly configured will have its messages quarantined or rejected. That risk is manageable when the work is sequenced so that every legitimate sender is identified and corrected before the policy changes.

How DMARC evaluates a message

DMARC does not inspect message content. A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the domain in the visible From: header, under either relaxed or strict alignment.³ Two distinctions account for most unexpected failures:

• SPF alignment compares the From: domain with the envelope sender (Return-Path) domain. A vendor that sends with its own bounce domain can pass SPF for that domain and still fail DMARC for yours.
• DKIM alignment compares the From: domain with the d= domain in the signature. A valid signature from the vendor's own domain does not satisfy alignment.

Only one of the two mechanisms needs to pass and align. DKIM is generally the more durable choice, because SPF results commonly fail when a message is forwarded through a server that the original domain's SPF record does not list.

Step 1: Build the sender inventory from aggregate reports

Begin by publishing a p=none policy with an aggregate reporting address and collecting reports for two to four weeks. Aggregate reports, now specified in RFC 9990, summarize the sources sending mail as the domain and their authentication results.⁴ They are the most complete inventory available, because they can include systems that were never recorded by IT or procurement.

A typical inventory includes the primary mail platform, marketing and newsletter services, recruiting and e-signature tools, the helpdesk, billing and ERP systems, payroll providers, and network-attached scanners. Aggregate reports are XML files delivered per receiver per day, so a reporting tool is recommended. The key measure is the share of legitimate volume that is both identified and aligned.

Step 2: Correct alignment for each legitimate sender

Each legitimate sender requires one of three remediations:

1. Enable DKIM signing with the organization's domain. Most established platforms support a custom signing domain, typically configured through two or three DNS records.
2. Move the sender to a dedicated subdomain, such as billing.example.com. This also contains the reputational impact of any single vendor.
3. Retire the sender when the business no longer needs it.

Review the SPF record at the same time. SPF evaluation is limited to 10 mechanisms and modifiers that require DNS lookups, and exceeding that limit produces a permanent error.⁵ Records that chain several include: statements can exceed the limit without notice. Reducing the number of senders that depend on SPF is more sustainable than flattening the record into IP addresses, which must then be maintained by hand.

Step 3: Stage the policy under the current standard

In May 2026 the IETF published RFC 9989, which obsoletes RFC 7489 and moves DMARC to the Standards Track.³ Three changes affect rollout planning. The pct tag, previously used to apply a policy to a percentage of failing mail, has been removed. A new t tag signals that the domain owner is testing its policy. A new np tag sets the policy for subdomains that do not exist, a common target for spoofing. Because receivers adopt new specifications at different rates, confirm how major mailbox providers handle these tags before relying on them.

Advance to p=quarantine before p=reject. An interim record might read:

v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com

This record quarantines failing mail from the organizational domain and requests rejection of mail from non-existent subdomains, which should never send legitimate mail.

Step 4: Confirm readiness for p=reject

Move to p=reject when three conditions are met. Every sender with meaningful volume is aligned or retired. The remaining unaligned traffic has been stable and explained for at least two full reporting weeks. A named owner reviews reports on an ongoing basis. The third condition is the one most likely to lapse, because new software is purchased after the project closes and its mail must be aligned before it is put into production.

Related controls

Enforcement is a prerequisite for Brand Indicators for Message Identification (BIMI), which requires a policy of quarantine or reject at the organizational domain.⁶ Once DMARC is at enforcement, MTA-STS and TLS Reporting address transport encryption for inbound mail and can be deployed with modest additional effort.⁷⁸

Practical takeaways

• Treat p=none as a monitoring phase with an end date, not a final state.
• Use aggregate reports as the authoritative sender inventory.
• Prefer DKIM alignment with the organization's own domain for every third-party sender.
• Update DMARC records and runbooks for RFC 9989, including removal of pct.
• Assign ongoing report review to a named owner before moving to p=reject.