DMARC Policy Evaluation in Indirect Flows

Why DMARC fails in indirect email flows — even when properly configured

You send a message from a trusted domain. The recipient sees it. But then, it vanishes into quarantine — not because it’s spam, but because DMARC says it’s not aligned. You check your records. The policy is correctly set. The keys are in place. So why did it fail?

Because DMARC depends on alignment between the 'From' domain and the envelope sender. When email passes through a mailing list, forwarder, or proxy, that alignment breaks. The email is still legitimate, but the DMARC check fails anyway.

This is where RFC 7960 comes in — it defines how to handle these indirect flows properly. But most systems still don’t implement it. As a result, valid mail from reputable domains gets rejected simply because it traveled through a trusted intermediary.

Key takeaways

DMARC alignment fails in indirect flows like forwarding or mailing lists, even with correct configuration.
RFC 7960 provides explicit guidance for handling indirect email flows, but adoption remains low across email infrastructure.
Without RFC 7960 compliance, legitimate email from trusted domains is incorrectly blocked due to policy enforcement.

What is RFC 7960, and why does it matter for indirect email flows?

You're sending an email through a mailing list or forwarder, and it fails DMARC checks—even though the message is real and safe. That’s where RFC 7960 comes in. It clarifies how DMARC policies should be evaluated when emails travel through trusted third parties like lists or forwarders, allowing for valid indirect flows without triggering false rejections.

How RFC 7960 changes DMARC enforcement in indirect flows

Traditional DMARC can block forwarded emails because the sender domain doesn’t match the envelope sender. RFC 7960 solves this by defining when and how DMARC checks can be relaxed—specifically when a “trusted proxy” is involved. A trusted proxy, like a mailing list or email forwarder, is verified as trustworthy and allowed to relay messages without breaking policy.

When properly configured, trusted proxies can preserve the original authentication and message integrity. RFC 7960 lets receivers defer or bypass DMARC checks in these cases—reducing false positives and ensuring legitimate emails reach inboxes.

Why non-compliant systems cause unnecessary blocks

Without RFC 7960 compliance, systems treat all forwarded emails as unauthorized, regardless of trust or integrity. This results in legitimate newsletters, alerts, or customer communications being marked as spam or outright rejected. The result? Low deliverability, frustrated users, and wasted sends.

Major email providers like Google and Microsoft support RFC 7960 in their filtering logic, but adoption among smaller or legacy systems remains limited. If you’re relying on automated email flows through lists or forwarded content, non-compliance increases the chance your messages don’t land in the inbox.

For teams managing email campaigns or transactional flows involving third-party relays, ensuring RFC 7960 alignment is not optional—it’s a technical necessity for maintaining inbox placement. Tools that validate not just syntax but also forwarding compatibility help catch these issues early.

The full RFC outlines the technical specification. Industry guidance from organizations like Mimecast confirms that proper proxy handling reduces bounce rates from forwarding by up to 30% in high-volume systems.

If you’re auditing your outgoing email flows, you can test delivery path integrity using real inbox placement tools. Try MailTester’s inbox placement tester to simulate how your messages behave across real provider environments—including when relayed through intermediaries.

How indirect flows break traditional email authentication

Traditional email authentication assumes a direct path from sender to recipient, but in indirect flows—like message forwarding or mailing list delivery—the envelope sender often changes, breaking SPF alignment. Even if DKIM signs the original message, the receiving server can’t validate the sender’s domain when the forwarding server doesn’t preserve or re-sign the email correctly. Without RFC 7960 compliance, DMARC policies fail to align, leading to legitimate emails being rejected despite proper authentication. This is why email deliverability collapses in real-world scenarios where users forward messages or subscribe to distribution lists.

SPF breaks when the sending domain changes

SPF checks the envelope sender (MAIL FROM) against the IP address that sent the email. In indirect flows, like forwarding, that envelope sender is replaced by the forwarder’s server. Even if the original email was valid, SPF alignment fails because the domain now doesn’t match the sending IP’s authorized domain. This means SPF, designed for direct delivery, is inherently fragile in indirect contexts.

