What does the DMARC fo tag mean?

What are the requirements?

RFC 9989, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)," is the controlling published RFC. It is a final RFC, not a draft. The fo option is optional, and it is a request to a report generator rather than a receiver enforcement rule.

The fo tag requires ruf

A domain owner must include ruf for fo to have an effect. RFC 9989 states that the fo tag's content "MUST be ignored" when ruf is absent.

v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=0

This is illustrative only. Use reporting addresses controlled by your organization. Do not copy example addresses into a production DMARC record.

The ruf tag provides one or more destinations for failure reports. The fo tag tells a report generator which failure condition the domain owner is requesting. Neither tag changes whether the message passes DMARC, and neither changes the policy requested by p, which in the example above is p=none.

fo=0 requests complete aligned-authentication failure

When fo is absent, its default value is 0. Under RFC 9989, fo=0 requests a failure report when all underlying authentication mechanisms fail to produce an aligned pass.

An SPF or DKIM check can pass without satisfying DMARC alignment. The relevant test is whether an evaluated mechanism produces an aligned pass for the RFC 5322 From domain. A receiver can still decline to send a failure report.

fo=1 requests any aligned-authentication failure

RFC 9989 defines fo=1 as a request for a failure report if any underlying authentication mechanism fails to produce an aligned pass.

v=DMARC1; p=none; ruf=mailto:dmarc-failures@yourdomain.com; fo=1

This request can produce more potential report events than fo=0, because one mechanism can meet the requested condition even if another mechanism produces an aligned pass. More requested reports do not prove stronger authentication, and they do not require a mailbox provider to send message-level data.

fo=d and fo=s request mechanism-specific reports

RFC 9989 defines fo=d as a request for a DKIM failure report when the message had a signature that failed evaluation, regardless of alignment. It defines fo=s as a request for an SPF failure report when SPF evaluation fails, regardless of alignment.

Multiple fo values use colon separation.

v=DMARC1; p=none; ruf=mailto:dmarc-failures@yourdomain.com; fo=0:d

This is illustrative only. The values request different report conditions. They do not modify the SPF record, repair a DKIM signature, or alter DMARC disposition. The separate DMARC rf tag controls the requested failure-report format.

Receivers retain discretion

The fo value is a request. RFC 9989 permits report generators to decide whether to honor the requested conditions. Privacy, abuse prevention, and local operating policy can affect whether a receiver generates or sends failure reports.

A missing failure report therefore does not prove that the DMARC record is invalid, that no message failed, or that a receiver ignored fo. Use aggregate reporting and delivered-message authentication results to investigate production sending behavior.

When does the requirement take effect?

RFC 9989 was published in May 2026 and is the current DMARC specification. It obsoleted RFC 7489, which had previously defined DMARC reporting behavior.

There is no mailbox-provider enforcement date for fo in RFC 9989. A receiver can evaluate the option after it obtains a valid DMARC record containing ruf, but the RFC leaves failure-report generation to the receiver's local policy. Treat fo as an optional diagnostic request, not as a compliance deadline or a guaranteed reporting channel.

How do I implement the requirement?

1. Decide whether failure reports answer a defined question

Start with the operational question that aggregate reports cannot answer. Message-specific failure reports may help investigate a narrow authentication incident, but they are not a replacement for aggregate DMARC data.

If your team does not have a controlled process for receiving and reviewing message-level data, do not add ruf and fo only because the tags are available. The DMARC ri tag concerns the requested aggregate-report interval, which is a separate reporting function.

2. Set up a controlled ruf destination

Use a mailbox or report processor with restricted access and a retention process appropriate for message-specific data. If ruf uses a reporting domain different from the policy domain, follow the external reporting authorization rules in RFC 9989 before expecting reports.

Failure reports can contain information about an individual message. Do not send them to a broadly shared mailbox or an unmanaged third-party address.

3. Choose the narrowest useful request

Leave fo absent when the default fo=0 request is sufficient, or publish fo=0 when you need the value to be explicit. Use fo=1, fo=d, or fo=s for a specific investigation with a defined review process.

Do not treat a broader report request as proof of authentication. The tag cannot correct an SPF authorization failure, restore a broken DKIM signature, or create DMARC alignment.

4. Publish one valid DMARC record

Publish one DMARC TXT record at _dmarc.yourdomain.com. Include ruf and fo in the same record as the DMARC version and policy.

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=0"

This DNS record is illustrative only. Query the authoritative DNS server and at least one public resolver after publication. Keep a change record so an operator can distinguish intended changes from DNS drift.

How do I validate compliance?

First, inspect the public record. Confirm that one valid DMARC record is published at _dmarc.yourdomain.com, that ruf is present, and that each fo value is one of the values defined by RFC 9989. A public lookup is DNS evidence only. It does not prove that a receiver will send failure reports.

Next, check the receiving system or report destination for accepted and processed reports. If you use an external destination, verify the required authorization record and the destination's handling controls.

Then test the exact production sending path. Send a controlled message and inspect its delivered headers to establish SPF, DKIM, alignment, and DMARC results. A green DNS result cannot prove that the application signed the message or used the expected return path.

Finally, use DMARC aggregate reports after data accumulates to identify sending sources and alignment outcomes. Failure reports are supplemental evidence because receivers may suppress them.

Check the DMARC record before relying on fo

Use the DMARC record checker to inspect the published ruf and fo values before changing a reporting request. Compare the DNS result with delivered-message headers and aggregate-report evidence.

Check the DMARC record

A public DNS check cannot prove that a receiver will send a failure report, show every production sender, or explain a receiver's private reporting decision. For ongoing work, Palisade is DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when evidence supports it, while a human reviews the evidence and applies the change.

Start with Palisade