Blog · Dmarc
Should You Keep Collecting DMARC Aggregate Reports After You Reach p=reject?
Yes. Keep the rua= tag in your DMARC record even after the policy is at p=reject. Aggregate reporting is the only sensor you have once enforcement is active, and the October 2026 census of 361 million domains shows that the majority of fully enforced domains have already turned it off.
This is not a theoretical concern. Roughly 19.1 million domains currently publish a DMARC record with p=reject. About 11 million of those have no rua= address at all. They enforced, then went silent.
The October 2026 Census: 56% of Enforced Domains Have Stopped Reporting
Defaults.Exposed runs a monthly census of domain and email security. The October 2026 edition is based on a 12 October 2026 snapshot of 361,301,790 domains that exist. 85,764,215 of those publish a DMARC record. The policy split looks like this:
| Policy | Domains | Of those, with rua= | Percentage with rua= |
| --- | --- | --- | --- |
| p=none | 43,720,472 | 8,671,108 | 20% |
| p=quarantine | 22,847,082 | 18,198,145 | 80% |
| p=reject | 19,152,043 | 8,360,218 | 44% |
The non-monotonic pattern is the point. Domains at p=quarantine collect aggregate reports more often than domains at p=reject. Roughly 35 million of the p=none records have no rua= address at all. Operators are most likely to keep reporting during the migration, then drop it once they reach the enforced state.
The thread that surfaced this data asked a direct question: once you are at p=reject, do you still need aggregate reports, or did you drop them to clean up the inbox? The honest answer is that the reports are still doing work after enforcement, but operators have stopped reading them. That gap between "the data exists" and "someone is reading the data" is exactly what the rest of this article is about.
What p=reject Actually Does and Does Not Do
p=reject tells receivers to refuse mail that fails DMARC at the envelope. That is the entire scope of what the policy does.
p=reject does not tell you whether the reject happened correctly. p=reject does not tell you whether a new third-party sender has started sending on your behalf. p=reject does not tell you whether alignment has regressed for a sender you already approved. p=reject is a wall. It is not a sensor.
The wall protects the receiving inbox. The sensor protects you, the operator, against silent drift in your own environment. Without the sensor, you learn about misconfigurations only when a customer complains that the password reset never arrived.
What Aggregate Reports Still Show You After Enforcement
RUA reports are produced by receivers regardless of policy outcome. At p=reject, you should still see reports. The interesting fields in those reports do not change because the policy tightened.
What does change is the operator's attention. Reports that were useful at p=none (which sender is failing DMARC and why) become reports that are easy to ignore at p=reject (because the failures are being rejected anyway).
The reports still contain:
- The DKIM d= domain for each sending source
- The SPF Return-Path identity for each sending source
- The source IP for each sending source
- The header From domain that the receiver saw
- The count of messages from each source
- The DKIM and SPF result for each source
These fields matter at p=reject. The reports do not stop because you enforced. The senders that need attention just get quieter.
The Three Signals in Post-Enforcement Reports Worth Watching
There are three signals in post-enforcement reports that justify keeping the rua= tag active.
Signal 1: A new sender appears. A DKIM d= domain, a Return-Path domain, or a source IP shows up that has never appeared in any prior report. The most common cause is that someone in your organization added a new ESP, CRM, or transactional provider and did not loop you in. The risk is that legitimate mail is being rejected because the new sender is not aligned with your From domain. A concrete example: a marketing team adds a new CRM that signs outbound with DKIM d=mail.newcrm.example but your From domain is corp.example; every CRM campaign fails DMARC at p=reject because the d= domain does not align.
Signal 2: A known sender's alignment drifts. A sender that previously passed alignment now fails it. The most common causes are a DKIM key rotation you were not told about, a switch to a new sending subdomain, or an SPF include change. The risk is silent rejection of legitimate mail you did not know was at risk.
Signal 3: A known sender's volume shifts by an order of magnitude. Volume that jumps up or down by 10x or more is almost never a benign change. Common causes are platform changes, infrastructure migrations, billing changes, or compromise of a legitimate sender. The risk is either a reputation problem you do not know about yet, or an active incident. A legitimate ESP that suddenly drops to one tenth of its usual volume after you reach p=reject is a signal that something is being rejected; the operator needs to know within days, not quarters.
These three signals are the difference between a domain that is enforced and a domain that is actually monitored. The challenge is that a domain sending tens of millions of messages a month produces enough aggregate traffic that spotting the three signals by eye is not realistic. DMARCFlow is built specifically to surface these three classes of change as alerts, which is why keeping the rua= tag active is only useful if something is actually reading the data.
When It Is Acceptable to Reduce Reporting and When It Is Not
Reducing the volume of reports you read is reasonable. Removing the rua= tag is not.
If the volume of aggregate reports is the problem, sample at the receiver side, not in your DNS. Most receivers will accept multiple rua= addresses and you can route a sample to a quieter destination. You can also reduce the number of rua= destinations you actively read.
What you cannot do is remove the rua= tag entirely while the policy is at p=reject. The pct= tag is for staged rollout, not for reducing report volume; do not conflate the two. If you set pct=10 to slow enforcement, the receivers still send reports for the 10%. Removing the rua= tag blinds you to what those 10% are doing.
If your rua= destination is failing or bouncing, fix the destination. An empty report mailbox is worse than no reports, because the receivers will silently stop sending and you will not notice until a real incident hits.
A Practical Post-Enforcement Reporting Checklist
A weekly review of post-enforcement reports should cover:
- New DKIM d= domains since the last review. Each new one is a sender that did not exist before.
- New SPF Return-Path domains since the last review. Same.
- New source IPs in the top ten by volume. Same.
- Any sender where the DKIM or SPF result changed since the last review. That is alignment drift.
- Any sender where volume is more than 2x or less than half of last week's volume. That is a volume anomaly.
- Quarterly: re-run the sender inventory you built during the p=none to p=reject migration. The inventory from migration day is not the inventory you have today.
That checklist is the minimum a human needs to do. If the volume of incoming reports is too high to maintain weekly, DMARCFlow runs the same checks automatically and turns the results into alerts you can act on.
Keep at least one active rua= destination that you read. Document the destination and the recovery contact in your DNS runbook. If the destination mailbox fails, you want to know within a day, not within a quarter.
How DMARCFlow Reads Post-Enforcement Reports So You Do Not Have To
The argument for keeping aggregate reporting only matters if the data is actually readable. Most operators do not have time to parse raw RUA XML every week. That is the gap DMARCFlow fills.
DMARCFlow parses RUA reports and surfaces the three signals above automatically. A new sender appearance becomes an alert rather than a row buried in raw aggregate output. Alignment drift on a known sender shows up as a trend rather than a one-off rejection you have to spot by eye. Volume anomalies are flagged against the sender's own baseline rather than a global threshold.
The Subdomain Discovery feature catches new subdomains that were not in your sender inventory at migration time. That is the most common post-enforcement failure mode for organizations that run a large or evolving infrastructure. If a new transactional subdomain starts sending after you reach p=reject, you will not see it in a manual review of aggregate reports until a customer complains. DMARCFlow surfaces it as soon as the first RUA report lands.
DMARCFlow does not decide for you whether a new sender is legitimate. The alert tells you a new sender appeared; you still have to confirm it is authorized and aligned. What DMARCFlow does is remove the work of finding the signal in raw data.
FAQ
Q: Does p=reject stop DMARC aggregate reports from being generated?
No. Receivers send RUA reports based on the rua= tag in your DMARC record, not on your policy. At p=reject you should still see reports showing the mail that was rejected.
Q: What does an aggregate report at p=reject actually contain?
The same fields as before: source IP, DKIM d= domain, SPF Return-Path identity, header From domain, DKIM and SPF result, and message counts. The policy outcome (quarantined, rejected, accepted) is in the disposition field.
Q: Should I remove the rua= tag once my DMARC policy is at p=reject?
No. Removing the rua= tag removes your only visibility into post-enforcement drift. Keep the tag, reduce the volume you actively read if needed, but do not remove it.
Q: How long should I keep aggregate reports for a fully enforced domain?
Indefinitely. Reports are the audit trail for any alignment or sender incident. The Defaults.Exposed October 2026 census shows that 56% of enforced domains have already lost this audit trail by removing the rua= tag.
Q: What is the difference between rua=mailto: and pct= for reducing report volume?
rua=mailto: controls where reports go. pct= controls what fraction of mail the policy applies to. They are independent. If you want to slow enforcement, use pct=. If you want to read fewer reports, reduce the number of rua= destinations you actively monitor. Do not use either as a substitute for turning off the other.
Q: Can I rely on RUF (forensic) reports instead of RUA reports at p=reject?
No. RUF reports contain message samples and are useful for diagnosing specific incidents, but most receivers do not send them and privacy concerns limit adoption. RUA is the baseline you keep on at all times.
Q: How often should I review aggregate reports after my domain reaches p=reject?
Weekly is a reasonable cadence for most organizations. Quarterly, re-run the sender inventory you built during the migration. The post-migration inventory is not the same as today's inventory.
Q: What does it mean if my rua=reports disappear after I move to p=reject?
Either the rua= destination mailbox is failing, or the receivers stopped honoring your rua= tag. Check the destination first. An empty report mailbox is the most common cause and the easiest to miss.