DMARC Failure Reports (RUF): What They Are, How They Work, and How to Enable Them Securely

Publishing a DMARC record is an important step toward protecting your domain from spoofing, phishing, and unauthorized email use. However, the real operational value comes from the reports that show whether legitimate senders are passing email authentication and where failures are occurring.

Many enterprise teams rely on DMARC aggregate reports to monitor overall domain health, but those summaries may not provide enough detail for incident response, compliance investigations, or complex third-party sender troubleshooting. DMARC failure reports (RUF) add message-level context that can help security and IT teams identify the source of authentication failures faster. 

This guide explains what RUF reports are, how they differ from aggregate data, and how to use them effectively.

What Is a DMARC Failure Report?

A DMARC failure report (also called a failure report or RUF report) is a detailed, near-real-time notification sent by receiving email servers when a message fails DMARC authentication. It provides message-level diagnostics, including authentication results, sending source, and message headers, so that domain owners can investigate potential spoofing attempts and troubleshoot email authentication issues.

Terminology note: The terms “DMARC failure report,” “DMARC failure report,” and “RUF report” all refer to the same report type. The underlying format is AFRF (Authentication Failure Reporting Format), defined in RFC 6591, which is a DMARC-specific extension of ARF (Abuse Reporting Format, RFC 5965). These terms are often used interchangeably in the industry.

• Who generates it? Receiving mail servers, ISPs, corporate mail gateways, and security appliances, but only when they support RUF and detect an authentication failure. Domain owners request reports via the ruf= tag, though receivers decide whether to send them based on their own privacy policies and configuration.
• Where does it go? It is delivered to the email address specified in the ruf= tag of your DMARC DNS record.
• What format does it use? Unlike aggregate reports, which are delivered as XML files, RUF reports use AFRF, the Authentication Failure Reporting Format, to provide detailed authentication failure data in a more human-readable structure.

What Information Is Included in DMARC Failure Reports?

Because RUF DMARC reports are designed for deep-dive troubleshooting, they contain specific metadata about the failed message that you will not find in aggregate reports. A typical RUF report includes:

• Sender IP address: the exact IP that attempted to send the message
• From and Return-Path addresses: the Header From and the envelope sender
• Subject line: the actual subject of the failed email
• Authentication results: specific details on why SPF or DKIM failed and whether DMARC alignment was achieved
• Mail headers: the full feedback headers of the message
• Received time: the timestamp when the message arrived at the receiving server
• Applied DMARC policy: the policy that was applied to the message, whether none, quarantine, or reject
• Delivery result: whether the message was delivered, quarantined, or rejected
• Personally identifiable information (PII): because these reports can include subject lines and recipient addresses, they often contain PII

Note on Privacy

Due to the inclusion of PII, many major mailbox providers have opted out of sending RUF reports to protect user privacy. PowerDMARC addresses this by supporting PGP encryption for RUF reports, so sensitive data stays encrypted and accessible only to you. Some receivers that do send RUF reports redact sensitive parts of the body or subject line first, which is why some failure reports arrive empty or contain [REDACTED] strings.

DMARC Failure Report Example: How to Read Each Field

To understand what is happening under the hood, review the raw data. When an email fails, the receiver generates a report in AFRF format. The following is a representative example using reserved domains and IP ranges per RFC 5737.

Field-by-field interpretation

Practical Tip

When reviewing a RUF report, work four questions in order. Is the Source-IP in your approved sender list? Did SPF or DKIM fail, or both? Is the Original-Mail-From aligned with your domain? Does this look like a forwarding edge case or a mailing list relay? If you cannot answer these confidently, route the report to your security team for investigation.

What the record looks like in your DNS

To receive these reports, your DMARC record must include the ruf= tag. A representative example:

If you are sending reports to a domain different from your own, the destination domain must publish a DNS record authorizing it to receive reports on your behalf. Breaking down the tags:

• v=DMARC1: the standard version tag identifying the DMARC protocol
• p=none: monitoring mode; messages are not rejected or quarantined, and receivers are asked to report authentication results
• rua=: the destination for daily aggregate reports summarizing all authentication activity
• ruf=: the destination for failure reports; route this to a secure, dedicated processing platform rather than a general inbox
• fo=1: instructs receivers to generate a report if either SPF or DKIM fails

DMARC Aggregate Report vs Failure Report: RUA vs RUF

Both report types are configured within the same DMARC record, but they serve distinct purposes. RUA provides domain-wide visibility over time; RUF provides message-level detail for specific failures. For a deeper split, see this comparison of RUA vs RUF reports.

How to Enable DMARC Failure Reports in Your DNS Record

Enabling RUF requires updating your existing DMARC TXT record in DNS. Follow these steps.

1. Access your DNS provider. Log in to the DNS management console for your domain.
2. Locate your DMARC TXT record. Find the TXT record published at _dmarc.yourdomain.com.
3. Add the RUF destination. Insert a ruf=mailto: address where supported failure reports should be sent.
4. Configure failure options. Add the fo= tag to define when reports should be generated, covered in the next section.
5. Use secure processing. Route reports to a secure platform such as PowerDMARC rather than a general-purpose inbox.
6. Save and allow propagation. DNS changes can take up to 48 hours to propagate globally.

Sending RUF reports to a standard inbox creates noise and increases data exposure risk. A reporting platform centralizes DMARC data, translates raw authentication data into readable dashboards, and correlates failures with SPF, DKIM, and DMARC alignment results so teams can identify issues faster.

DMARC fo Tag Explained: When Failure Reports Are Triggered

The fo tag is a component of the DMARC record that instructs the receiving server when to generate a failure report.

Most security professionals use fo=1 because it provides maximum visibility into authentication failures. That said, fo=1 should be routed to a dedicated, secure processing platform rather than a human inbox. The volume of reports it generates can become unmanageable without automation, and sending them to an unprotected inbox increases exposure of sensitive message data. A DKIM failure in particular can produce a burst of reports worth isolating from a shared mailbox.

Why You Might Not Be Receiving DMARC Failure Reports

If you have enabled RUF but your reporting destination is empty, this does not necessarily indicate a configuration error. Several common factors can result in no reports being received.

This is why aggregate RUA reports are considered the authoritative source for overall domain health monitoring, while RUF reports serve as a supplemental investigative tool for specific failure scenarios.

Privacy and Security Concerns

Because RUF reports can contain subject lines, recipient addresses, headers, and sometimes message content, they must be handled carefully under privacy frameworks such as GDPR and CCPA. For organizations in regulated sectors such as finance, healthcare, education, retail, and government, failure data should be processed through secure, access-controlled systems that support privacy and compliance obligations.

For organizations working toward Google, Microsoft, PCI DSS, GDPR, or government email authentication requirements, secure reporting workflows matter. RUF data can support investigations, but aggregate DMARC visibility, enforcement progress, and authenticated sender management remain essential for long-term compliance readiness.

Best practices

• Use a dedicated, secure reporting platform.
• Enable PGP encryption: a bring-your-own-key model means only authorized users with the private key can view sensitive failure report contents.
• Limit access to failure data based on role and operational need.
• Define data retention policies for stored RUF data in accordance with applicable privacy regulations.
• Conduct a legal review before enabling RUF in jurisdictions with strict data protection requirements.

How to Use RUF Reports to Detect Spoofing and Fix Failures

Once you begin receiving failure data, treat each report as an investigative signal rather than a definitive verdict. Validate findings against approved sender inventories, DMARC aggregate trends, mail gateway logs, and threat intelligence before making remediation decisions. Five scenarios cover most of what failure data surfaces.

Detecting domain spoofing

If a failure report identifies an unrecognized source IP using your domain in the Header From address, treat it as an investigative signal. Validate the source against approved sender inventories, aggregate trends, gateway logs, and threat intelligence first. If confirmed as unauthorized, the IP can be added to blocklists and your security operations center can be notified.

Fixing legitimate failures

