Last updated: July 2026

In short: The optional fo= (Failure Reporting Options) tag dictates the exact conditions under which receiving mail servers generate and dispatch a per-message failure report (ruf=). It provides four granular trigger options (0, 1, d, and s) for diagnosing authentication breaks.

When you configure Domain-based Message Authentication, Reporting, and Conformance (DMARC) to request forensic failure reports via the ruf= tag, the fo= parameter controls when those detailed reports are triggered.

Core rules and dependence on ruf=

The fo= tag operates exclusively alongside the ruf= tag. If fo= is omitted from your published DNS record, DMARC automatically defaults to option 0.

According to RFC 7489, the tag specification states: fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified.

A complete DMARC record utilizing explicit failure options looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

The four reporting triggers explained

Under RFC 7489, administrators can choose from four distinct options, or combine multiple triggers using colon separation (for example, fo=0:d):

Option 0 (default): all mechanisms fail

When set to 0 or omitted entirely, a failure report is generated only if both underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned pass: 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.

This option restricts forensic volume to complete authentication failures, but it hides partial misconfigurations where one protocol succeeds while the other fails.

When configured with 1, a failure report is triggered immediately if either SPF or DKIM fails to produce an aligned pass: 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.

Setting fo=1 is widely considered the gold standard during onboarding and active troubleshooting. It alerts security teams immediately if an edge-case system passes DKIM alignment but fails SPF alignment due to forwarding or improper Return-Path configuration.

Option d: DKIM evaluation failure

Option d triggers a report whenever a cryptographic DKIM signature fails technical evaluation, regardless of whether DMARC alignment passes or fails: d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.

This specific trigger helps administrators diagnose broken private keys, misconfigured selectors, or intermediate mail relays that corrupt message bodies during transit.

Option s: SPF evaluation failure

Option s triggers a report whenever the raw SPF check fails, independently of DMARC alignment: s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

Verifying your configuration

To verify that your fo= parameter is published cleanly in DNS, confirm your ruf= reporting syntax, and check for hidden formatting errors, scan your domain with the free MXAudit scanner.

To explore comprehensive authentication concepts and provider-specific setup guides across various platforms, visit the DMARC hub and practical guides like IONOS DMARC setup.

Further reading