Publishing a DMARC record is an important step, but it does not automatically give a domain owner visibility into their email.

That visibility depends on aggregate reports. Participating mail receivers can send these reports to the address listed in the DMARC record’s rua tag. They summarize where messages using the domain came from, how SPF and DKIM evaluated, whether those identities aligned with the visible From domain, and what disposition the receiver applied.

Without that feedback, a team may have a DMARC policy in DNS but still lack the evidence needed to understand its legitimate senders, spot authentication failures, or move toward enforcement with confidence.

That gap is not rare. Palisade’s State of DMARC 2026 study found that 20.5% of domains publishing a valid DMARC record had no usable aggregate-reporting address. That was 11,839 of 57,691 DMARC-publishing domains in the study.

What the 20.5% figure actually means

The study started with the top 100,000 domains in a pinned Tranco list and successfully observed 99,310 of them on August 13, 2026. Among those observed domains, 57,691 published a valid DMARC record. Of that DMARC-publishing group, 11,839 had no usable rua destination.

The denominator matters. This is not 20.5% of every domain on the internet, nor 20.5% of all domains in the original list. It is 20.5% of the domains in the study that published valid DMARC.

It is also a DNS measurement, not an incident report. The absence of rua does not prove a domain is under attack, that its email is unauthenticated, or that its security program is weak. It shows something narrower: the published policy does not request aggregate DMARC feedback at a usable address.

The reverse needs the same care. A working rua tag shows that reports have been requested. It does not prove the destination accepts every report, the processing pipeline is healthy, or anyone is acting on the results.

Why aggregate reporting matters

DMARC evaluates whether a message passes through aligned SPF or aligned DKIM. Alignment connects authentication to the domain a recipient sees in the From field.

The policy tells receivers what the domain owner wants them to do when that evaluation fails. A p=none policy expresses no handling preference, while p=quarantine or p=reject asks receivers to treat failures as suspicious or invalid. Receiver behavior can still vary.

The rua tag serves a different purpose. It tells participating receivers where to send aggregate feedback. A simple monitoring record might look like this:

_dmarc.example.com. IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;”

The reports are machine-readable summaries, normally delivered as compressed XML. They can reveal:

•  the source IP addresses sending mail that uses the domain;

•  message counts grouped by source and result;

•  SPF and DKIM authentication outcomes;

•  whether SPF or DKIM aligned with the From domain;

•  the policy the receiver found and the disposition it applied.

That makes the data useful for two jobs. First, it helps identify legitimate systems that are missing or misconfiguring authentication. Second, it surfaces unknown sources using the domain, which a team can investigate before deciding whether they are authorized, obsolete, or abusive.

Moving from monitoring to enforcement without that map creates avoidable risk. A forgotten billing platform, help desk, marketing tool, or regional sender may be legitimate but fail alignment. If the domain moves to enforcement before those streams are understood, some valid messages may be quarantined or rejected.

Four common ways reporting fails

1. The `rua` tag is missing

This is the clearest failure mode. A record can be valid and can even request enforcement without asking receivers for aggregate reports.

In the 2026 study, 4,980 domains were in that exact position: they published p=quarantine or p=reject but had no aggregate-reporting address. Enforcement may still protect the visible domain at participating receivers, but the domain owner loses an important source of operational feedback.

2. The report URI is malformed

The rua value is a list of reporting URIs. For email delivery, the conventional form begins with mailto:. Small errors can leave a value unusable even when the record looks plausible during a quick visual review.

For example, this is not a valid email reporting URI:

rua=dmarc-reports@example.com

It should be:

rua=mailto:dmarc-reports@example.com

Syntax is only the first check. The mailbox or processing service also needs to exist, accept the messages, and handle the report volume.

3. An external destination is not authorized

Many organizations send reports to a specialist service rather than to an address on their own domain. When the destination is outside the domain publishing DMARC, conforming receivers check that the external domain has authorized the relationship.

Suppose example.com publishes:

v=DMARC1; p=none; rua=mailto:reports@processor.example.net;

