What does DMARC fo tag 0 1 d s mean in email authentication?

You’ve set up DMARC, configured your SPF and DKIM, and now you’re staring at a report that says “alignment failed” — but the failure reports don’t make sense. Why? Because you missed the fo tag.

It’s easy to overlook, but the DMARC fo tag controls how receiving servers format failure reports when your email fails alignment checks. It’s not about enforcing policy — it’s about making sure the reports you get are actually useful, not misleading or overwhelming.

Understanding the fo tag — specifically the options 0, 1, d, and s — prevents misconfigurations that trigger false positives or bury real issues in noise. This matters because a single incorrect setting can turn your DMARC monitoring from a security tool into a distraction.

Key takeaways

  • The fo tag defines the structure of DMARC failure reports sent to your domain's reporting address.
  • Setting fo=1 includes both SPF and DKIM failure details; fo=0 only reports if one mechanism fails.
  • Using fo=d or fo=s controls whether reports include domain-level or subdomain-level failure context.

What are the valid DMARC fo tag values: 0, 1, d, s?

The fo tag in DMARC specifies the conditions under which aggregate or forensic reports are generated. Valid values are 0, 1, d, or s. fo=0 triggers reports only when both SPF and DKIM fail; fo=1 generates reports when either fails; fo=d is for DKIM-only failures; fo=s is for SPF-only failures. These settings help you fine-tune visibility into authentication breakdowns without overwhelming your reporting system.

Understanding DMARC's fo tag options

Each option adjusts how strictly reports are generated. The choice depends on your monitoring goals and the complexity of your email ecosystem. Let’s break down what each setting actually means in practice.

fo value Condition for report generation When to use it
0 Only when both SPF and DKIM alignment fail. Use when you want minimal noise and only care about complete authentication breakdowns. Common in strict policy environments where a full failure is a red flag.
1 When either SPF or DKIM alignment fails — regardless of the other. Best for monitoring overall alignment health. This is the most commonly used setting because it reveals partial failures that could indicate misconfigurations.
d Only when DKIM alignment fails. Use when you have strong SPF implementation but rely heavily on DKIM. Helps isolate DKIM-specific issues.
s Only when SPF alignment fails. Use when SPF is your primary alignment mechanism, and you’re troubleshooting SPF-specific problems like incorrect sender domains or relaxed mechanisms.

These values are defined in the DMARC specification (RFC 7483), which you can review at tools.ietf.org/html/rfc7483. The choice impacts how much data you receive from receivers that honor DMARC reporting.

Let’s say you’re running a campaign and seeing inconsistent inbox placement. Using fo=1 helps you catch the root cause faster — whether it's a misaligned SPF or a broken DKIM signature.

If you're validating email addresses before sending, you can use MailTester’s bulk verification to identify bad or misconfigured addresses early. It checks for syntax, domain existence, and some basic alignment indicators — though not full DMARC enforcement. For deeper inbox placement testing, try our inbox tester to simulate real-world deliverability.

Why does DMARC fo tag 0 matter for deliverability?

Setting DMARC’s fo=0 means you only receive forensic reports when both SPF and DKIM fail—making it easy to miss alignment issues, misconfigurations, or subtle spoofing attempts. This reduces report volume but also limits visibility, which can hurt long-term deliverability health, especially if your email environment changes.

What you lose with fo=0: visibility into partial failures

When fo=0, you get no reports if only SPF or DKIM fails. That means a sender might pass SPF but fail DKIM alignment, or vice versa, and you’d never know. That’s a blind spot: even if your authentication is mostly working, alignment failures can still lead to inbox placement drops or spam filtering, especially on strict platforms.

Without reports for partial failures, you’re less likely to catch misconfigured senders, third-party tools, or phishing attempts that exploit weak authentication. A real-world example: a newsletter platform using your domain with poor DKIM setup might slip through undetected, undermining your sender reputation.

When is fo=0 still useful?

It’s primarily valuable in low-volume environments where report saturation is a concern. If your organization sends only a handful of emails per day and you already have strong infrastructure oversight, a reduced report volume may be less impactful.