Sometimes legitimate email fails because a third-party sender is not aligned correctly, a DKIM selector is misconfigured, or the domain’s SPF record has become too complex. A reporting platform helps teams identify these failures in context and simplify SPF management with hosted SPF and automated flattening, reducing the risk of delivery issues as new SaaS tools are added.

Diagnosing forwarding-related failures

Email forwarding commonly breaks SPF because the forwarding server’s IP is not listed in the original sender’s SPF record. If a RUF report shows failures from a recognized forwarding service or mailing list relay, the cause is likely SPF breakage rather than a spoofing attempt. In these cases, check whether DKIM is still passing, since DKIM signatures typically survive forwarding, and whether the DMARC policy can be satisfied through DKIM alignment alone.

Discovering shadow IT and unauthorized senders

RUF reports can reveal sending sources that IT teams did not authorize or are unaware of, such as a marketing team that connected a new automation tool without updating the SPF record. If a failure report shows a failure from an IP belonging to a recently adopted SaaS platform, this is a configuration gap rather than an attack. Add the service to your authorized sender inventory and update your DMARC record accordingly.

Investigation workflow

1. Identify the source IP in the RUF report.
2. Verify authorization: is this IP associated with a tool or service your organization uses?
3. Inspect alignment: review SPF and DKIM results in the Authentication-Results field.
4. Check for forwarding or mailing-list behavior: assess whether SPF failure comes from an intermediate relay.
5. Classify risk: authorized sender with misconfiguration, unauthorized sender, forwarding artifact, or shadow IT source.
6. Remediate: if authorized but failing, fix the SPF or DKIM alignment. If unauthorized, use your DMARC policy at p=quarantine or p=reject to enforce protection.
7. Monitor via aggregate reports: confirm the remediation is effective by reviewing subsequent RUA reports.

When RUF Is Worth Enabling, and When to Skip It

RUF is not a default-on setting for every domain. Whether it earns its place depends on who will read the reports and what they are for. Three situations make it worthwhile, and two argue against it.

• Enable it when you have a security team to act on the data. SOC analysts and incident responders use the message-level detail to investigate confirmed spoofing, which is the report’s strongest use.
• Enable it during active troubleshooting. When a third-party sender keeps failing and aggregate data is not specific enough, failure detail on the exact IP and alignment result shortens the diagnosis.
• Enable it in regulated environments with secure processing already in place. If you already run encrypted, access-controlled reporting, the added investigative depth carries little marginal risk.
• Reconsider it if reports would land in a shared inbox. Without encryption and access controls, receiving PII-bearing reports creates compliance exposure that outweighs the benefit.
• Reconsider it if nobody owns the output. A high fo=1 volume with no analyst to triage it becomes noise, and the aggregate reports already cover domain-health monitoring.

The honest default for most teams is aggregate-first. Run RUA for domain health and enforcement progress, then switch RUF on deliberately when an investigation or a stubborn sender failure calls for message-level depth, routed to a platform built to handle the sensitivity.

Limitations of DMARC Failure Reports

Understanding what RUF reports cannot do is as important as knowing what they can. Position failure reports as a supplemental investigative tool rather than the primary signal for DMARC program decisions.

• Limited provider support: major mailbox providers including Gmail and Microsoft 365 generally do not send RUF reports due to privacy concerns, so failure coverage is inherently incomplete
• Redacted data: receivers that do send reports may redact subject lines, message bodies, or recipient addresses before delivery
• False positives from forwarding: mailing list relays and forwarding services frequently cause SPF failures that look like authentication failures but are not spoofing attempts
• Report volume and noise: with fo=1, high-volume senders may receive an unmanageable number of reports, many reflecting expected forwarding behavior rather than genuine threats
• Not a replacement for RUA: aggregate reports remain the authoritative source for domain-wide authentication health, so RUF should complement rather than replace ongoing RUA monitoring
• PII exposure risk: without encryption and access controls, the act of receiving RUF reports can itself create compliance obligations under GDPR, CCPA, and similar frameworks

How MSPs Can Use DMARC Failure Reports Across Client Domains

