DMARC fo Tag: Failure Reporting Options Explained

Q: Should I use fo=0 or fo=1?

Use fo=1 while diagnosing a new setup because it asks for reports when any underlying authentication method fails to align. Use fo=0 when you want fewer reports. If you omit the tag, fo=0 is the default.

Q: Why am I not receiving DMARC failure reports?

First check that your record has both ruf and fo . Then check whether the reporting address is valid and authorized if it is on another domain. After that, the likely answer is receiver policy. DMARC lets receivers choose whether to send failure reports, and many send few or none.

Q: Does fo affect whether Gmail or Outlook sends my mail to spam?

No. The fo tag only requests failure reports. Inbox placement depends on authentication, alignment, reputation, recipient behavior, content, blocklists, DNS, and provider policy. Fix SPF, DKIM, and DMARC alignment before moving from p=none to enforcement.

InboxRadar grades your email deliverability free and emails you when it changes. Check your domain.

The fo tag controls failure reports

A bad fo setting can flood a reporting mailbox with private message samples. A missing ruf tag makes it do nothing at all.

The fo tag is a DMARC failure reporting option. It tells mail receivers when you want message-level failure reports sent to the address in your ruf tag. A record might look like this:

v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1

The key rule is simple: fo does not work by itself. RFC 9989, the current DMARC protocol spec, says receivers must ignore fo when ruf is not present. The older RFC 7489 text said the same before it was replaced. Even with ruf, failure reports are optional in practice. Many large receivers send few or none because these reports can include message headers and sometimes message content.

Use fo for short-term debugging. Use rua aggregate reports for daily monitoring. Aggregate reports are safer, more common, and better for finding every service that sends mail for your domain.

What each fo value means

The valid values are 0, 1, d, and s. You can combine values with colons, such as fo=1:d, but 0 and 1 are mutually exclusive.

fo=0: request a DMARC failure report when all underlying authentication methods fail to produce an aligned pass. This is the default if you omit fo.
fo=1: request a DMARC failure report when any underlying authentication method fails to produce an aligned pass. This is noisier and useful during setup.
fo=d: request a DKIM-specific failure report when a DKIM signature fails evaluation, regardless of alignment.
fo=s: request an SPF-specific failure report when SPF fails evaluation, regardless of alignment.

Most teams should start with fo=1 only while fixing a new DMARC rollout. It can show cases where DKIM passes but SPF fails, or SPF passes but DKIM is broken. After the domain is stable, remove ruf and fo, or send them to a reporting vendor that can handle private data, rate limits, and noise.

Use fo=0 when you want fewer message-level reports. Use fo=d when you are debugging DKIM selectors, key rotation, or signing changes. Use fo=s when you are debugging a new sender, an SPF include, or a forwarding path.

fo does not change delivery policy

fo asks for reports. It does not tell Gmail, Outlook, or any other receiver to accept, quarantine, reject, or inbox a message.

DMARC policy comes from p=none, p=quarantine, or p=reject. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. Relaxed alignment is the default. Strict alignment requires an exact domain match.

That means a message can pass DMARC while still generating a report under fo=1, because one authentication method failed while the other passed and aligned. That report can be useful during setup, but it is not a spam-folder signal by itself.

Check the basics before adding fo

Failure reports help only when the normal authentication record is clean enough to read.

SPF: publish one SPF TXT record for each sending domain. Include every service that sends mail for that domain. RFC 7208 limits SPF evaluation to 10 DNS-querying terms, including include, a, mx, ptr, exists, and redirect. Exceeding the limit returns a permanent error.
SPF policy: use ~all while testing. Move to -all only when all valid senders are covered. RFC 9989 warns that some receivers can reject on SPF hard fail before DMARC runs, so those messages may never appear in DMARC aggregate reports.
DKIM: enable signing in each mail platform. Publish the public key at the selector your provider gives you, such as selector1._domainkey.example.com. During key rotation, keep the old selector long enough for queued or forwarded mail that may still need it.
DMARC: publish one TXT record at _dmarc.example.com. Start with p=none and a rua address. Move to p=quarantine, then p=reject, after your real senders pass SPF or DKIM with alignment.
DNS and reputation: make sure sending IPs have valid forward and reverse DNS. Check blocklists for sending IPs and domains. Authentication helps receivers trust the source, but spam complaints, bad lists, poor engagement, misleading content, and blocklists can still send mail to spam.

Google requires SPF or DKIM for all senders to Gmail accounts, and SPF, DKIM, and DMARC for bulk senders. Microsoft also documents SPF, DKIM, and DMARC alignment for Microsoft 365 and has published stricter requirements for high-volume Outlook.com, Hotmail, and Live.com senders. Treat those provider pages as the source when exact thresholds or enforcement details matter.

If you want a fast read on your live DNS before touching enforcement, run a free InboxRadar domain check. It grades SPF, DKIM, DMARC, MX, and blocklist signals, then shows which record to fix first.

A safe setup path

The safest DMARC rollout is boring: watch first, fix each sender, then enforce.

Start with v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com. This collects aggregate reports without asking for message-level samples.
Add ruf=mailto:dmarc-fail@example.com; fo=1 only when you have a clear debugging reason and a controlled mailbox or vendor ready for private data.
Read reports by source. Find normal mail first: Google Workspace, Microsoft 365, your CRM, support desk, billing system, marketing tool, and product mail.
Fix SPF or DKIM alignment for each source. DMARC needs one aligned pass, but both passing is easier to operate.
Move to p=quarantine after reports are clean. Watch for missed senders. Move to p=reject when remaining failures are spoofing, retired systems, or mail you are willing to block.

Keep one DMARC record. Multiple DMARC records can cause receivers to treat the domain as misconfigured. Keep report addresses monitored, restrict access, and document who owns each sending service.

Official references

Use primary sources when the exact rule matters.

RFC 9989 is the current DMARC protocol spec. RFC 9991 covers DMARC failure reports. Older tools may still point to RFC 7489, which RFC 9989 and RFC 9991 replaced.
RFC 7208 defines SPF, including the 10 DNS lookup limit.
RFC 6376 defines DKIM signatures and selectors.
Google sender guidelines explain Gmail authentication, DNS, spam-rate, and bulk-sender requirements.
Microsoft DMARC guidance explains SPF and DKIM alignment for Microsoft 365 domains. Microsoft's Outlook sender requirements cover high-volume consumer-mail rules.

For broader setup work, see the related InboxRadar guides.

Common questions

Should I use fo=0 or fo=1?

Use fo=1 while diagnosing a new setup because it asks for reports when any underlying authentication method fails to align. Use fo=0 when you want fewer reports. If you omit the tag, fo=0 is the default.

Why am I not receiving DMARC failure reports?

First check that your record has both ruf and fo. Then check whether the reporting address is valid and authorized if it is on another domain. After that, the likely answer is receiver policy. DMARC lets receivers choose whether to send failure reports, and many send few or none.

Can fo reports contain private data?

Yes. Failure reports can include message headers and sometimes message content. Send them to a controlled mailbox or a reporting service, restrict access, and avoid using them as your main monitoring feed. Aggregate rua reports are safer for daily operations.

Does fo affect whether Gmail or Outlook sends my mail to spam?

No. The fo tag only requests failure reports. Inbox placement depends on authentication, alignment, reputation, recipient behavior, content, blocklists, DNS, and provider policy. Fix SPF, DKIM, and DMARC alignment before moving from p=none to enforcement.