Debug DMARC fo=1 with adkim=r

Why DMARC fo=1 reporting fails when adkim=r is set

You send transactional emails through a third-party provider. The DKIM signature validates. The SPF check passes. But DMARC reports show fo=1 failures — even though everything appears correct. Why?

Because adkim=r enforces strict alignment: the DKIM signature must be from the same domain as the From address. If your email is signed by a service like SendGrid or Mailgun, but the From domain is different, alignment breaks — regardless of technical validity. This triggers fo=1 reports, which degrade sender reputation over time.

Understanding how adkim=r interacts with forwarding, third-party services, and domain misalignment isn’t optional. It’s foundational to deliverability when DMARC is enforced.

Key takeaways

adkim=r requires the DKIM-signing domain to match the From domain for alignment to pass
DKIM signatures from third-party providers fail alignment if the signing domain differs from the From domain
fo=1 reporting increases when alignment fails, leading to reputational risk even with valid signatures

What does adkim=r mean in a DMARC record?

adkim=r means "relaxed" alignment for DKIM signatures in your DMARC policy. It allows a DKIM-signed email to pass alignment even if the signing domain (like mail.example.com) doesn’t exactly match the From domain (example.com), as long as the base domain matches. This helps reduce false fails when sending from subdomains, but it doesn’t override domain separation — an email from a third-party service using a different domain still fails alignment if adkim=r isn’t applied to both sides.

How relaxed alignment works in practice

Let's say you send mail from mail.example.com, and your DKIM signature covers that domain. If your From header is example.com and adkim=r is set, DMARC will accept the alignment. The system recognizes that mail.example.com is a subdomain of example.com and passes the check. This reduces bounces due to strict domain mismatch, especially common with marketing platforms or transactional email vendors.

But here's the catch: this relaxation only applies when both domains are under your control. If you're using a third-party sender (like a newsletter platform or CRM), and they send from their own domain, that domain must either sign the email with a DKIM record aligned to your From domain or be explicitly allowed in your DMARC policy. adkim=r doesn’t magically fix misaligned sending domains. If a message comes from [email protected] with From: example.com, and no DKIM record exists for thirdparty.com that aligns with example.com, alignment still fails.

You can verify DKIM and SPF alignment before sending using an inbox placement tester or a real-time email verification tool. This helps prevent DMARC failures caused by alignment issues long before they hit your deliverability. For instance, MailTester’s inbox placement tester simulates how messages land in real mailboxes and flags alignment mismatches early.

Why it matters for DMARC reporting

When you see fo=1 in DMARC reports — meaning a failure occurred due to From domain alignment — and you have adkim=r set, you're seeing a report that reflects a true misalignment: your From domain isn't covered by the DKIM signature, even with relaxed checks. This often happens with cross-domain signing, like when sending from a branded email platform (e.g., Mailchimp) but setting the From domain to your company’s root domain. The sender’s domain doesn’t align with yours, and while adkim=r helps in some cases, it doesn’t close that gap.

For troubleshooting, check your DKIM records with a tool like MXToolbox or refer to the official DMARC specification in RFC 7483. That document makes it clear that relaxed alignment only applies to subdomain mismatches, not unrelated domains. You can verify domain alignment patterns ahead of sending by testing with tools that simulate real sender behavior.

Why you get fo=1 even with adkim=r

Even with adkim=r set, you get fo=1 when the DKIM signature's domain isn't hierarchically related to the From domain. For example, if your email is signed by sendgrid.net but the From header says company.com, that fails alignment—even under relaxed mode—because the domains aren't part of the same hierarchy. The relaxed alignment rule only applies within a known domain tree, not across unrelated senders.

Understanding DKIM and From domain alignment

DMARC's fo=1 means the From domain didn’t align with the DKIM signature domain. This isn’t a flaw in your setup—it's how the protocol works. adkim=r only relaxes the alignment requirement for domains that are subdomains of each other. If the signing domain is a completely different entity, like a third-party email service, alignment fails.

Let’s say you're using a transactional email platform that signs emails from yourcompany.com but sends from [email protected]. The From domain yourcompany.com isn’t a subdomain of sendgrid.net, so DMARC rejects it. This is common with bulk email platforms not configured for domain alignment.

Fixing the root cause: realign domains or use authorized senders