The operator of processor.example.net can authorize reports for example.com by publishing a TXT record at:

example.com._report._dmarc.processor.example.net. IN TXT “v=DMARC1;”

If that authorization cannot be confirmed, the receiver must ignore the external reporting destination. Reputable DMARC services usually handle this through their onboarding instructions or a wildcard authorization record, but the result should still be verified.

4. The destination exists but the pipeline is not monitored

DNS can be correct while the operational path is broken. Reports may reach a mailbox that is full, be rejected by filtering rules, sit as unread attachments, or enter a parser that stopped processing them.

This is why configuration and verification are separate steps. Seeing rua in DNS proves that a report was requested. It does not prove that reports from multiple receivers are arriving, parsing correctly, and reaching the people responsible for acting on them.

How to close the reporting gap

Step 1: Inspect the published record

Query the DMARC record directly rather than relying only on a screenshot or an old configuration document:

dig +short TXT _dmarc.example.com

Confirm that there is one valid DMARC policy record, that v=DMARC1 comes first, and that a usable rua URI is present. Also check that the destination is spelled correctly and still belongs to the organization or its chosen provider.

Step 2: Choose a destination that can handle reports

Aggregate reports can be numerous, compressed, and inconvenient to inspect by hand. A small domain can use a dedicated mailbox and a parser, while a larger organization may prefer a managed reporting platform.

Whichever approach is used, keep the reporting address separate from a person’s everyday inbox. Assign an owner, control access, define retention, and make sure a staff change does not quietly abandon the mailbox.

Step 3: Validate external authorization

If the rua address uses a different organizational domain, confirm the required authorization record on the destination side. Do not assume that copying a vendor-provided email address completes the setup.

Query the exact authorization name or use the provider’s validation workflow. If the provider uses wildcard authorization, confirm that it covers the destination domain in the published rua value.

Step 4: Confirm reports actually arrive

Allow multiple reporting cycles and look for reports from more than one participating receiver. Delivery is best-effort: not every receiver sends reports, schedules differ, and low-volume domains may have little data.

Check the full path:

1.  The receiver sends the report.

2.  The destination accepts it.

3.  The attachment is decompressed and parsed.

4.  The data appears in the monitoring view or workflow.

5.  Someone is responsible for investigating changes and failures.

An alert for a sudden drop to zero reports can be as useful as an alert for a new sending source. Silence may mean traffic changed, but it may also mean the pipeline broke.

Step 5: Review several cycles before changing policy

Build an inventory of known senders and validate that each legitimate stream passes DMARC through aligned SPF or DKIM. Pay attention to intermittent and low-volume systems such as invoicing, recruitment, support, survey, and event platforms.

After changes, watch more than a single day. Reporting is not perfectly complete or immediate, and some business systems send weekly or monthly. Enforcement decisions should reflect the organization’s mail patterns and risk tolerance rather than an arbitrary timer.

Limits and responsible handling

Aggregate reports are valuable, but they are not complete telemetry.

Receivers participate voluntarily, so a domain owner will not see every message sent across the internet. Reports can be delayed or absent. They describe what a reporting receiver observed and how authentication evaluated; they do not prove who operated a source or whether a specific message was malicious.

The data also deserves careful handling. Aggregate reports can expose sending IP addresses, domain relationships, traffic volumes, and authentication details. Limit access to people who need it, use appropriate retention, and review the privacy and security practices of any third-party processor.

Finally, DMARC itself has boundaries. It protects the use of a domain in the visible From field when receivers participate and the message fails aligned authentication. It does not stop lookalike domains, abuse from a compromised legitimate account, or every form of phishing.

The practical goal is not to collect reports for their own sake. It is to turn them into a reliable picture of the systems sending on behalf of the domain, fix authentication and alignment problems, and make policy changes with evidence rather than guesswork.

Author bio

Samuel Chenard is the CEO and co-founder of Palisade, where he works on agentic DMARC software and reproducible email-authentication research for IT teams and MSPs.