DMARC glossary
What does the fo tag mean in DMARC? (fo=1 explained)
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The fo tag sets failure-reporting options — when receivers should generate a forensic report to your ruf= address. fo=0 (the default) reports only when both SPF and DKIM fail aligned; fo=1 reports when either fails. d and s trigger on DKIM or SPF failures specifically, combinable as fo=1:d:s.
fo at a glance | |
|---|---|
| Tag | fo (failure reporting options) |
| Valid values | 0 · 1 · d · s — combinable, colon-separated (e.g. fo=1:d:s) |
| Default | Defaults to 0 — report only when both SPF and DKIM fail to produce an aligned pass. |
| Where it goes | After the policy tags, e.g. v=DMARC1; p=quarantine; ruf=mailto:forensics@yourdomain.com; fo=1; |
How fo works
Forensic (failure) reports are per-message snapshots sent when something fails — unlike the daily aggregate summaries sent to rua= (see [what a RUF address is](/learning/what-is-a-ruf)). The fo tag tunes the trigger: 0 fires only on a full DMARC failure, 1 fires when either SPF or DKIM fails to align, d fires on a DKIM signature failure, and s fires on an SPF failure. fo=1 is the popular debugging choice because it surfaces partial failures — the early warnings.
Two things keep fo firmly in the 'minor tag' category. First, it only matters if you've set a ruf= address — without one, there's nowhere to send failure reports and the tag is inert. Second, most large receivers don't send forensic reports at all, regardless of fo, because per-message reports can leak personal data and message content. Gmail, for one, doesn't send them.
Practical stance: aggregate reports do the real rollout work. If you do run a ruf= mailbox, fo=1 extracts the most signal from the few receivers that participate — just don't build your process around a report stream that may never arrive.
Correct record vs common mistake
Correct
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1fo=1 paired with a ruf= address — reports on any partial failure, from the receivers that send them at all.
Common mistake
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; fo=1fo without a ruf= address does nothing — there's no destination for failure reports. Either add ruf= or drop the tag.
Generate your DMARC record
Build the exact TXT record to publish — pick a policy, add a reporting address, copy. Free, no signup.
Used to show the exact host name to publish — the record itself doesn't contain it.
Start at none to observe, then tighten once reports look clean.
Where daily XML summaries are sent. Comma-separate multiple addresses.
Advanced options (sp, alignment, pct, ruf)
Subdomains inherit p unless you set this. Attackers love unused subdomains — reject is a strong choice once you're at enforcement.
Relaxed allows subdomain matches (mail.yourdomain.com signs for yourdomain.com). Strict requires an exact match — most domains should stay relaxed.
Same idea for the SPF (Return-Path) domain.
Applies quarantine/reject to a percentage of failing mail during rollout. Retired in DMARCbis — use briefly if at all.
Per-message failure samples. Rarely sent by large providers; contains message data.
Your DMARC record
Publish this as a TXT record in your DNS.
_dmarc.yourdomain.com
v=DMARC1; p=none;
Record type: TXT · TTL: your provider's default (e.g. 3600) is fine.
After you publish
- Add the TXT record at your DNS host and allow up to an hour for propagation.
- Verify it with the free DMARC checker.
- Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.
Troubleshooting fo
| Issue | Likely cause | Fix |
|---|---|---|
| No failure reports despite fo=1 | Most receivers don't send forensic reports for privacy reasons — Gmail among them | Expected. Use aggregate (rua=) reports as the primary data source; treat any ruf mail as a bonus |
| fo tag present but ignored | No ruf= address in the record — fo has no destination to act on | Add ruf=mailto:<address> if you want failure reports, or remove fo |
| Failure-report mailbox flooded during rollout | fo=1 fires on every partial failure — a busy unaligned sender generates a report per message | Scope the debugging window, then tighten back to fo=0 or fix the unaligned sender causing the volume |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Forensic reports can contain message content and recipient addresses — real client data. Pointing 50–200 tenants' ruf= at a shared, casually-secured mailbox is a privacy incident waiting to be discovered. If you enable failure reporting at all, treat that mailbox like the sensitive data feed it is.
Trusted by MSPs
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
Enforce it — don't just monitor it
Palisade does its rollout work from aggregate reports — the reliable, privacy-safe stream every major receiver actually sends — so client domains reach enforcement without depending on forensic reports that may never arrive.
Free 15-day trial · No credit card · Your own domain free forever (NFR)