DMARC reports are only useful if you know what causes them. fo=1 isn’t an error—it’s intended behavior. The fix isn’t to change adkim=r; it’s to ensure your DKIM signing domain is a subdomain of your From domain. For example, sign from mail.yourcompany.com instead of a separate domain like sendgrid.net.

If you must use a third-party domain for signing (like a mail relay), make sure DMARC includes asp=1 or use a verified forwarding setup. You can test alignment before sending by checking your setup through tools like Mail-Tester or validating the full email stream with an inbox placement test. If you're sending bulk emails, use bulk email verification to catch issues before delivery.

For developers, check your DMARC record on MxToolbox or use RFC 7483 to confirm how relaxed alignment applies only within hierarchical domains. If you're unsure whether your setup meets DMARC’s expectations, verify the core email infrastructure with a real-time email verification API.

How to diagnose DMARC fo=1 alignment failures

When DMARC reports show fo=1 with adkim=r, it means the From domain and DKIM signature domain don’t align — even if the DKIM signature is valid. You’ll find these failures in aggregate (RUA) or forensic (RUF) reports. Filter those reports to see which emails sent from your domain were signed by a third-party service like SendGrid or Mailchimp. The mismatch between the From domain and the DKIM domain triggers the failure, even with relaxed alignment.

Step-by-step diagnostic process

Access your DMARC reports from RUA (aggregate) or RUF (forensic) email addresses. These reports are sent by mail receivers to your designated address or a third-party analytics service. They contain the full alignment status, including fo=1 failures.
Filter reports by the sending domain. Look for emails sent from your primary domain (e.g., [email protected]) but where the DKIM signature domain is different (e.g., [email protected] or [email protected]).
Check the DKIM-Signature header in the raw email. The d= value indicates the domain used for signing. Compare this to the From: header domain. If they don’t match — even when adkim=r — you’ll get a fo=1 violation.
Verify that third-party services use proper alignment. Some providers sign with their own domain (e.g., sendgrid.net), which breaks alignment unless you use a forwarding or BIMI setup to preserve the From domain. Check your provider’s documentation on aligned DKIM.
Use tools to simulate headers. A tool like DMARCian’s DKIM tester allows you to test how your DKIM signature aligns with your From domain, even before sending.

Common pitfalls and real-world fixes

Many teams assume adkim=r protects them from alignment issues. That’s not true — adkim=r only means alignment is relaxed, not ignored. A mismatch between d= and From: will still trigger fo=1 when the domains are different.

The 5 steps described in “Step-by-step diagnostic process”, in order.

If you use SendGrid or Mailchimp, confirm they’re using aligned DKIM — meaning the domain in the d= tag matches your From domain. Otherwise, you’ll trigger alignment failures even with valid signatures.

For high-volume senders, it’s worth verifying your email addresses and domains at scale before sending. With MailTester’s bulk verification, you can pre-check your list for invalid or risky addresses, reducing bounce risk and improving sender reputation—all while ensuring domain alignment is correct at the source.

Step-by-step: Fix alignment issues in third-party email workflows

If your DMARC policy uses adkim=r and you're seeing fo=1 fails, it means the From domain doesn't align with the DKIM signature domain. You’ll fix this by ensuring every email sent through third-party services like SendGrid or Mailchimp uses a DKIM signature that aligns with the From domain—either by signing with the From domain directly or a subdomain of it, and by using consistent From domains across SPF, DKIM, and email headers.

Verify third-party signing domains

Check the DKIM signature domain in your outbound emails. Use a tool like MxToolbox to analyze the headers of a real message. Look for the DKIM-Signature field and confirm the d= value. If it doesn’t match your From domain or a subdomain, alignment fails.
Configure your third-party service to sign with your From domain. Most platforms (SendGrid, Mailchimp, etc.) let you set a custom signing domain. Update your DNS records with a valid DKIM selector and public key, then assign that domain as the signing domain in the service’s settings. This ensures alignment with adkim=r.
If using a subdomain for signing, verify it’s properly aligned. For example, if your From domain is example.com, signing with mail.example.com is acceptable if you’ve published DKIM records for that subdomain. Ensure the DNS record includes d=mail.example.com and matches your email’s sending domain.

Enforce consistent From domain usage