For MSPs and MSSPs, failure reports are valuable when a client reports missing messages, suspected spoofing, or unexplained authentication failures. Raw RUF reports are difficult to manage at scale, though. They may contain sensitive client data, arrive from multiple domains at once, and require correlation with other authentication signals to be actionable.

• Multi-domain visibility: aggregating reports across dozens or hundreds of client domains without a centralized platform takes significant manual effort
• Sensitive data handling: RUF reports from client domains may contain end-customer PII, creating compliance obligations for the MSP
• Report volume management: high-volume client domains can generate large numbers of failure reports that overwhelm technician workflows
• Role-based access: technicians should only see reports for their assigned client domains

A centralized platform like PowerDMARC for MSPs and MSSPs helps service providers process RUF data securely, separate client domains, reduce manual investigation time, and give technicians fast visibility into which sender, IP address, or authentication mechanism caused a failure, without exposing sensitive data unnecessarily.

How PowerDMARC Helps with DMARC Failure Reports

PowerDMARC processes DMARC failure data securely and turns raw authentication failures into actionable insight. Instead of sending sensitive RUF reports to a standard inbox, teams view reports in a centralized dashboard, protect sensitive data with PGP encryption, and correlate failures with SPF, DKIM, and DMARC alignment results.

• Clear visibility: identify failed sending sources, authentication results, and suspicious IPs faster across all your domains
• Secure handling: PGP encryption with a bring-your-own-key model reduces exposure of sensitive failure data, so even PowerDMARC cannot read the encrypted contents
• Centralized management: monitor DMARC, SPF, DKIM, BIMI, MTA-STS, and TLS-RPT from one platform without switching tools or parsing raw XML
• Faster remediation: troubleshoot legitimate sender failures and spoofing attempts without manually parsing AFRF reports, with hosted SPF and automated flattening to reduce delivery failures as new SaaS tools are added
• Compliance readiness: audit trails, role-based access controls, and support for Google, Microsoft, PCI DSS, GDPR, and government sender requirements

Frequently Asked Questions

What exactly is a DMARC failure report?

A near-real-time failure report generated when an individual email fails the authentication checks defined by your DMARC policy and failure options. It carries message-level detail, unlike aggregate reports, which summarize activity across all messages over 24 hours.

How is RUF different from RUA?

RUA gives a daily domain-wide summary in XML covering all messages. RUF is near-real-time for individual failing messages in AFRF format (RFC 6591, extending ARF in RFC 5965), contains message-specific detail, and may include PII. RUA does not.

How do I turn these reports on?

Add ruf=mailto:[email protected] to your DMARC TXT record at _dmarc.yourdomain.com. Include fo=1 to receive a report when either SPF or DKIM fails. Route reports to a secure platform rather than a standard inbox.

I set up RUF but I am not getting anything. Is it broken?

Not necessarily. Many providers do not send RUF for privacy reasons, and no report is generated when messages pass. If aggregate RUA reports are arriving, your record is likely correct. Check the troubleshooting table for other causes.

Do all mailbox providers send DMARC failure reports?

No. Gmail and Microsoft 365 generally do not, citing user privacy. Coverage is limited to receivers that implemented RUF support, typically some corporate mail gateways, ISPs, and independent mail servers. This is a key limitation.

Are DMARC failure reports safe to receive?

They may contain PII such as subject lines, recipient addresses, and headers. Receiving them without controls can create GDPR and CCPA obligations. They are safest routed to a secure platform with PGP encryption, role-based access, and defined retention.

What does the fo tag do?

It stands for Failure Options and defines when receivers generate a report. fo=0 (default) requires both SPF and DKIM to fail. fo=1 sends on either failure. fo=d triggers on DKIM failure only; fo=s on SPF failure only.

• About
• Latest Posts

Milena Baghdasaryan

Content Specialist at PowerDMARC

Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.

Latest posts by Milena Baghdasaryan (see all)

• DMARC Failure Reports (RUF): What They Are, How They Work, and How to Enable Them Securely - August 11, 2026
• Email Authentication at the World’s Biggest AI Companies - August 10, 2026
• Top 5 Business Email Compromise (BEC) Tools in 2026 - July 31, 2026