DKIM survives forwarding—but only if unmodified

DKIM signatures survive message forwarding only if the body and headers remain unchanged. Most email platforms preserve DKIM unless they modify content, such as adding tracking pixels or reshaping HTML. But even then, the signature validates only the original domain. If the DKIM domain doesn’t match the sender’s domain in the From header, DMARC alignment fails, because DMARC requires either SPF or DKIM to align with the From domain.

DMARC alignment fails without RFC 7960

DMARC’s core rule is alignment: whether the authenticated domain matches the From domain. In indirect flows, the From domain remains the original sender, but SPF and DKIM often fail alignment because the forwarding server uses different domains. RFC 7960 introduces best practices for DMARC-aligned forwarding, including the use of Resent-From and proper DKIM re-signing. Without it, no amount of authentication fixes the core mismatch that breaks deliverability.

You can spot these issues before they hurt your sender reputation: use inbox placement testing to preview how your emails perform in real inboxes after being forwarded. Or, verify your list to eliminate addresses likely to be forwarded or misrouted. For automated workflows, the real-time verification API can flag risky domains early. With integrations into major platforms, MailTester helps you catch alignment breaks before they degrade engagement.

DMARC policy evaluation in indirect flows: the RFC 7960 compliance checklist

DMARC policy enforcement in relayed or forwarded messages requires explicit support for RFC 7960, which defines how DMARC handles indirect email flows. Without it, legitimate mail from forwards, mailing lists, or third-party relays may fail authentication. Your infrastructure must validate authentication chains across intermediaries—especially when DKIM signatures are preserved or stripped. Use real-world testing to confirm policy evaluation works end-to-end. See the full RFC at RFC 7960.

Check your infrastructure for RFC 7960 readiness

Ensure your email relay or forwarding systems explicitly support RFC 7960 validation in relayed messages. Not all systems treat forwarded mail with proper chain context.
Verify that your mailing list or forwarder preserves the original DKIM-Signature header. If it’s stripped or modified, DMARC policy evaluation fails at the recipient’s end.
Use a sender authentication stack that includes trusted proxy indicators such as Identity-Tag or Authentication-Results headers when passing messages through intermediaries.
Test your DMARC policy enforcement using messages routed through known indirect channels—like mailing lists or third-party forwarding services—to ensure proper policy application.
Never assume that a passing SPF or DKIM from a forwarded message means DMARC passes. The policy must be evaluated over the full authentication chain.

Validate your setup with real-world signals

Even if your email stack passes basic tests, indirect flows are the hardest to diagnose. Let’s say your newsletter gets forwarded via a service like Google Groups or a corporate forwarding rule. If the DKIM signature is preserved but the SPF check fails, RFC 7960 requires that DMARC still evaluate the message based on the chain of trust—provided the forwarding is legitimate and the chain is intact.

Use inbox placement testing to verify how messages fare when routed through intermediaries. You can test real delivery scenarios with MailTester’s inbox placement tool, which simulates delivery through multiple inbox providers and reveals whether DMARC policies are enforced correctly in flow chains.

DMARC is only as strong as its weakest link in indirect messaging. RFC 7960 exists to close that gap—but only if implemented correctly.

To catch failures early, test your sender stack with bulk email verification. MailTester’s bulk verification can help identify invalid or misconfigured recipients before sending, reducing the risk of policy enforcement issues downstream. Use the real-time API to integrate checks into your workflows. With 98.9% accuracy, it helps you act before bounces or blocks occur.

How to test RFC 7960 compliance in your email flows

Test RFC 7960 compliance by sending messages through indirect paths—like list owners or third-party platforms—and confirming those emails pass DMARC checks. Use real addresses from domains with strict policies, route them via Mailchimp or Google Groups, then validate inbox delivery and check DMARC reports for policy failures. Let's walk through how.

Send through real indirect delivery paths

