DMARC FO Tag: A Guide to DMARC Failure Reporting Options

If you’re tightening email authentication, DMARC reporting is where the real insight lives. Most teams start with DMARC aggregate reports (high-level trends), then add failure reporting when they need message-level visibility. 

That’s where the DMARC fo=1 setting comes in. It helps surface partial authentication failures that can hide misconfigurations, alignment gaps, and early signs of spoofing. 

This guide explains what the FO tag does, how FO=1 works in practice, how it compares with other options, and when it makes sense for enterprise environments.

What Is the DMARC FO Tag?

The DMARC FO (Failure Options) tag is a tag in your DMARC record  that influences when a receiving mail server may generate forensic (failure) reports. FO helps define which DMARC authentication failure conditions should trigger a message-level report.

It’s important to separate FO from an aggregate report:

• Aggregate (RUA): Summary DMARC reports that show authentication and DMARC alignment results across large volumes of mail.
• Failure/forensic (RUF): Message-level forensic report data tied to specific failures or conditions.

FO is tied to failure reporting behavior (typically delivered via the address in ruf=), while aggregate summaries are delivered via rua=.

What FO=1 means in a DMARC policy

FO=1 requests failure reports when either the SPF authentication fails, or the DKIM authentication fails.

Even if the message still passes DMARC  because the other mechanism passes and aligns, FO=1 can still request a report. That added visibility helps you catch partial failures, like cases where your SPF record is correct but your DKIM signature breaks, or where DKIM passes but SPF alignment fails due to third-party senders.

How DMARC FO=1 Works in Practice

When a receiver evaluates a message, it checks SPF and DKIM, then checks identifier alignment to decide whether the authenticated identity aligns with the visible “From” domain (DMARC’s core requirement). Alignment is what turns “authentication happened” into “authentication is meaningful for this From domain.”

Here’s the simplified decision flow:

1. SPF check: The receiver evaluates whether the sending IP is authorized for the domain used in SPF, then evaluates alignment (whether that SPF domain aligns with the From domain configured for sending email addresses).
2. DKIM check: The receiver validates the DKIM record signature against the sending domain in the DKIM header, then evaluates dkim alignment (whether that DKIM domain aligns with the From domain).
3. DMARC check result: DMARC passes if either SPF-aligned pass or DKIM-aligned pass occurs. If both fail alignment, DMARC fails and the receiver applies your DMARC policy (p=).

How FO=1 triggers a report

With FO=1, a failure report may be generated when either SPF or DKIM fails, regardless of the final DMARC pass/fail outcome. This is useful when you’re trying to track down why some mail is intermittently failing one mechanism, even though legitimate email still lands.

What you can see in FO=1 failure reports

A failure report commonly includes message-level signals such as:

• Key message headers (enough to troubleshoot routing and identity)
• Authentication results (SPF/DKIM pass/fail and alignment outcomes)
• Sending infrastructure indicators like source IPs and domains

Because this is message-level data, it can contain sensitive information. Many enterprises treat failure reports as restricted telemetry: limit who can access them, define retention, and avoid forwarding raw reports broadly.

Also note that failure reporting support varies by mailbox provider. Even if you publish FO and ruf=, receivers may not send forensic reports in all cases.

DMARC Record Example with FO=1

Here’s a simple DMARC record example showing FO=1 in a DMARC TXT record (published as a DNS TXT record under _dmarc.yourdomain.com):

• fo=1 requests failure reporting when SPF or DKIM fails
• adkim=s and aspf=s tighten alignment (strict mode)
• rua= receives aggregate summaries; ruf= receives failure reports

If you’re validating records during rollout, a DMARC record checker  can confirm the syntax and whether a DMARC record found result appears for the domain.

DMARC FO=1 vs Other FO Tag Options

FO supports several values, and each changes your visibility and operational load:

FO=0

FO=0 requests failure reports primarily when DMARC fails (more “complete failure” oriented). This is the least noisy option and can be a practical default when you’re building a reporting baseline.

FO=d

FO=d narrows failure reporting to DKIM-related failures. It’s useful if your environment relies heavily on DKIM signing and you want tighter focus on DKIM breakage, affecting email deliverability and authentication.

FO=s

FO=s narrows failure reporting to SPF-related failures. It’s useful if SPF authorization and SPF-based workflows are the main source of authentication problems.

A simple way to choose which FO value to use us to consider your organization’s specific requirements:

• Choose FO=0 if you want lower volume and a cleaner starting point.
• Choose FO=1 if you want deeper insight into partial failures and are prepared to handle more data.
• Choose FO=d or FO=s if you’re isolating troubleshooting to one mechanism.

FO=1 can increase report volume and operational overhead. If you don’t have a process to triage and store these reports, you can end up with noise instead of insight.

Why DMARC FO=1 Matters for Enterprise Security

FO=1 is valuable because partial failures are where problems hide. A message can “pass DMARC” while still showing a weak point, like a broken DKIM signing path, a third-party sender causing alignment issues, or a gradual shift in infrastructure that breaks authentication for certain streams. FO=1 can help you:

• Find authentication and DMARC misconfigurations sooner (especially across many senders)
• Spot early indicators of brand impersonation or phishing attempts that threaten email security 
• Validate that your DMARC setup is working consistently across domains, infrastructure, and sending email addresses
• Reduce blind spots when only one mechanism is doing all the work

Risks and trade-offs to manage

The trade-offs of using FO=1 are mostly operational and governance-related:

• Data exposure: Failure reports can include sensitive content signals
• Compliance and handling: You need access controls, retention rules, and secure storage
• Volume: FO=1 can generate more reports than teams expect

For enterprise governance, treat failure reporting like security telemetry. Define who can view it, how long it’s retained, and how it’s used for investigations.

Enhancing DMARC Monitoring With FO=1

The DMARC FO tag helps refine DMARC reporting by controlling when failure reports are requested, and FO=1 is especially useful for surfacing partial authentication failures that can be easy to miss. 

For mid-to-large enterprise environments with many senders, FO=1 can strengthen monitoring by improving visibility into SPF/DKIM issues, alignment gaps, and early abuse signals.

If you’re considering FO=1, treat it as part of a mature strategy: plan for report handling, privacy, and volume. And if managing reports across multiple domains and senders feels heavy, Mimecast DMARC Analyzer and DMARC record generator can help reduce complexity and turn reporting into actionable insight.