Skip to content
Back to Blog
DMARC.WS Team··7 min read

What Are DMARC Failure Reports (RUF) and Should You Enable Them?

DMARCRUFReportsPrivacy

Two Types of DMARC Reports

DMARC defines two reporting mechanisms:

  • Aggregate reports (RUA): XML summaries sent daily with pass/fail statistics per source IP. These are the bread and butter of DMARC monitoring.
  • Failure reports (RUF): Individual message-level reports sent in near real-time when authentication fails. These provide forensic detail about specific failures.

Most organizations set up RUA immediately but skip RUF. This article explains what RUF reports contain, when they're useful, and the privacy implications you should consider.

What's in a RUF Report?

A RUF report is an email containing a redacted copy of the failed message, formatted as an RFC 5965 Abuse Reporting Format (ARF) message. It typically includes:

  • From address: The address in the failed message's From header
  • Subject line: The subject of the failed message
  • Authentication results: Which checks failed (SPF, DKIM, or both)
  • Source IP: The server that sent the message
  • Message headers: Full or partial headers of the original message
  • Arrival date: When the message was received

Some receivers include a redacted version of the message body, while others strip it entirely for privacy reasons.

RUF vs RUA: Key Differences

Aspect RUA (Aggregate) RUF (Failure)
Frequency Daily (usually) Per-message
Format XML ARF (email)
Detail level IP-level statistics Individual message
Volume One report per source per day One per failure
Privacy impact Low (statistics only) High (message content)
Provider support Broad Limited

When RUF Reports Are Useful

Diagnosing Intermittent Failures

Aggregate reports tell you "50 messages from IP 203.0.113.5 failed DKIM." But they don't tell you why. A RUF report for one of those messages shows you the actual DKIM signature, headers, and alignment details — making it much easier to pinpoint the issue.

Identifying Spoofing Attempts

When your domain is being actively spoofed, RUF reports show you the actual phishing messages being sent. You can see the subject lines attackers are using, the From addresses they're impersonating, and sometimes the content of the phishing attempt.

Debugging Third-Party Services

When a new email service fails authentication, the aggregate report tells you it failed. The failure report shows you the exact headers, including which DKIM selector was used, what SPF domain was checked, and whether alignment was the issue.

Privacy Considerations

RUF reports can contain personally identifiable information:

  • Email addresses (From, To, CC)
  • Subject lines (which may contain names, account numbers, etc.)
  • Message bodies (depending on the reporter)
  • Sending server hostnames and IPs

GDPR and Data Protection

If you operate in the EU or process EU residents' data, RUF reports raise GDPR considerations:

  • The data is transmitted via email (potentially unencrypted)
  • Message content may include personal data
  • You become a data processor for information you didn't explicitly request

Some organizations choose not to enable RUF for compliance reasons, or they use a dedicated DMARC reporting service that handles the privacy aspects.

Limited Provider Support

Many large mailbox providers — including Google — do not send RUF reports at all, citing privacy concerns. This means even if you request them, you'll only receive reports from a subset of receivers.

Providers that typically send RUF reports:

  • Microsoft (Office 365, Outlook.com)
  • Yahoo / AOL
  • Some smaller ISPs and enterprise gateways

How to Enable RUF Reports

Add the ruf tag to your DMARC record:

v=DMARC1; p=quarantine; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com

Additional Options

fo (Failure Options): Controls when failure reports are generated:

Value Meaning
fo=0 Generate report only if ALL checks fail (default)
fo=1 Generate report if ANY check fails
fo=d Generate report if DKIM fails (regardless of alignment)
fo=s Generate report if SPF fails (regardless of alignment)

You can combine options: fo=1:d:s

For debugging purposes, fo=1 is most useful — it captures partial failures that fo=0 would miss.

rf (Report Format): Almost always afrf (the default). No need to change this.

Handling RUF Report Volume

With fo=1 on a high-volume domain, you can receive thousands of RUF reports per day. Considerations:

  • Use a dedicated mailbox: Don't send RUF reports to a human inbox
  • Use a DMARC reporting service: Tools that parse and aggregate RUF reports are far more practical than reading individual emails
  • Consider fo=0 for high-volume domains: Only generates reports when both SPF and DKIM fail, significantly reducing volume

Our Recommendation

For most organizations, we recommend:

  1. Always enable RUA — aggregate reports are essential and low-risk
  2. Enable RUF during the monitoring phase (p=none) when you're actively debugging authentication issues
  3. Use fo=1 during debugging for maximum visibility
  4. Consider disabling RUF after enforcement once your authentication is stable and you have high pass rates
  5. Use a DMARC reporting tool to process RUF reports — don't try to read them manually

If you're in a privacy-sensitive industry or subject to strict data protection regulations, consult your compliance team before enabling RUF.

Summary

RUF reports provide message-level forensic detail that aggregate reports can't match. They're invaluable during the initial DMARC deployment and debugging phase. However, they carry privacy implications, have limited provider support, and can generate high volumes on busy domains.

Use them strategically — enable during monitoring, leverage for debugging, and consider your privacy obligations before making them permanent.