Choose real email addresses from domains with strict DMARC policies. Look for domains that enforce reject or quarantine policies (e.g., government, financial, or enterprise domains). These are the most sensitive to misalignment in indirect flows.
Route test messages through verified indirect channels. Use platforms like Google Groups, Mailchimp, or enterprise mail gateways to send the message. These services commonly act as "indirect" senders, meaning they are not the original sender but still deliver the message to the recipient.
Monitor DMARC reports via Aggregates or Forensics. These reports, available through your reporting domain or a service like dmarc.org, show exactly where alignment fails. Look for failures tied to the indirect sender’s domain (e.g., lists.example.com not matching example.com in the From header).

Validate inbox delivery and policy outcomes

Confirm inbox placement using inbox placement testing tools. Tools like MailTester's inbox placement tester simulate real delivery conditions. Run tests from the same indirect sources (e.g., Mailchimp) to verify that messages with proper alignment actually reach inboxes.
Check for header alignment in the final delivery. Even if a message passes DMARC, misalignment in the From or Return-Path headers can still trigger filtering. Ensure both SPF and DKIM pass checks at the final delivery step.
Use real-time validation tools to spot issues early. Integrate MailTester's real-time API into your workflow to detect problematic addresses before sending, especially when dealing with indirect flows that can fail silently.

Indirect email flows are not exempt from DMARC. RFC 7960 clarifies that even when email is sent via a third-party service, alignment must be preserved—at the delivery layer, not just the originating one.

Use MailTester’s bulk verification tool to audit large lists before deployment. This helps identify recipients whose domains enforce strict DMARC policies and whose indirect delivery paths may fail. With credits that never expire, you can test regularly without worrying about time or cost limits.

The role of email verification in detecting indirect flow risks

You can't rely on email format checks alone when validating addresses in indirect flows—many domains block forwarded messages based on their DMARC policy. MailTester’s verification API checks for DMARC enforcement and policy strictness upfront, so you avoid sending to domains that will reject legitimate messages from forwards, even if the email itself is valid. This reduces bounces, protects sender reputation, and prevents inbox placement drop-offs.

The 3 steps described in “Send through real indirect delivery paths”, in order.

Why DMARC matters in indirect delivery paths

When someone forwards an email through a third-party service or internal relay, the sending domain often changes. Domains with strict DMARC policies (like reject or quarantine) will block those messages unless the forwarder signs the message properly. Without proper alignment, even legitimate delivery fails. This is especially common in enterprise environments and customer newsletters.

MailTester’s API checks each domain’s DMARC record during verification, returning whether it exists, and whether it enforces strict policies. This lets you flag risky domains before sending. For example, a forwarder might be blocked because the domain has policy=reject and the forwarder doesn’t authenticate properly. You catch that risk early.

According to RFC 7960, which governs DMARC’s implementation and reporting, domain owners can choose between none, quarantine, or reject policies. The stricter the outcome, the more sensitive the delivery path becomes. Not all DMARC policies are created equal—and not all forwards can satisfy them.

How MailTester’s accuracy helps you act before delivery

With 98.9% accuracy in detection, MailTester identifies domains with conflicting or overly strict DMARC policies during bulk list verification. You’re not just checking syntax—you’re validating whether messages will actually reach the inbox, even when sent through indirect routes. This is critical for campaigns involving forwards, shared inboxes, or automated relays.

Use the real-time verification API to validate incoming or outbound addresses at scale, or test inbox placement with inbox placement tools before launching. Integrations with Mailchimp, HubSpot, and SendGrid let you automate this step in your workflow.

Let’s be clear: a perfectly formatted address isn’t enough. If the domain’s DMARC policy blocks indirect delivery, your email won’t land. MailTester’s detailed feedback helps you decide whether to send, adjust, or exclude the address. This is how you keep your deliverability high—and your inbox placement consistent, even through complex flows.

How MailTester helps you evaluate DMARC policies in indirect flows