But even then, monitoring alignment—especially across multiple authentication methods—is critical. You’re trading off diagnostic detail for simplicity. If you later scale up, you’ll likely need to adjust fo to 1 to gain those insights.

Let’s be clear: ignoring alignment issues isn’t a sustainable strategy. The DMARC spec (RFC 7483) explicitly recommends using fo=1 (or fo=2) for better security visibility. This aligns with industry standards, including those from major email providers like Google and Microsoft, whose filtering systems rely heavily on alignment.

Use cases like automated mailing systems, shared platforms, or third-party tools make alignment issues common. Without fo=1, detecting these problems becomes guesswork. That means more hard bounces, lower inbox placement, and reputation damage over time.

If you’re managing large email lists, regularly testing delivery, or relying on external vendors, verifying your domain’s authentication setup is essential. Tools like MailTester’s inbox placement tester or bulk verification can help ensure your sending practices align with real inbox behavior.

When should you use DMARC fo tag 1 instead of 0?

You should use fo=1 when you want detailed reporting on failed authentication—specifically, when either SPF or DKIM fails, even if the other passes. This gives you full visibility into where email alignment breaks, making it easier to catch misconfigurations in your sending stack. Most organizations with strict DMARC policies (quarantine or reject) default to fo=1 because it surfaces issues early, before they impact deliverability.

How fo=1 helps you catch problems early

When you set fo=0, you only get reports if both SPF and DKIM fail. But in real-world setups, one can pass while the other fails—often due to misaligned headers, forwarded messages, or third-party tools. fo=1 ensures you’re notified in those cases, which is critical if you’re validating sender compliance across internal teams or partners.

For example, if your marketing platform is signing with DKIM but your email headers aren’t properly aligned, SPF may pass while DKIM fails. With fo=1, you’ll get a report. With fo=0, you won’t—until the email is blocked. That delay can mean missed campaigns or deliverability blackouts.

Why most strict DMARC policies use fo=1

Organizations that enforce DMARC with a p=quarantine or p=reject policy often adopt fo=1 by default. This approach maximizes visibility, which is essential as you scale sender sources, onboard new vendors, or manage complex email workflows.

The DMARC specification (RFC 7483) allows fo=1 to be the standard for thorough enforcement. It’s widely supported by email receivers and reporting tools, including tools like MxToolbox and Spamhaus, which provide insights into DMARC compliance trends across domains. The goal isn’t just compliance—it’s to understand where your infrastructure breaks so you can fix it before it hits the inbox.

Let’s be real: relying solely on fo=0 hides a large portion of your email failure surface. If you’re serious about deliverability and sender reputation, you want to see every failure—not just the worst ones. That’s why fo=1 is the baseline recommendation for organizations using DMARC seriously.

Use fo=1 to test your sending stack before going live. Tools like MailTester’s inbox placement tester can simulate real-world delivery and report how your messages perform under different DMARC settings—giving you confidence in your configuration before you send.

How do fo=d and fo=s help in diagnosing authentication issues?

When DMARC fails, the fo=d option pinpoints DKIM signature misalignments by testing if the DKIM-signed domain matches the From domain. The fo=s option isolates SPF failures by verifying whether the sending IP aligns with the SPF record. Together, they help you quickly identify whether the issue lies with DKIM, SPF, or both — especially critical in environments with multiple senders or forwarded messages.

fo=d: Tracking DKIM alignment problems

If you see fo=d in a DMARC report, it means the DKIM signature did not align with the From domain. This usually happens when a message is signed with a domain that doesn’t match the display From address — common when using third-party email services or forwarders.

For example, a newsletter sent via a transactional platform might authenticate with mail.example.com, but the From address says [email protected]. If DKIM only validates the former, DMARC flags it as a fo=d failure. This lets you adjust your signing domain or update your DKIM settings to match the From domain.

This level of granularity is essential when debugging issues across different email tools or in email pipelines involving multiple relays. A tool like Inbox Placement Testing can help simulate real-world delivery scenarios and confirm whether your alignment is set up correctly.

