A DMARC record can ask for two kinds of reports. The first, requested with the rua tag, is the aggregate report: a daily summary from each receiver of how many messages claimed your domain, where they came from and whether they passed. Almost every DMARC guide tells you to publish it, and you should. The second, requested with the ruf tag, is the failure report, often called a forensic report. It describes individual messages that failed DMARC, and may include the headers, and in some cases parts of the body. It sounds like exactly what you need to debug a failing sender, and in a lab it would be. In practice, few large mailbox providers send them, those that do send little, and the content raises privacy questions that many organisations decide they do not want to carry. This guide explains what ruf reports are, how to request them, what the fo options do, why you may receive nothing, what the legal and privacy issues are and a sensible way to decide whether to ask for them.
Aggregate versus failure reports
| rua (aggregate) | ruf (failure or forensic) | |
|---|---|---|
| Granularity | Counts per source IP, result and domain, usually over 24 hours | One report per failing message, or per failure event |
| Content | XML with identifiers and results; no message bodies | A copy of headers, sometimes the body or parts of it, in a defined report format |
| Who sends it | Most large mailbox providers | Only a few receivers; many large ones do not |
| Volume | One file per receiver per day | Can be large during an attack or a misconfiguration |
| Privacy risk | Low; contains IP addresses and counts | Higher; may contain personal data in headers or content |
| Main use | Find all senders, see pass rates, plan enforcement | Investigate a specific failure or active abuse |
The aggregate report gives you a complete picture of who sends mail as your domain, which is why it is the right tool for deploying DMARC. See DMARC aggregate reports and moving to reject. The failure report adds detail about single messages. That detail is occasionally what you need, for example to see the exact headers of a message that failed alignment, but you can usually reach the same understanding by combining aggregate data, a test message you send yourself and the headers of a message a recipient forwards to you.
How to request ruf reports
You add the tag to the DMARC record, with one or more mailto: addresses, optionally with the fo tag that selects which failures count:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"If the report address is on a different domain from the one in the policy, the receiving domain must authorise it by publishing a TXT record at example.com._report._dmarc.reportdomain.com with the value v=DMARC1. Without it, compliant receivers will not send reports to that address. The same rule applies to rua. Many people use a DMARC reporting service, which supplies a ready-made address and takes care of the authorisation. If you use one, check how it stores and protects failure reports before you enable ruf.
The fo tag: what triggers a report
| fo value | Meaning |
|---|---|
0 (default) | Generate a report if all underlying checks failed (neither SPF nor DKIM produced an aligned pass) |
1 | Generate a report if any underlying check failed, even if DMARC passed |
d | Generate a report if a DKIM signature failed to verify |
s | Generate a report if SPF failed |
You can combine values with colons, for example fo=1:d:s. The broader the setting, the more reports you receive. fo=1 is the most informative and the noisiest, because it reports cases where DMARC passed and one mechanism failed, such as a forwarded message whose SPF failed but whose DKIM passed. The report format is defined in RFC 6591 (an extension of the Abuse Reporting Format), with the DMARC-specific fields described in RFC 7489. The rf tag, which names the report format, defaults to afrf and rarely needs to be set.
Why you may receive nothing
- Most large providers do not send them. The biggest mailbox providers have chosen not to send failure reports, mostly because of privacy and abuse concerns. You will see them only from a minority of receivers, often smaller or specialised ones.
- Authorisation is missing. If the report mailbox is on another domain and the authorisation record is absent, receivers skip it.
- Syntax errors. A wrong
mailto:format, missing semicolon or a space can invalidate the tag. Check with the SPF, DKIM and DMARC checker. - Few failures. If your authentication is healthy, there is little to report, apart from abuse of your domain.
- Policy. A receiver may send reports only for some domains or only when a policy is enforcing.
Because of this, a quiet ruf mailbox says very little about the health of your domain. Do not treat the absence of failure reports as evidence of no abuse. Use aggregate reports for that conclusion.
Privacy and legal considerations
A failure report can include the headers of a real message and sometimes the body, which means the personal data of senders and recipients: names, email addresses, subject lines and perhaps content. If the failing message was a spoof, the data may belong to a person who has nothing to do with you. If it was a legitimate message from one of your own senders, it may contain your customers' data. By asking receivers to send such copies to you, you become a recipient of that data and take on duties under data-protection law in places such as the European Union and the United Kingdom. The receivers have the same concern from their side, which is a large part of why many do not send the reports. This is not legal advice. Ask your data-protection adviser before you enable ruf, and consider these measures if you do.
- Send reports to a dedicated mailbox with restricted access, not to a shared inbox.
- Limit retention, for example by deleting reports after 30 days.
- Use a processor that you have vetted, with a data-processing agreement, if you outsource analysis.
- Do not forward raw reports in tickets or chat; share only the fields you need.
- Document the purpose (security monitoring and fixing authentication failures) and mention it in your privacy notice where appropriate.
- Treat the mailbox as a source of attacker-controlled content: reports can contain malicious links or attachments, so do not open them in a regular mail client.
A sensible approach
For most organisations the recommended setup is simple: publish rua to a mailbox or a reporting service you trust, read the reports, fix your senders and move to enforcement. Skip ruf unless you have a specific reason. Good reasons include an active spoofing campaign that you must investigate, a security team that can handle sensitive data and wants every available signal, or a regulated environment in which per-message evidence is required. If you enable it, do it deliberately, with the controls above, and review after a few weeks whether it ever produced a useful report. If it did not, switch it off.
Using the reports you receive
When a failure report arrives, check the following. The source IP address and the Reported-Domain tell you who sent the message and which domain it claimed. The authentication results show whether SPF, DKIM or both failed and why, for example a body-hash failure, which is covered in DKIM body hash did not verify. The headers show the path and the Return-Path, which you can compare with your SPF record and your sending services. Decide whether the message was a legitimate sender that needs fixing or abuse of your domain. Fix the former; for the latter, enforcement and monitoring are the answer, and the message may be worth reporting to the sending network. Read headers with the steps in how to read email headers.
See who is sending as your domain Authenticate every sender, publish DMARC reporting and move to enforcement with confidence.
References and further reading
Frequently asked questions
What is the DMARC ruf tag?
It requests failure (forensic) reports: per-message copies or details of messages that failed DMARC, sent to the addresses you list.
What is the difference between rua and ruf?
rua requests daily aggregate statistics and is widely sent. ruf requests reports on individual failing messages and is sent by few receivers.
Why am I not receiving DMARC ruf reports?
Most large providers do not send them. Missing authorisation for an external address, syntax errors or healthy authentication can also explain it.
Are DMARC forensic reports a privacy risk?
They can include headers and parts of message content, so they may hold personal data. Restrict access, limit retention and take advice before enabling them.
Do I need ruf to deploy DMARC?
No. Aggregate reports are enough for most deployments. Add ruf only for a specific investigation or security need.