Use the same domain in SPF, DKIM, and From. If your SPF record allows include:_spf.example.com, your DKIM should sign with example.com or a subdomain like mail.example.com. If the From domain differs, alignment breaks and triggers fo=1 in DMARC reports.
Reconfigure signing domains to match the From domain. If your marketing emails must come from [email protected], ensure the DKIM signature uses d=example.com and not a generic one like d=sendgrid.net.
Test the fix with real-world verification. Use MailTester’s email checker to validate that your From domain, SPF, DKIM, and alignment settings hold up in real conditions. Follow up with an inbox placement test to confirm emails land in inboxes, not spam folders. Test across multiple providers: Gmail, Outlook, Yahoo.

Alignment isn’t optional when adkim=r is enforced. A single mismatch in domain scope can cause DMARC rejection—even with valid SPF and DKIM.

DMARC reporting can be confusing, but the fix is mechanical: ensure the signature domain matches the From domain’s root or a subdomain, and test the full flow. Use tools that show real email behavior, not just syntax. That’s how you resolve fo=1 without weakening your security posture.

How to validate email addresses in bulk before sending

You can catch alignment issues early by running your entire email list through MailTester’s bulk verification API. It flags invalid, catch-all, and risky addresses—especially those from domains with adkim=r and weak email alignment—before you send, reducing bounces and inbox placement risk. No guesswork. Just pre-cleanup.

Run a full list scan with MailTester’s bulk API

Send your list through the bulk verification tool to process hundreds or thousands of addresses at once.
Let the API check each email against SMTP, MX records, domain reputation, and catch-all detection in real time.
Results return within seconds, with verdicts like valid, invalid, catch-all, or risky.

Focus on risky and invalid domains tied to DMARC

Sort the results by verdict: filter out invalid and catch-all addresses—they won’t deliver and often signal misaligned sender domains.
Pay close attention to the risky verdict. This includes domains using adkim=r with mismatched organizational domains or third-party email services like SendGrid or Mailchimp for signing, which fail alignment unless properly configured.
DMARC’s fo=1 reporting logs failures when the From domain and SPF/DKIM alignment don’t match. If your list includes addresses from domains with adkim=r but weak verification results, that’s a red flag for misalignment.
Use RFC 7483’s guidelines on DMARC implementation as a reference for how alignment checks work: https://tools.ietf.org/html/rfc7483.
If your campaign sends from a third-party service, validate that the From domain matches the authorized sending domain—or the alignment fails.

Proper email alignment isn’t just a technical detail. It’s required for inbox delivery when DMARC is strict. You can't rely on a single email pass. You must test the entire list.

After filtering, your list will have fewer non-deliverable addresses and fewer alignment mismatches. This reduces sender reputation risk and prevents DMARC policy enforcement issues. The next step? Use the real-time API to verify individual addresses before sending campaigns.

Use inbox-placement testing to validate sender alignment

Send real test emails through MailTester’s inbox-placement tool to see how Gmail, Outlook, Yahoo, and Apple Mail actually handle your messages. Compare delivery results across different From domains and signing domains to spot alignment issues. If delivery drops only appear for certain domains, cross-reference with your DMARC reports to confirm if misaligned SPF or DKIM are to blame.

Validate alignment under real-world conditions

Use MailTester’s inbox-placement testing to send identical messages with different From domains—some aligned, some not—to see how each performs in actual inboxes.
Send tests with and without proper SPF/DKIM alignment, focusing on cases where adkim=r is set but the From domain doesn't match the signing domain.
Check delivery results across major providers: Gmail, Outlook, Yahoo, and Apple Mail. Note differences in inbox placement, spam placement, or outright rejection.
Use your DMARC reports (via tools like dmarcian, Valimail, or Postmark) to correlate drops in delivery with alignment violations—especially for domains where adkim=r is enforced but alignment fails.
If a domain has high delivery failure only when used as From but not when aligned, that’s a strong signal of DMARC enforcement due to missing alignment under policy.

Confirm the cause with real data

DMARC’s adkim=r policy means the From domain must match the DKIM signature’s domain. If it doesn’t, the message fails alignment even if SPF passes.
Check RFC 7483 (section 4.1.2) for the specification on how alignment is determined during DMARC evaluation—especially how the From header and DKIM-Signature domain are compared.
MailTester’s inbox tests are tied directly to real recipient environments, so a failed delivery in test is a real-world signal—not a simulator guess.
Use the real-time verification API to pre-check addresses before sending, but remember: alignment issues may not show up in validation but will affect inbox placement.
For bulk campaigns, combine inbox testing with MailTester’s bulk list verification to clean invalid or risky addresses before testing delivery patterns.