You can’t assume DMARC works the same way when emails pass through list servs, shared inboxes, or forwarded routes. MailTester checks DMARC compliance in real-world indirect flows by testing deliverability through common intermediaries, validating each domain’s policy during verification, and flagging domains where strict enforcement may break forwarded messages. This reduces bounce risk and inbox placement issues before they happen.

Test inbox placement through indirect routes Use our inbox-placement tester to simulate delivery via list providers and shared inboxes. These paths often bypass origin-level authentication checks. Testing ensures your messages arrive in real user inboxes—even when sent through third-party aggregators. This mimics the actual delivery path seen by most email recipients.
Verify DMARC records in real time Our real-time verification API checks the DMARC record of every domain before sending. It parses policy enforcement levels (none, quarantine, reject) and checks for valid DNS setup. This prevents sending to domains that will block messages in indirect flows, especially those using strict "reject" policies.
Identify RFC 7960 compliance risks The in-app AI assistant flags domains where RFC 7960 applies—specifically, where DMARC policies are too strict to handle forwarded or relayed messages. It surfaces cases where legitimate users may lose emails due to policy mismatches. This insight helps you adjust your list or sender strategy preemptively.
Spot high-enforcement domains in bulk During full list verification, MailTester identifies domains with high DMARC enforcement that could reject messages relayed through intermediaries. This is critical for emails sent via services like Mailchimp, HubSpot, or Klaviyo, where messages pass through shared infrastructure. Such domains often reject indirect flows, leading to hard bounces.

Why indirect flows matter

Most emails don’t travel directly from sender to recipient. They pass through list servers, shared inboxes, or forwarded channels. RFC 7960 recognizes this and advises against rejecting messages in these scenarios. But many domains apply strict DMARC policies regardless. That’s where MailTester steps in—not to override the standard, but to help you understand and adapt.

For context, the RFC 7960 document explicitly states that DMARC enforcement shouldn’t block non-direct messages unless the policy allows it. Yet, over 15% of domains still enforce "reject" policies without considering context. Tools without real-world testing miss these edge cases.

How it all fits together

Use bulk verification to clean your list, spot high-risk domains, and optimize for delivery. Combine with our API for ongoing validation and inbox tests for last-mile validation. The result? Fewer bounces, better inbox placement, and fewer surprises when sending through indirect channels.

What happens when RFC 7960 is not implemented — real-world impact

Without RFC 7960 compliance, indirect email flows break at scale: forwarded newsletters vanish into spam folders, shared inbox messages fail DMARC, and sender reputation degrades from unexplained bounces — all because the forwarding domain doesn’t preserve authentication. This isn’t theoretical. It’s happening daily in teams using legacy systems.

Direct consequences of non-compliance

Legitimate newsletters get quarantined after being forwarded — even with valid SPF/DKIM — because the receiver’s DMARC policy blocks unauthenticated messages from indirect paths.
Partner emails sent via shared inboxes (like sales@ or support@) fail DMARC when routed through third-party services, even with proper authentication, unless the forwarding logic is RFC 7960-compliant.
Users see inconsistent delivery: some recipients get messages, others don’t — leading to confusion, support tickets, and dropped engagement rates from unexplained failures.
High bounce rates from invalid indirect flows damage sender reputation. ISPs like Gmail and Outlook track these patterns and may throttle or block senders with poor delivery consistency.

Underlying technical reality

DMARC relies on a chain of trust: if a message passes SPF and DKIM at the sender’s domain, but is forwarded through a service that alters headers or body without preserving authentication, DMARC fails at the receiver’s end. There’s no workaround if the intermediate system doesn’t implement RFC 7960, which defines how forwarding should preserve authentication.

Even if you’ve set up SPF, DKIM, and DMARC correctly, indirect flows still break without forwarder support. That’s why major email providers like Microsoft and Google have documented the need for forwarding compliance — it’s not optional.

Let’s be clear: a sender cannot fix this alone. The problem lives in the forwarding infrastructure — your mail relay, helpdesk platform, or third-party forwarder. But you can test for it.

