The EasyDMARC 2026 DMARC Adoption Report, drawn from an analysis of the top 1.8 million global domains, contains a finding that deserves more attention than it has received: more than 70 percent of DMARC-enabled domains have no aggregate reporting configured.
These organizations published a DMARC record. They are counted in the 52.1 percent adoption figure. But they added no rua= tag to receive aggregate reports, which means they have no way to see who is sending email that claims to come from their domain.
That gap defines one of the structural problems in email authentication in 2026: adoption and visibility are not the same thing. A DMARC record without reporting is a policy without feedback. And a policy without feedback cannot be safely enforced.
What Aggregate Reports Actually Tell You
DMARC aggregate reports – specified in RFC 7489 and preserved in the newly published RFC 9989 – are XML documents that receiving mail servers send back to the domain owner on a scheduled basis, typically once per day. Each report covers a 24-hour window and contains a record for every IP address that sent email claiming to originate from the domain during that period.
For each sending source, the report includes the authentication results: did SPF pass, did DKIM pass, and did the combination meet the alignment requirements for DMARC? It also includes message counts, so domain owners can see the volume attributed to each source.
This data answers questions that no other source can answer. You can see whether your email service provider is authenticating mail correctly. You can see whether an old sending domain is still generating traffic you thought was retired. You can see whether an unauthorized server is sending mail that claims to come from your domain – and whether that mail is passing or failing authentication.
Without an rua= tag in your DMARC record, none of those reports reach you. The receiving servers generate and discard them. The intelligence exists. It is simply never delivered.
The Path from p=none to p=reject Runs Through Your Reports
The standard DMARC deployment sequence – publish p=none, review reports, identify all legitimate sending sources, move to p=quarantine, then to p=reject – exists precisely because enforcement requires verified visibility. You cannot safely quarantine or reject mail until you know that every legitimate sending source is correctly authenticated.
Organizations that skip aggregate reporting at the p=none stage have no basis for making that judgment. They see no signal from the email ecosystem about what their domain is sending or how authentication is resolving. They either never move to enforcement, or they move to enforcement and break legitimate mail streams they did not know existed.
The EasyDMARC data shows this dynamic in operation. Of the 52.1 percent of top domains with DMARC records, only 43.9 percent apply an enforcing policy – p=quarantine or p=reject. The majority stuck at p=none is not primarily a population of organizations that do not care about enforcement. It includes a substantial share of organizations that published DMARC records for compliance purposes, set the policy to p=none as every configuration guide recommends for a safe starting point, and then stopped. They did not add reporting. Without reporting, there is no path forward.
The Data Gap Has a Security Consequence
The practical effect of the reporting gap is that more than 70 percent of DMARC-enabled domains are invisible to themselves. An attacker could be using their domain in a phishing campaign today. If those phishing messages fail DMARC, receiving mail servers may be generating aggregate reports documenting every IP address involved in the campaign. Those reports are going nowhere, because there is no rua= tag to route them.
If the attacker uses infrastructure that passes SPF alignment – a misconfigured third-party sender already authorized in the SPF record – the messages may be reaching recipients. Without aggregate reports, the domain owner has no signal that this is happening.
Neither scenario is detectable through the DMARC record alone. The record is a statement of policy. The reports are the feedback mechanism that makes the policy meaningful. One without the other is an incomplete implementation.
How to Close the Reporting Gap
Adding aggregate reporting to an existing DMARC record is a single DNS change. The rua= tag accepts an email address or URI that receiving mail servers should use to deliver reports. A minimal configuration looks like this:
v=DMARC1; p=none; rua=mailto:[email protected];
The address does not need to be on the same domain as the DMARC record, but if it is on a different domain, that domain needs to publish a consent record in DNS. Most organizations route reports to a dedicated inbox, a DMARC reporting service, or both.
The reports arrive as XML attachments, which are difficult to interpret manually at any volume. A DMARC reporting tool parses the XML, aggregates results across receiving servers, and presents the data in a format that shows which sending sources are passing, which are failing, and which unknown sources are generating traffic against your domain.
With that visibility, the path to enforcement becomes a structured process rather than a risk. You identify each sending source, confirm it is authenticated correctly, and move to enforcement only after every legitimate source is verified. The organizations at p=reject in the EasyDMARC data overwhelmingly have reporting configured. That is not a coincidence.
What the Numbers Say About Email Security in 2026
The 52.1 percent DMARC adoption figure represents genuine progress. Every domain that moves from no DMARC record to any DMARC record has increased the overall floor of email authentication and begun the process that eventually leads to enforcement.
But the 70 percent reporting gap tells a more specific story: adoption statistics and protection statistics measure different things.
A domain with p=none and no reporting has taken the first step. It has not protected anything. The protection comes from enforcement. The enforcement comes from visibility. The visibility comes from aggregate reports.
The organizations that have completed this path – the 43.9 percent at p=quarantine or p=reject – almost certainly got there because they read their reports and used that data to validate their sending infrastructure before tightening policy. The more than 70 percent without reporting have not started that part of the journey yet.
The EasyDMARC report also found that 95 percent of Fortune 500 companies have implemented DMARC, with more than 80 percent enforcing policies that actively block unauthorized email. In contrast, just over 50 percent of Inc. 5000 organizations continue to rely on monitoring-only policies. The divide between enterprises that have completed enforcement and mid-market organizations that have not maps closely onto which organizations read and acted on their aggregate reports.
Aggregate reporting is not an advanced feature. It is the mechanism the protocol was built around. Publishing DMARC without it is like installing a security camera with no recording – the policy is in place, but the evidence never accumulates.
Excello Mail gives you DMARC aggregate report processing built into the same platform you use to manage your email authentication configuration. Add your rua= address, connect your domain, and start reading the data that shows you who is sending as you. Sign up for free to Excello Mail and turn your DMARC record into a working security signal.