DMARC Reports and the Path to Enforcement

Publishing a DMARC record with p=none is where most organizations start, and where many of them stay. A monitoring policy gives you reports but stops nothing. Anyone can still send mail that appears to come from your domain. The value of DMARC comes from enforcement, and reports are how you get there safely.

What DMARC Reports Contain

A DMARC record can request two kinds of report.

Aggregate Reports (RUA)

Aggregate reports are XML files sent, usually once a day, by each mailbox provider that received mail claiming to be from your domain. Each report lists:

• The IP addresses that sent the mail
• How many messages came from each one
• Whether SPF and DKIM passed
• Whether each result aligned with the From domain
• What policy the receiver applied

They contain no message content. You request them with the rua tag:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Failure Reports (RUF)

Failure reports describe individual messages that failed DMARC. Few providers send them because of privacy concerns, and Gmail does not. Do not rely on them.

Why You Need a Tool

A domain with moderate volume can receive dozens of XML files a day from different providers. Reading them by hand is impractical.

A DMARC reporting platform collects the reports, groups IP addresses into named sending services and shows pass and fail rates for each one. If you send reports to an address at another domain, that domain must publish a small authorization record. Reporting vendors handle this for you.

Reading the Results

Sort every sending source into one of three groups.

Legitimate and Aligned

These sources pass SPF or DKIM with your domain. No action is needed.

Legitimate but Not Aligned

This is the group that needs work. Typical examples are a CRM, helpdesk or invoicing tool that sends as your domain but signs with its own. The fix is usually to enable custom DKIM in that platform and, where possible, a custom return path, so the authenticated domain matches your From address.

Unknown or Fraudulent

Some sources will be unfamiliar. Investigate before dismissing them. They are often forgotten internal systems or a tool another department signed up for. What remains is spoofing, which is exactly what an enforcement policy will block.

Forwarded mail also appears here. Forwarding breaks SPF, and results in the reports can look like failures from servers you do not recognize. DKIM usually survives forwarding, which is one reason every source should be DKIM-signed.

Moving to Enforcement

Tighten the policy in stages.

1. Start with p=none and collect reports for two to four weeks.
2. Fix alignment for every legitimate source.
3. Move to p=quarantine once legitimate mail passes consistently.
4. Monitor for a few weeks, and resolve anything new that appears.
5. Move to p=reject.

Do not rush the second step. Enforcing before all legitimate sources are aligned will send your own mail to spam or bounce it.

Subdomains

The sp tag sets a policy for subdomains. If it is absent, subdomains inherit the main policy. Check reports for subdomains you did not know were sending. Domains that never send mail should publish p=reject straight away.

What Changed in the 2026 DMARC Update

In May 2026 the IETF published an updated DMARC specification as RFC 9989, with reporting covered in RFC 9990 and RFC 9991. Existing records continue to work, and the version string remains v=DMARC1. The main changes are:

• The pct tag, used to apply a policy to a percentage of mail, is now historic. Receivers applied it inconsistently.
• A new t tag requests testing mode. With t=y, receivers are asked to apply the policy one level below the one published.
• A new np tag sets the policy for subdomains that do not exist, a common target for spoofing.
• The organizational domain is now found through a DNS tree walk instead of the Public Suffix List.

There is no need to rewrite every record at once. If your rollout plan depended on pct, plan around the staged approach above, and review records that use deprecated tags.

Common Mistakes

• Leaving the policy at p=none indefinitely.
• Publishing a record with no rua address, so no reports arrive.
• Moving to p=reject in one step without reviewing reports.
• Forgetting marketing, billing or support platforms when fixing alignment.
• Publishing more than one DMARC record for the same domain.
• Ignoring reports after enforcement. New tools get added, and they need aligning too.

After Enforcement

Reaching p=reject is not the end of the project. Keep reviewing reports monthly. They are the earliest warning that a new service has started sending as your domain, or that an existing one has changed its configuration. Enforcement is also a prerequisite for BIMI, which displays your logo next to authenticated mail.