Why DMARC Forensic Reports Are Almost Never Deployed — ruf=, Privacy, and the pct= Gradual Rollout Strategy

The ruf= tag in a DMARC record requests forensic reports — full copies of failing messages sent back to a specified email address — and this is the DMARC feature that almost nobody enables because receiving a full copy of a failing message can mean receiving a copy of a phishing email, an email with PII, or confidential business correspondence

The previous articles on this site covered DMARC basics, moving from p=none to p=reject, reading DMARC XML reports, alignment failure, non-sending domain protection, and using aggregate reports to build a sender inventory. This article addresses DMARC forensic reports (ruf=) — what they contain, why they're rarely used in practice, the privacy and legal implications, and what the alternatives are for diagnosing specific failures.

DMARC's two report types: rua= vs ruf=

DMARC specifies two reporting mechanisms:

rua= (Aggregate reports): XML files containing statistical summaries of DMARC outcomes — how many messages were sent from each IP, which passed/failed SPF and DKIM, and what disposition was applied. No message content. Reports typically arrive daily. Widely deployed and the primary tool for DMARC monitoring.

ruf= (Forensic reports, also called "failure reports"): full (or partial) copies of individual messages that failed DMARC, sent to the specified address. Contains message headers, body (potentially), and failure reason. Enables pinpointing specific sending systems that are failing authentication.

The difference in what they reveal: an rua= report tells you "1,247 messages from IP 203.0.113.42 failed DMARC last week." An ruf= report shows you one of those actual failing messages — including the From address, Subject, body text, and headers.

Why ruf= is rarely deployed in practice

Three practical reasons forensic reports are almost never used:

Privacy concerns: if a legitimate sender fails DMARC (for example, a forwarded email from a mailing list), the forensic report contains the original message — possibly confidential business email, personally identifiable information, or other sensitive content. Receiving this in a forensic report and processing it creates data protection obligations under GDPR, CCPA, and other privacy frameworks.

Volume: for any domain with meaningful email traffic, forensic reports can arrive at enormous volume — one report per failing message. A domain receiving 10,000 messages/day with a 5% DMARC failure rate would generate 500 forensic reports per day. Processing this volume requires automation.

Major providers don't send them: Gmail/Google, Microsoft (Outlook.com), and Yahoo! do not send ruf= forensic reports, even when requested. They cite privacy concerns and operational overhead. Since these providers handle the majority of consumer email, ruf= reports are rarely available from the most important receiving domains.

The practical result: most DMARC implementations omit the ruf= tag entirely and rely solely on rua= aggregate reports for monitoring.

DMARC failure report options: fo= tag

The fo= (Failure Reporting Options) tag controls which failures trigger forensic reports when ruf= is configured:

fo=0 (default): send a report only when all authentication mechanisms (both SPF and DKIM) fail to produce an aligned pass. The strictest filter — only generates a report when there's a complete authentication failure.

fo=1: send a report when any authentication mechanism fails to produce an aligned pass — even if the other mechanism passes. Generates more reports; useful for diagnosing partial failures.

fo=d: send a report only for DKIM failures (regardless of SPF outcome).

fo=s: send a report only for SPF failures (regardless of DKIM outcome).

Multiple values: fo=1:d:s combines options. fo=0 is the most conservative (fewest reports, lowest privacy exposure); fo=1 is the most diagnostic (most reports, higher privacy exposure).

DMARC percentage tag: pct= for gradual rollout

The pct= tag (percentage) allows applying the DMARC policy to only a fraction of messages — enabling gradual rollout without immediately affecting all traffic:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

This record applies the quarantine policy to only 10% of messages that fail DMARC alignment. The remaining 90% are treated as if the policy were p=none — still reported but not quarantined.

The rollout strategy:

1. Start at p=none; pct=100 — report all, reject none
2. After establishing authorized sender inventory and fixing misconfigurations: p=quarantine; pct=10
3. Gradually increase: pct=25, pct=50, pct=100
4. Move to p=reject; pct=10, then gradually to p=reject; pct=100

The pct= limitation: not all receiving mail servers honour the pct= tag. Google and Microsoft respect it; some others apply the full policy regardless. This means pct= is a useful gradual rollout tool but not a reliable safety net — the full policy may be applied by some receivers even at pct=10.

External report destinations: third-party reporting services

DMARC aggregate reports can be sent to third-party services (Postmark's DMARC reports, DMARC Analyzer, Valimail, dmarcian) rather than a self-managed inbox:

The DNS verification requirement: if your DMARC rua= tag points to an address outside your domain (e.g., rua=mailto:[email protected]), the third-party domain must publish a DNS record authorizing your domain to send reports there:

example.com._report._dmarc.dmarc-analyzer.com TXT "v=DMARC1"

This requirement prevents DMARC reports from being used as a spam delivery mechanism (a malicious domain can't configure rua= to flood an external inbox without the external domain's explicit authorization).

The value of third-party services: they parse, aggregate, and visualize rua= XML into dashboards showing unauthorized senders, legitimate but misconfigured systems, and policy effectiveness trends — far more actionable than processing raw XML manually.

How to use the DMARC Lookup on sadiqbd.com

1. Verify rua= is configured correctly: the tool shows the complete parsed DMARC record — confirm rua= points to a monitored address that actually processes the reports, not an abandoned inbox
2. Check pct= during rollout: verify the percentage setting matches your intended rollout phase; a pct=10 record that was meant to be updated to pct=100 months ago is a common configuration lag
3. Identify subdomain policy (sp=): the tool shows the sp= tag if present — subdomains without explicit sp= inherit the main domain's policy, which may be unintentional

Frequently Asked Questions

If I set p=reject and discover a legitimate sending system is failing DMARC, can I quickly roll back to p=none? Yes — but TTL determines how quickly the rollback takes effect. Changing your DMARC record from p=reject to p=none takes effect at DNS TTL expiry (typically 5-30 minutes if TTL is set low). Receivers that cached the p=reject record won't see the change until their cache expires. This is why low TTL (300-600 seconds) on your DMARC record is important during rollout — it enables rapid rollback if problems are discovered. Once you're fully stable at p=reject with high confidence, you can raise the TTL for better DNS performance, knowing you're less likely to need emergency rollback.

Is the DMARC Lookup free? Yes — completely free, no sign-up required.

Try the DMARC Lookup free at sadiqbd.com — check any domain's DMARC record, policy, and reporting configuration.