Understanding DMARC Aggregate and Failure Reports

DMARC reports provide evidence about how participating receiving systems evaluated messages associated with a domain. They are most useful when combined with a verified sender inventory and samples from the organisation’s own mail systems.

There are two report types:

• aggregate feedback, requested with the rua tag; and
• message-specific failure reports, requested with the ruf tag.

The formats and receiver behaviour are described in RFC 9990 and RFC 9991. The current DMARC protocol is RFC 9989.

Aggregate reports

An aggregate report summarises authentication observations over a reporting period. It is usually machine-readable XML, delivered to an authorised destination listed in rua.

A report can include:

• the reporting organisation and report identifier;
• the time range covered;
• the domain and published DMARC policy observed;
• source IP addresses and message counts;
• DMARC disposition results;
• SPF and DKIM alignment outcomes; and
• authentication results for relevant domains.

It generally does not contain the message subject or body. Even so, source addresses, domain names, and operational patterns can be sensitive and should be handled under an appropriate access and retention policy.

Illustrative XML shape

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>12</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.co.za</header_from>
  </identifiers>
</record>

The address and count are illustrative. A single row should not be treated as a person, campaign, or confirmed sending service without other evidence.

Failure reports

Failure reports can provide message-specific information when a receiver detects a DMARC failure and chooses to generate a report. A domain requests them with ruf, but support and redaction vary by receiver.

Because a failure report can contain message or header details, it can carry greater privacy and data-handling risk than aggregate feedback. Do not assume it will be available, complete, or suitable for unrestricted storage.

An empty ruf mailbox does not mean that there are no failures. Many investigations should start with aggregate reports and controlled message samples.

Report destination authorisation

If the report address uses a different organisational domain from the domain publishing DMARC, the destination domain can be required to authorise the reporting relationship through DNS. This protects an unrelated domain from being made the target of unwanted report traffic.

Before relying on an external destination:

1. confirm the exact mailto: address;
2. complete the required external-destination authorisation;
3. ensure the mailbox or ingestion service accepts the report format and volume;
4. validate the public DNS result; and
5. define access, retention, and deletion responsibilities.

Reading a report without jumping to conclusions

Start with the policy domain and date range

Confirm that the report applies to the expected domain and period. A report can reflect a policy observed before a recent DNS change.

Group by authentication pattern

Useful initial groups include:

• aligned DKIM pass;
• aligned SPF pass;
• both aligned mechanisms passing;
• authentication passing without DMARC alignment; and
• neither aligned mechanism passing.

DMARC passes when at least one supported mechanism both authenticates and aligns. A message does not need aligned SPF and aligned DKIM at the same time.

Map sources to known services

Reverse DNS, network ownership, and provider ranges can help generate a hypothesis, but they do not prove which business system sent the mail. Confirm the source with provider configuration, return-path data, DKIM signing domains, and internal service owners.

Examine the volume in context

Counts are observations from one receiver for one period. They are not a complete measure of all mail sent, all recipients reached, or all fraud attempted.

A low-volume source can still be business-critical. A high-volume source can be unauthorised, misaligned, or the result of receiver aggregation. Prioritise using business ownership and risk, not volume alone.

Distinguish policy request from receiver action

The policy-evaluated fields describe the receiver’s DMARC processing, including local-policy overrides where reported. DMARC policy is a request by the domain owner; a receiver can make a different final delivery decision.

Common patterns

SPF passes but DMARC fails

The SPF-authenticated envelope domain may not align with the visible From domain. Ask whether the provider supports a custom aligned return path, and check whether aligned DKIM is available.

DKIM passes but DMARC fails

The signature’s d= domain may not align with the visible From domain. A provider can validly sign with its own domain without satisfying DMARC for the customer’s From domain.

Both SPF and DKIM fail after forwarding

Forwarding commonly changes the connecting IP, which can break SPF. Message modification can also invalidate DKIM. ARC information may help a receiver apply local policy, but it does not convert the reported DMARC result into a pass.

A familiar provider appears from an unexpected range

Confirm the tenant and sending path. Shared infrastructure, a new supported range, or an unauthorised use are different cases and require different responses.

The record requests enforcement but disposition is none

Check whether the report shows a local-policy reason, a different effective policy, or a historical policy snapshot. Receiver discretion remains relevant.

Turning reports into changes

A practical review loop is:

1. ingest and validate the report;
2. group observations by source and authentication pattern;
3. map each potential legitimate source to a service owner;
4. confirm SPF, DKIM, and alignment using provider configuration and samples;
5. create a controlled remediation or removal task;
6. validate after the change using DNS, samples, and later reports; and
7. record exceptions and unresolved sources before any policy progression.

Reports support decisions; they do not make the decision automatically. Avoid blocking a source merely because its IP is unfamiliar, and avoid authorising it merely because it sends a large volume.

Limitations to document

• Not every receiver sends every report type.
• Reporting schedules, grouping, and fields can vary within the standard’s rules.
• Reports cover the receiver’s observations, not the entire mail ecosystem.
• Source attribution requires evidence beyond an IP address.
• DNS and policy changes may appear in later reporting periods.
• Failure reports can be unavailable or redacted.
• Authentication success does not establish that a message is wanted or safe.

Frequently asked questions

How soon should reports arrive?

Allow for DNS publication, actual mail reaching participating receivers, and their reporting cycles. There is no universal arrival guarantee.

Can a report identify an individual sender?

An aggregate report normally groups technical observations. It should not be used to identify a person without appropriate, independent evidence and governance.

Does count equal messages sent by the source?

It is the reporting receiver’s aggregate count for that record and period. It is not necessarily the source’s complete sending total.

Should every failure be blocked before moving policy?

No. Investigate whether it is authorised, misconfigured, forwarded, or unauthorised. The policy decision should be based on domain-specific evidence and delivery risk.

Next step

If a domain has a valid DMARC reporting address but no data is arriving, work through why DMARC reports may be empty. For help reviewing public records and planning the next investigation, contact Vigil.