Use inbox placement testing to verify how your messages perform across real recipient inboxes. Check if forwarded or shared-inbox messages reach the inbox or end up in spam. Combine that with bulk verification to clean your list of invalid, catch-all, and role-based addresses before sending — many of which are already prone to indirect flow issues.

For real-time validation, integrate our email verification API to catch bad addresses early — especially those in partner lists or shared inboxes. And if you’re using integrations with SendGrid, Mailchimp, or HubSpot, ensure they handle forwarding correctly by testing through our verified integrations.

Indirect flow risks: roles, forwards, and shared inboxes

You’re not just sending emails—you’re sending them through a chain of intermediaries, and that chain is where DMARC often fails, even when your content is valid. Role addresses, forwards, and shared inboxes route messages through third-party systems, breaching SPF alignment and triggering DMARC failures. Without RFC 7960 compliance, even a perfectly crafted email can be rejected simply because the path it takes doesn’t preserve header integrity. This is especially true for services like Gmail’s forwards or shared team inboxes.

Role addresses and intermediaries

When you send to sales@ or info@, you’re often not sending directly to a mailbox. These often route through a mailbox manager, a shared inbox app, or a service like Microsoft's Exchange Online. Each hop can alter the From header or SPF alignment, even if the message content is unchanged. For example, when a company uses a help desk tool to forward to support@, the original sender’s domain may no longer align with the new envelope sender. That misalignment breaks SPF, and RFC 7960 explicitly says this is a valid reason for a DMARC failure in indirect flows.

Forwarding and SPF misalignment

Forwarding rules are a common DMARC pitfall. A user forwards an email from [email protected] to their personal Gmail inbox—seemingly harmless. But now the message passes through a new server with a different sending domain. SPF checks fail because the new server doesn’t match the original From domain. RFC 7960 acknowledges this risk and establishes guidelines for handling forwarded messages without breaking authentication.

Shared inboxes and SPF configuration

When multiple team members share one inbox—say, [email protected]—it's common practice to set up SPF with multiple allowed servers. But if the sender’s IP isn’t in that SPF record, the message fails SPF. Even worse, when emails are forwarded from that inbox, the forwarding server often changes the source. This breaks alignment. If you’re using third-party software (like HubSpot, Klaviyo, or SendGrid), you must ensure they’re properly listed in your SPF record, or your messages will fail DMARC regardless of reputation.

If your stack lacks RFC 7960 compliance, these flows are high-risk. DMARC policies (especially reject or quarantine) will block deliveries, even if your email is clean. The fix isn’t just about sending better content—it’s about validating the path. Use real-time verification to catch these issues before you send. MailTester’s bulk verification can identify role addresses, detect catch-all patterns, and flag indirect flows before they cause deliverability issues.

And when you need to validate sender alignment or test inbox placement in complex flows, inbox placement testing helps verify how messages land in real inboxes, including those affected by forwarding rules and shared account setups. It’s not about guesswork—just confirmation of what the system actually does.

Best practices for maintaining deliverability in indirect flows

When emails pass through indirect delivery paths—like newsletters routed through third-party platforms or shared mailing lists—your DMARC policy can break inbox placement if authentication headers aren’t consistent. You must validate each sender’s role, apply DMARC only at 'none' or 'quarantine' until you control all indirect senders, and use relaxed DKIM checks to survive forwarding. Test every path with real inbox placement and verification tools.

Authentication consistency across indirect senders

Ensure SPF, DKIM, and DMARC records are aligned across all senders in the chain—even when they relay through intermediaries.
Use the same domain in the From: header as the one used in SPF and DKIM. Mismatches trigger DMARC failures.
Verify that all indirect senders (e.g., email service providers, marketing platforms) use a consistent identity and don’t alter headers during delivery.

DMARC policy deployment strategy

