The DMARC ‘fo’ tag options and their ideal use cases
There are some optional tags in DMARC, and ‘fo’ is one of them. It stands for ‘failure options.’ The ‘fo’ tag allows domain owners to specify the conditions under which forensic (RUF) reports should be generated for SPF and/or DKIM authentication checks. There are four possible values for this tag: fo=0, fo=1, fo=d, and fo=s. Forensic reports contain detailed and sensitive data, including email headers. Sometimes, these reports also include portions of the original message, jeopardizing the confidentiality of sensitive details.
You can combine the ‘fo’ tag options and create a more potent reporting strategy that best suits security standards and tolerance for risks emerging from false positives and negatives.
Possible values of the DMARC ‘fo’ tag
There are four values of the ‘fo’ tag that you can choose from-
fo=0
This is the default setting for failure reporting and is the most restrictive option. If you have specified ‘fo=0’ in your DMARC record, then failure reports will be generated if an email fails both SPF and DKIM authentication. With this setting, you receive a limited number of reports, which is an ideal case for organizations that don’t have enough people on their team to evaluate these reports regularly. You receive reports when authentication failures are more likely to indicate actual spoofing or phishing.
However, there is one drawback: Some phishing emails might go unnoticed if they pass one of the checks. Since forensic reports often contain sensitive email information, using fo=0 helps mitigate privacy risks while still allowing domain owners to monitor and analyze critical authentication failures.
fo=1
The fo=1 tag allows domain owners to specify that forensic reports should be generated if either SPF or DKIM fails, even if one of them passes. This is a more aggressive setting, and you also receive more reports, which means more visibility into email activities.
It is important to consider the fact that many mailbox providers don’t support forensic reporting due to GDPR and privacy regulations. That’s why you should not rely solely on fo=1 to get a deep dive into email insights. It’s suggested that you complement it with DMARC aggregate reports (RUA).
fo=d
This tag setting instructs mail servers to generate forensic reports only for emails that fail the DKIM authentication checks. This means that if an email does not have a valid DKIM signature, or if the DKIM-signed domain does not match the ‘From’ domain (failing alignment), a forensic report is triggered. Unlike fo=0, which requires both SPF and DKIM to fail, fo=d focuses specifically on DKIM-related failures, making it useful for organizations that prioritize DKIM authentication over SPF.
fo=s
If you apply this configuration, then forensic reports will only be generated for emails that didn’t pass the SPF authentication check, regardless of DKIM results. This setting is particularly useful for domain owners who rely heavily on SPF authentication and want detailed insights into misaligned SPF failures. However, since fo=s does not trigger forensic reports for DKIM failures, it may not capture cases where SPF passes but DKIM fails due to issues like broken signatures or header modifications.
Final words
It can be overwhelming to manage so many reports on a daily basis. Moreover, these reports are not only for storing the history of outgoing emails; you need to analyze them properly to see if you have to sort some misconfigurations or remove any obsolete sending sources. If you are seeking a helping hand in DMARCReport management, reach out to us.