Why DMARC RUF failure reports are rarely sent.

RUA and RUF answer different questions

Aggregate RUA reports summarise source IPs, message counts and authentication outcomes over a reporting period. They do not normally contain a copy of each message. RUF failure reports concern an individual failed message or a group of similar failures and can include much more diagnostic detail.

• RUA: statistical evidence for identifying senders and alignment problems over time.
• RUF: message-level failure evidence, usually generated close to the failure when a receiver supports it.
• DMARC Analyst is designed for aggregate RUA reports only.

What a failure report may disclose

RFC 9991 warns that failure reports can include header fields or sometimes the entire content of a failed message. Redaction is available, but a domain owner cannot assume every reporter will expose the same fields or apply the same minimisation.

• Sender and recipient email addresses and other identifiers.
• Subject lines, routing and authentication headers.
• Source IP addresses and transmission metadata.
• Parts of the message body—or, in some formats, the complete message.
• Personal information, non-public business data or confidential communications.

Why receivers restrict failure reporting

• Privacy and data-protection risk when message-level information is sent to a domain owner or third-party report processor.
• Data leakage when a legitimate but misconfigured message contains confidential information.
• Content-injection abuse when an attacker deliberately places material into forged messages in the hope that a report will relay it.
• High volume and denial-of-service risk because a spoofing campaign can trigger reports for many individual failures.
• Limited additional value for routine monitoring when aggregate RUA reports already identify sources, volume and authentication results.

Support is limited and optional

The DMARC specification leaves failure-report generation to the receiving operator. Current Google Workspace documentation lists ruf as unsupported in Gmail. Current Microsoft 365 documentation states that it does not send DMARC forensic reports, even when a valid ruf address is published. Provider behaviour can change, so a monitoring design should never depend on RUF coverage.

Use RUA as the dependable monitoring path

Concentrate on a valid aggregate rua destination, correct external reporting authorisation and the reports that participating receivers send. Aggregate data usually provides enough evidence to inventory sending sources, find alignment failures and plan policy changes without collecting message content.

v=DMARC1; p=none; rua=mailto:your-reporting-address@example.net