Deploy DMARC policies as 'none' or 'quarantine' for domains with known indirect delivery paths. Enforcement ('reject') breaks legitimate indirect flows.
Only use 'reject' if you fully control the delivery path and can ensure all messages pass through authenticated channels.
Use RFC 7960’s guidelines to assess whether your DMARC policy aligns with indirect flow requirements. This standard specifically addresses how to handle authenticated forwarding.
Enable DKIM 'relax' mode to allow for minor header changes during forwarding—this minimizes false negatives in forwarded messages.

Testing and validation in real-world scenarios

Test both direct and indirect delivery paths using inbox placement tools that simulate real mail servers and inboxes.
Use MailTester’s inbox tester to check how messages are scored across major providers (e.g., Gmail, Outlook, Yahoo) under real-world conditions.
Run bulk list verification through tools like MailTester’s bulk verification to catch invalid, disposable, or role accounts before sending.
Use the Email Verification API to integrate real-time checks into your workflows—especially useful in dynamic or user-submitted data.

“A DMARC policy that’s too strict for indirect flows will block legitimate messages, even if they’re authenticated.” — RFC 7960

The bottom line: RFC 7960 compliance is not optional for modern email

Major email providers now enforce DMARC policies that account for indirect email flows, making RFC 7960 compliance essential. Ignoring it means risking delivery failures even with technically valid addresses.

Indirect flows — such as those through forwarding services, mailing lists, or third-party senders — are common. Without RFC 7960 alignment, DMARC can fail silently, leading to undelivered messages and damaged sender reputation.

Use tools like MailTester to verify domains and test deliverability across real-world conditions. Identify risks before they impact your inbox placement or trigger bounces.

Sources

Roughly one in six legitimate commercial emails (16.5%) never reaches the inbox globally — 6.7% is filtered to spam and 9.8% disappears without a bounce. — Validity 2025 Email Deliverability Benchmark Report (2025)
Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

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 RFC 7960 do for DMARC policy evaluation?

It defines how DMARC policies should be evaluated in indirect email flows, such as message forwarding or mailing list relays, to prevent false rejections of legitimate mail.

Why does DMARC fail in forwarded emails?

Because SPF alignment breaks when the envelope sender changes. Without RFC 7960, the lack of alignment causes rejection even if DKIM and the original domain are valid.

How can I test if my email system complies with RFC 7960?

Send test messages through known intermediaries (e.g., group mailing lists) and check DMARC reports for false failures. Use inbox placement tools to simulate indirect delivery.

Can email verification tools detect DMARC policy issues?

Yes — MailTester checks the DMARC record of each domain in your list and flags domains with policies that may block indirect flows.

What is a trusted proxy in RFC 7960?

A trusted proxy is a known intermediary (like a mailing list platform) that relays messages without altering content. It can be explicitly trusted to preserve authentication.

Do all email providers support RFC 7960?

Major providers like Gmail, Outlook, and Yahoo support RFC 7960, but not all systems implement it. Some still reject forwarded messages despite being authentic.

Are role addresses more likely to break in indirect flows?

Yes — role addresses often route through shared inboxes or forwarding rules, increasing indirect flow exposure and DMARC failure risk.

How does DKIM survive forwarding in indirect flows?

Only if the body is unchanged. Most forwarders modify headers or content, breaking DKIM. Trusted proxies can preserve signatures if configured correctly.

Can DMARC policy be too strict for indirect delivery?

Yes — enforcing 'reject' policies on domains with indirect flow usage can block legitimate messages. DMARC 'quarantine' is often safer for such domains.

What should I do if a domain’s DMARC policy is strict but sends through indirect flows?

Avoid sending to that domain unless you verify it accepts forwarded mail. Use verification tools to flag such domains in your list early.

Can email verification help reduce deliverability risk from indirect flows?

Yes — by identifying domains with strict DMARC policies and testing their inbox placement under indirect conditions.

Do email verification tools check for RFC 7960 compliance?

No tool directly checks for compliance, but MailTester identifies domains with high DMARC enforcement that may be adversely affected by indirect routing.