fo=s: Debugging SPF alignment failures

When fo=s appears, the failure is tied to SPF checks — typically because the sending IP isn't listed in the SPF record of the domain in the MAIL FROM (envelope From). This can happen if a message is sent from a partner server not included in your SPF record, or if your SPF is misconfigured.

For instance, if you use a marketing platform and its IP isn't in your SPF record, SPF will fail. The fo=s tag confirms the issue is SPF-specific, not DKIM. You can then update your SPF record to include trusted IPs or consider using a relaxed SPF policy if your sender base is complex.

Many organizations use multiple senders — internal teams, CRMs, and third-party tools — making it hard to keep SPF and DKIM consistent. Tools that verify domains and detect misalignments in real time, like the Email Verification API, help ensure your sender base remains aligned across all authentication methods.

The DMARC fo tag is a diagnostic tool, not a policy — it tells you what failed, not how to fix it. Use it to isolate issues before adjusting your policies.

Using fo=d and fo=s effectively requires reviewing DMARC reports from providers like Spamhaus or MxToolbox — both of which provide reliable DMARC analysis and historical data. For ongoing verification, consider regular list hygiene using bulk verification to catch alignment issues before they impact deliverability.

How does DMARC fo tag influence sender reputation and inbox placement?

DMARC’s fo tag controls how detailed failure reports are generated when email alignment fails. Setting fo=0 disables reporting for misaligned messages, which means you won’t see alerts when spoofed or compromised accounts send mail using your domain. This lack of visibility delays detection of abuse, weakens your domain’s reputation over time, and increases the risk of inbox placement issues. Using fo=1 or granular values gives you accurate, actionable reports that help maintain sender reputation and protect inbox delivery.

Why skipping DMARC failure reports harms your sender reputation

When you set fo=0, your domain stops receiving detailed reports for messages that fail SPF or DKIM alignment. That means if an attacker uses your domain to send spam or phishing emails, you won’t know—unless someone manually checks spam filters or reporting services.

Without these reports, you can’t detect compromised accounts or misconfigured third parties early. Over time, repeated abuse with no detection reflects poorly on your domain’s trustworthiness. ISPs and email providers track this behavior; a history of abuse—even if you didn’t send it—can result in higher rejection rates and reduced inbox placement.

How granular fo tags improve visibility and reputation health

Setting fo=1 enables failure reports for all messages that fail alignment. This gives you a clear picture of every alignment breakdown, whether from a real email or a spoofed one. You can then block or fix the source before reputation damage compounds.

For even more precision, fo=2 or fo=3 allow reporting based on which specific alignment (SPF or DKIM) fails. If you’re using multiple authentication methods, this helps isolate issues to the correct mechanism—especially useful when third-party vendors manage parts of your sending flow.

According to RFC 7483, DMARC’s reporting framework relies on accurate feedback to be effective. Skipping fo tags undermines that foundation and reduces the overall value of the protocol. You’re essentially turning off a key diagnostic tool for your domain’s security and deliverability.

Proper DMARC configuration isn’t just about blocking spoofing—it's about enabling visibility. When you catch misalignment early, you maintain stronger sender reputation and better inbox placement. Tools like MailTester’s inbox placement tester help simulate real-world delivery conditions, so you can validate that your DMARC policies are working as intended.

Let’s say you’re using a third-party CRM or marketing tool. Without fo=1, you might not know if it’s sending unauthenticated messages. With it, you get alerts and can act before your domain gets flagged. This level of oversight is critical for reputation-based systems used by Gmail, Outlook, and other major providers.

How can you test DMARC fo tag settings in practice?

You can test DMARC fo tag settings by sending sample messages with intentionally misaligned SPF or DKIM signatures through a platform that lets you inject custom headers, then checking the DMARC aggregate reports (RUA) to see if the reported failures match your chosen fo value. Let’s walk through how.