Real inbox placement testing exposes alignment failures that static validation tools miss. What looks correct in a header check can still be rejected by Gmail’s DMARC enforcement when adkim=r is active.

How to integrate list hygiene with DMARC alignment

You can prevent DMARC failures caused by misaligned From addresses by proactively cleaning your email list using automated checks. Before sending, use MailTester’s API to validate every address, remove catch-all and role accounts (like info@ or sales@), and filter out disposable or outdated domains—these often trigger false DMARC reports when used as From addresses without proper alignment. This reduces reporting noise and protects sender reputation.

Automate list hygiene to match DMARC policy

Use MailTester’s real-time verification API to validate every address in your list before each campaign—this ensures only deliverable, properly aligned addresses are used.
Set up automated checks in your CRM or email platform to run on new list additions; this prevents misaligned addresses from ever reaching your sending system.
Filter out catch-all domains (where any address is accepted) as they often lack authentication and increase the risk of DMARC failure when used as a From address.

Eliminate high-risk addresses that distort DMARC data

Remove role accounts (e.g., admin@, support@) and generic addresses—these frequently fail alignment checks and are common in DMARC reports even when not sent from your domain.
Block disposable email domains using MailTester’s bulk verification tool; these often appear in DMARC reports due to high spam usage and poor sender reputation.
Exclude outdated or inactive addresses—these not only hurt engagement but may be flagged in DMARC reports due to incorrect or missing authentication records.

DMARC reporting with fo=1 and adkim=r is designed to catch misaligned sends. When you use unverified lists with weak hygiene, you increase the signal noise in these reports—not the actual threat. A clean list aligned with your domain reduces false positives and keeps your reputation intact.

DMARC is only effective when paired with sender authentication and list hygiene. Without both, reports become unreliable indicators.

For teams sending at scale, integrating this cleaning step into your pre-send workflow is as essential as setting up SPF and DKIM. This approach ensures only properly aligned, valid addresses are used—reducing bounce rate, improving deliverability, and making DMARC reports actionable, not overwhelming.

Real-time verification for dynamic or high-velocity sends

You can prevent DMARC alignment failures by verifying every new email address in real time before it hits your send pipeline. Use MailTester’s API to check validity, detect catch-alls, and catch invalid or misaligned addresses immediately—before they trigger bounces or damage sender reputation. This reduces misalignment risks tied to adkim=r, where strict alignment is enforced but the from domain doesn’t match the domain in the SPF or DKIM signature.

How to implement real-time verification

Integrate MailTester’s real-time API at the point of email capture (e.g., on your signup form or CRM data entry).
Validate each address against MX records, syntax checks, and SMTP-level presence before accepting it into your database.
Reject invalid or high-risk addresses—like role accounts, disposable domains, or known spam traps—immediately.
Use the MailTester API for high-velocity sends, ensuring every address meets delivery standards before hitting SendGrid, Klaviyo, or your SMTP server.
Set up automated workflows so valid, aligned addresses only proceed to your campaign or transactional engine.

Keep your data clean across platforms

When you add new subscribers via HubSpot, Mailchimp, or Klaviyo, run real-time checks before syncing. Some systems allow for pre-send validation via webhook, which can hook directly into MailTester’s verification API. This prevents misaligned or fake emails from ever being added to your list.

For example, a role account like [email protected] might technically appear valid, but it often fails DMARC when used as the return-path or from address. MailTester flags these as risky, helping you avoid alignment mismatches that cause rejection under adkim=r.

According to RFC 7483, strict DKIM alignment (adkim=r) requires the from domain to match the signing domain, which is why misaligned emails are rejected. Real-time filtering prevents this upstream.

Every validated address reduces your risk of DMARC failure, improves inbox placement, and protects your sender reputation. Start small with just 100 free verifications at MailTester’s pricing page, then scale as your list grows. No credit expiration. No false alarms. Just clean, deliverable data.

Why your DMARC fo=1 failures might not be fixable at scale

DMARC fo=1 reports aren't errors in your email — they're diagnostic signals showing where authentication failed due to domain alignment. If you're sending from a third-party provider that doesn’t support domain-aligned DKIM (like some older ESPs or unverified transactional services), fixing the alignment at scale may not be possible without changing providers. In those cases, you're limited to either accepting the risk or isolating the non-aligned domains to prevent broader deliverability damage.

