What does the DMARC fo tag mean?

The DMARC fo tag requests when a receiver should generate a message-specific failure report for an address listed in ruf. The default, fo=0, requests a report when all underlying authentication mechanisms fail to produce an aligned pass. fo=1 requests a report when any mechanism fails to produce an aligned pass, while d and s request DKIM-specific or SPF-specific failure reports. Receivers may decline to send these reports, and fo is ignored when ruf is absent.

Quick takeaways

• fo affects failure reports, not aggregate reports.
• The tag is ignored if the DMARC record has no ruf destination.
• fo=0 is the default and focuses on complete aligned-authentication failure.
• fo=1 can request more reports because one failed mechanism is enough.
• Receivers decide whether to honor failure-report requests, so ruf volume is never guaranteed.

Who is affected?

The tag matters to domain owners who deliberately collect DMARC failure reports and to processors that handle their sensitive message-level content. Most domains can operate DMARC monitoring with aggregate reports alone.

MSPs should pay particular attention to privacy, mailbox security, retention, and authorization before adding ruf. See the DMARC overview for the policy and alignment context.

What are the requirements?

RFC 9989 defines four fo values. 0 requests a report when all underlying mechanisms fail to produce an aligned pass. 1 requests a report when any underlying mechanism fails to produce an aligned pass. d requests a DKIM-specific failure report for a failed signature regardless of alignment. s requests an SPF-specific failure report for SPF evaluation failure regardless of alignment.

Multiple values are separated by colons, such as fo=0:d. The tag does not name a destination. The ruf tag supplies the authorized URI, and the fo content must be ignored if ruf is not present.

These are requests, not delivery promises. A receiver can choose not to generate failure reports because of privacy, abuse, or local policy. DMARC's reporting model distinguishes these message-specific reports from aggregate reports sent to rua, which remain the dependable foundation for source-level monitoring.

When does the requirement take effect?

The receiver evaluates fo when processing a valid DMARC policy record that also contains ruf. RFC 9989 is the current DMARC protocol reference. Existing deployments should recheck older assumptions because the current standard explicitly describes receiver discretion and the ruf dependency.

Changing fo does not change the domain's DMARC policy and does not make authentication pass or fail.

How do I implement the requirement?

1. Decide whether failure reports are necessary

Write down the diagnostic question that aggregate data cannot answer. If no one will securely review message-level reports, omit ruf and fo.

2. Secure and authorize the destination

Use a controlled mailbox or processor with appropriate access, retention, and incident handling. Complete external-destination authorization when the report address uses another domain.

3. Choose the narrowest useful value

Start with the default behavior unless a specific DKIM or SPF investigation justifies another value. More requested reports can create more sensitive data without improving a routine rollout.

4. Publish one valid DMARC record

Place ruf and fo in the same record as the policy and other reporting tags. Keep exactly one DMARC policy record at the owner name.

How do I validate compliance?

Query the public record and confirm that fo uses only supported colon-separated values and that ruf is present. Validate authorization for an external report destination. Then confirm that the processor can receive and protect reports, while accepting that some receivers will send none.

Use the DNS lookup tool to inspect the published record and Email Security Score to review the wider public configuration. Use aggregate data, not expected ruf volume, to judge source coverage.