Set up a controlled test environment

  1. Use a trusted email testing platform—like Mail-Tester or a sandboxed SendGrid account—that lets you add custom headers. This lets you simulate real-world message flows while controlling alignment conditions.
  2. Send a test message with a forged From: header, intentionally mismatching the domain in SPF (e.g., sender domain doesn't align) or DKIM (e.g., domain doesn’t match the signature’s selector). This triggers DMARC evaluation.
  3. Ensure your DMARC record includes a RUA tag pointing to a valid email address you control. Most public platforms won’t send reports unless you have a real RUA destination.

Analyze your DMARC reports

  1. Wait 24–48 hours. Aggregate reports (RUA) are typically sent daily and contain details on alignment failures, including which authentication method failed and the fo value applied.
  2. Check the report’s fo field in the orgpolicy section. If you set fo=1, only failures in SPF or DKIM should appear. If fo=1 or fo=2, report failures for either SPF or DKIM, or both.
  3. Confirm that DMARC correctly flagged the test misalignment. Adjust fo values iteratively—e.g., test fo=0 to suppress reporting (useful in debug mode), then fo=1 or fo=2 for broader monitoring.

You can use MailTester’s inbox placement tester to validate delivery and alignment when sending to real domains, though it doesn’t generate DMARC reports. For bulk list verification, use bulk verification to test real recipient domains in a controlled way.

Understand the impact of fo values

DMARC standards define how fo values affect reporting. Setting fo=0 disables report generation for misalignment, which is useful during testing but not for monitoring. fo=1 reports failures when either SPF or DKIM fail. fo=2 reports only when both fail—less common, but avoids noise in mixed environments.

According to RFC 7483, the fo tag allows domain owners to control when DMARC reports are generated, balancing detection clarity with report volume.

You should use fo=1 for the best visibility into alignment failures across both SPF and DKIM. It’s the default in RFC 7489 and widely adopted by enterprise mail systems because it balances detailed reporting with manageable volume—making it the safest, most practical choice for most domains.

Why fo=1 is the default recommendation

When you set fo=1, you receive forensic reports for any authentication failure where either SPF or DKIM fails to align with the From domain. This visibility helps you identify misconfigurations, third-party sender issues, and potential spoofing attempts early. The RFC 7489 standard explicitly endorses this setting for broad deployment, which is why it’s used by major email providers like Google and Microsoft.

While fo=0 only reports when both SPF and DKIM fail (a much narrower view), and fo=2 reports on any failure regardless of alignment, fo=1 gives the most actionable insight without overwhelming you with noise. For example, if your newsletter uses a third-party service that passes SPF but fails DKIM alignment (a common issue), fo=1 flags it. You can then adjust the setup before reputation is damaged.

What you gain—and what to watch

The key benefit of fo=1 is its balance. You get detailed failure data to troubleshoot sender issues, but not so much that reports become impractical to manage. Most email systems that accept DMARC records are already built to handle this level of reporting volume.

That said, don’t assume every failure is malicious. Legitimate email can fail alignment due to forwarding, header rewriting, or improper sender configuration. Use your DMARC reports—via a tool like MailTester’s inbox placement tester—to filter out false positives and refine your setup.

If you're validating your infrastructure or auditing your senders, you can also use MailTester’s real-time verification API to check if your domains are aligning correctly before deploying to large lists. It’s an effective way to catch issues early—especially with role accounts or catch-all inboxes that could otherwise pass alignment checks but still cause deliverability drops.

For organizations already using DMARC, reviewing the RFC 7489 specification gives a definitive look at its design intent. The standard’s adoption across major email providers confirms that fo=1 remains not just recommended—but proven.

How does MailTester help verify DMARC alignment and sender health?

You can verify DMARC alignment and sender health by checking whether an email address is valid, deliverable, and properly aligned with your domain’s authentication records. MailTester’s API and bulk verification tools detect invalid, role-based, or catch-all addresses that may trigger DMARC failures or harm sender reputation. Inbox placement tests also identify alignment issues before you send.

Real-time detection of misaligned sender patterns

When you validate an address via our Email Verification API, it doesn’t just check if the address exists—it checks if the sender domain aligns with SPF and DKIM records. Misalignment can trigger DMARC rejection, even if the email appears legitimate. Our system flags mismatches in the “from” domain during delivery, helping you catch alignment flaws early.

Let’s say you’re sending from [email protected] but your SPF only allows mailserver.yourcompany.com, and DKIM uses a different selector. DMARC will fail unless all components align. Our checks surface these discrepancies before they impact deliverability. This is not just verification—it’s health diagnostics for your sender reputation.

Spotting risky patterns in bulk lists

High volumes of role-based addresses (like admin@, support@, info@) or addresses with disposable domains can signal that your list is low-quality. Such patterns are often overlooked in basic validation, but they degrade sender reputation and can trigger DMARC scrutiny.

MailTester’s bulk verification process scans for these red flags across entire lists. If over 10% of your list uses role-based addresses, that’s a known sign of weak hygiene—common in older or purchased lists. You get a clear breakdown of invalid, risky, or catch-all addresses so you can clean your list before sending.

You don’t need to guess if your sending infrastructure is aligned. Our inbox placement tests simulate real-world delivery across major providers. They confirm whether your messages pass DMARC checks, especially when forwarded or shared with third-party services like mailing platforms or CRM tools.

For example, if a user replies to your campaign from Gmail, does DMARC still pass for the original sender? Our tests catch when alignment breaks in forwarded or nested delivery paths. You can fix issues before they cause blocks or complaints.

Start with 100 free verifications at MailTester’s pricing page, or integrate real-time validation through the Email Verification API. Use bulk verification to clean large lists, or run inbox placement tests to validate deliverability. You can also add MailTester to platforms like HubSpot, SendGrid, and Klaviyo via our integrations.

For the technical details, refer to the official DMARC specification (RFC 7001) to understand how alignment policies (p=none, p=quarantine, p=reject) enforce sender compliance.

How to maintain a strong DMARC policy with the right fo tag?

Begin with p=none and fo=1 to gather alignment and delivery data without disrupting email flow. This allows you to identify sources of misalignment before enforcing stricter policies.

Once alignment is stable across your sending domains, gradually move to p=quarantine, then p=reject after verifying no legitimate mail is blocked. Monitor RUF reports closely to confirm that all misaligned messages are being captured based on your chosen fo value.

Use fo=1 during data collection to ensure all messages failing alignment are reported. This visibility enables accurate tuning and prevents blind spots in your email security posture.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if I set fo=0 on my DMARC record?

Only alignment failures in both SPF and DKIM trigger reports. Many issues may go undetected, reducing visibility into sender problems.

Can I use fo=d and fo=s together?

No — fo tag accepts only one value. Use fo=1 if you want comprehensive failure reporting.

Does a higher fo value reduce deliverability?

No — fo tag affects reporting only. Deliverability depends on alignment, not the fo setting itself.

Why do some tools say fo=1 is best practice?

Because it captures failures in either SPF or DKIM, allowing faster detection of misconfigured senders.

Can I change fo tag after publishing my DMARC record?

Yes — changes propagate within minutes to hours. Test with tools that simulate DMARC evaluation.

Does fo tag impact how spam filters treat my emails?

No — fo tag only affects report generation. It doesn't influence filter decisions or inbox placement.

What should I do if my DMARC reports are not arriving?

Check that the RUA email is correct and not blocked. Verify fo tag settings ensure the failure condition triggers reporting.

Can MailTester detect DMARC misconfigurations?

Yes — our inbox placement and deliverability tests identify alignment issues by simulating email delivery.

Is fo=1 required by DMARC policy standards?

No — but it is the recommended default in RFC 7489 and widely used by major mailbox providers.

Why do some domains use fo=0 even with strict DMARC?

They may prioritize low report volume but risk missing alignment issues, especially with complex senders.

How does role-based email affect DMARC fo reporting?

Role addresses (e.g. admin@, sales@) can trigger false alignment failures if not properly authenticated. Verify them with MailTester.

Does a DMARC fo=1 record stop spoofing attacks?

No — only the 'p' policy (quarantine or reject) stops attacks. fo tag only improves failure visibility.