Non-aligned DKIM is a reality for many providers

Many third-party email senders — especially those handling bulk transactional messages — use DKIM signatures tied to a generic or shared domain, not your own. When adkim=r is set (strict alignment), these emails fail DMARC evaluation even if the SPF and DKIM signatures are technically valid. This is not a flaw in your setup. It's a design limitation of the provider’s infrastructure.

According to RFC 7050, DMARC’s alignment requires that the domains in the from header and the DKIM signature match. If your ESP signs with example.net but you send from you.com, alignment fails. This is common with legacy systems. Let's be clear: if the provider doesn't allow domain-aligned signing, you can't fix it with configuration alone. You either switch providers, or you accept that some deliveries will be marked as failing alignment.

Segregate domains to reduce fallout

If you must use a non-aligned provider, don't mix your sender domains. Use a dedicated domain — like marketing.yourcompany.com or tx.yourcompany.com — for all outbound mail through that provider. That way, alignment issues stay isolated and don’t affect your core brand domain.

MailTester’s bulk verification tool can help you audit your list for high-risk or non-aligned sending patterns before deployment. You can test your domains at scale across multiple inboxes to catch alignment issues early, even before they trigger DMARC reports.

Remember: fo=1 is not a delivery failure. It’s a diagnostic signal, like a warning light. It tells you *where* the problem lies, not that the email is bad. Use it to clean your list, identify bad senders, and tighten your sender stack — not to reconfigure protocols that can’t be fixed.

Conclusion: Fix alignment, not just reporting

DMARC fo=1 reports with adkim=r are not a bug. They indicate a mismatch between the From domain and the DKIM-signing domain. This misalignment breaks email authentication and harms inbox placement.

Proactive verification reduces DMARC failures

Real-time email verification catches invalid, risky, and misaligned domains before they send. Inbox placement tests confirm whether mail reaches inboxes under realistic conditions.

With MailTester, you verify 98.9% of email addresses accurately. Catching misaligned addresses early reduces bounces and prevents DMARC failures before they impact sender reputation.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

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

Frequently asked questions

What does fo=1 mean in a DMARC report?

fo=1 means the From domain failed DKIM alignment. It reports a failure when the DKIM-signed domain does not align with the From domain, even if the signature is valid.

Can adkim=r fix misaligned DKIM signatures?

No. adkim=r relaxes alignment for subdomains but does not allow cross-domain alignment. A signature from sendgrid.com cannot align with a From domain of example.com, even with adkim=r.

How do I fix DMARC failures caused by third-party email providers?

Ensure the provider signs with a domain related to your From domain. If not, either reconfigure the provider or send from a dedicated domain aligned with the signing domain.

Can I ignore fo=1 reports in DMARC?

No. fo=1 reports help identify alignment issues that hurt inbox placement and sender reputation. Ignoring them leads to increased spam filtering and delivery failure.

What does a 'risky' verdict mean in MailTester?

A 'risky' verdict flags addresses with potential alignment, delivery, or reputation risks — such as role accounts, disposable domains, or mismatched domains in email headers.

Can I test inbox delivery without sending to real users?

Yes. MailTester’s inbox-placement testing simulates delivery to real inboxes using verified test accounts, helping you measure deliverability before sending to your audience.

How often should I verify my email list?

Verify your list before every major send and periodically on a scheduled basis. High-velocity senders should use real-time verification on every new address.

Do DMARC alignment issues affect all email recipients?

No. Only recipients who enforce strict DMARC policies and receive the email will log alignment failures. However, frequent failures harm sender reputation across all providers.

Is there a way to check DKIM alignment without sending an email?

Yes. Use MailTester’s API to check individual addresses for alignment risks, catch-all status, and deliverability issues before sending.

Why are some valid emails marked as 'invalid' by verification tools?

Addresses can be flagged as invalid due to temporary issues, DNS policy (like reject-all), or if they exist only as catch-alls or role accounts with no real user.

Can I trust tools like MailTester with my list data?

Yes. MailTester uses end-to-end encryption and does not store or resell your list. Verification results are processed securely and remain private by default.

How accurate is MailTester’s email verification?

MailTester achieves 98.9% accuracy in email verification, using real SMTP checks and pattern analysis to identify valid, invalid, catch-all, and risky addresses.