How to handle DMARC failures when email is forwarded by recipients?
Updated on 31 Jul 2026: We updated this guide for RFC 9989, added SRS guidance, and replaced percentage-based policy staging with current testing guidance.
The practical answer is this: you cannot fully fix recipient-side forwarding from your own DNS. You can reduce the damage by making DKIM as resilient as possible, separating high-forwarding mail onto its own subdomain, keeping that subdomain at p=quarantine or a carefully monitored p=none until the risk is measured, using DMARC reports to identify the receiving domains involved, and giving affected customers a short technical note they can hand to their mail admins. For operational alerts, add a non-email alert endpoint so a customer's broken forwarding path does not become the only incident delivery path.
Forwarding can break DMARC because SPF is tied to the sending IP and MAIL FROM domain seen by the final receiver, while DKIM breaks when a forwarder, security gateway, mailing rule, or ticketing system modifies signed headers or body content. DMARC only needs one aligned pass, SPF or DKIM, but forwarded mail often loses SPF alignment by design and then loses DKIM because the message changed in transit. That is why a message can be clean when it leaves your platform and still appear as a DMARC failure in aggregate reports.
Focus on protecting the domain and important recipient workflows while proving which failures are expected forwarding versus real unauthorized sending. A perfect pass rate is not useful when you do not control the last hop. Good DMARC monitoring matters here because raw aggregate reports are too hard to read manually when the failure pattern is intermittent.
Why forwarded email fails DMARC
DMARC passes when SPF or DKIM passes and its authenticated domain matches the visible From domain under the published alignment mode. Forwarding changes the route. The final mailbox provider sees the forwarder's IP, not the original sending IP, so the original SPF identity usually fails. A forwarder can rewrite the envelope sender so SPF passes for its own domain, but that rewritten domain usually does not match the unchanged From domain. DKIM can preserve the DMARC pass only if an aligned signature and its signed content remain intact.
- SPF path: Ordinary forwarding breaks the original SPF result. SRS can make SPF pass for a rewritten MAIL FROM domain without restoring DMARC alignment.
- DKIM path: DKIM survives if the signed headers and body remain intact, but footers, URL rewriting, security banners, and MIME changes can break it.
- DMARC domain match: DMARC still fails if SPF and DKIM pass for domains that do not match the visible From domain under the published alignment mode.
- Receiver policy: Receivers decide final handling and can override the published assessment policy when they trust the forwarder or have reliable local evidence.
Flowchart showing how forwarding causes SPF failure and depends on DKIM survival.
A high DMARC failure rate on a forwarding-heavy alert subdomain does not automatically mean your sender setup is broken. Separate expected forwarded failures from unauthorized sources before moving that subdomain to p=reject.
A useful pattern is a sharp increase in failures from a small set of receiver or security gateway networks while the original sources still authenticate cleanly. If the same customer domain accounts for the spike every time, the issue is usually a forwarding rule, a mail flow connector, a security gateway, or an internal system that receives and re-sends alerts.
Why SRS does not fix DMARC by itself
Sender Rewriting Scheme (SRS) lets a forwarder replace the MAIL FROM address with one in a domain it controls. The final receiver can then validate the forwarder's IP against that rewritten domain, and bounce messages can return through the forwarder. SRS fixes an SPF forwarding problem, but it does not normally create SPF alignment for DMARC because the visible From domain stays unchanged.
- SPF pass with DMARC fail: Check whether the SPF-authenticated SRS domain differs from the visible From domain.
- Aligned DKIM pass: DMARC passes even when the original SPF path breaks, provided the aligned DKIM signature survives.
- Aligned DKIM failure: The forwarder must stop changing signed content, or the final receiver needs trusted ARC or other local evidence to override policy.
This distinction prevents a common troubleshooting error. A report row showing SPF pass is not proof that DMARC should pass. Compare the SPF-authenticated domain and DKIM signing domain with the visible From domain before changing DNS or contacting the recipient.
What to do first
Start by proving whether the failures are forwarded mail, then decide whether the policy should absorb those failures or whether customer outreach is justified. Do not raise enforcement on a subdomain used for critical alerts until the top failing sources and receiver dispositions are understood.
Sender controls
- Sign with DKIM: Use DKIM matched to the From domain on every alert message and avoid signing only with a third-party domain.
- Limit mutations: Keep alert templates plain and avoid downstream systems that rewrite body content before sending.
- Segment subdomains: Use a dedicated alert subdomain so forwarding risk does not block enforcement on the primary domain.
Recipient controls
- Fix forwarding: Recipients can use forwarding methods that preserve authentication or add narrowly scoped internal allow rules.
- Preserve DKIM: Security gateways should avoid adding banners or changing MIME structure on signed alert mail.
- Use ARC: ARC helps when the forwarder and final receiver both support and trust the chain.
A simple diagnostic order works well. First, validate your own DNS and signing. Then group DMARC failures by source IP, reporter, header From domain, DKIM domain, SPF domain, and policy disposition. Finally, compare the failure volume against the customer domains receiving the most alert traffic. If one or two customer environments create most of the failures, the next step is targeted outreach. If failures are spread across many forwarded environments, policy segmentation and alternate delivery channels matter more.
DMARC testing record for an alert subdomaintext
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@yourdomain.com
RFC 9989 made pct historic and introduced t=y to request testing behavior. The example keeps aggregate reports on and leaves alignment at its relaxed defaults. Older receivers ignore an unrecognized t tag, so use p=none when monitoring-only behavior must be clear across older implementations. Move the dedicated subdomain to quarantine only after legitimate sources and forwarding impact are understood.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to read the reports
The biggest mistake is treating a DMARC fail count as a delivery fail count. Aggregate reports show authentication results and the receiver's reported disposition, but not every reporting source provides complete or consistent detail. A message can fail DMARC in a report and still be delivered because the receiver applied a local override, trusted a forwarder, or used the result as one input to its own filtering decision.
|
|
|
|---|---|---|
SPF fail, DKIM pass | Normal forwarding | Check DKIM alignment |
SPF pass, DMARC fail | SRS or unaligned domain | Compare domains |
SPF fail, DKIM fail | Forwarder changed mail | Group by receiver |
Pass, no alignment | Wrong authenticated domain | Fix sender |
Fail, delivered | Policy override | Monitor trend |
Sudden spike | New route | Identify source |
Use this table to classify the likely cause before changing policy.
Suped's product supports this workflow by turning aggregate XML into source groups, authenticated and unauthenticated streams, and specific issues with remediation steps. This helps separate your own configuration problems from recipient-side forwarding failures, which is the difference between a DNS fix and a customer mail-flow conversation.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Inspect receiver clusters rather than single rows. Mailbox providers, secure email gateways, cloud security appliances, and ticketing systems can appear as the visible source after forwarding. If the original mail matched the From domain on the way out, the failure source in the report is often the second hop, not your application.
A useful check is to send a controlled sample through the same alert template to a mailbox you control, then forward it through known routes and inspect the headers. That does not reproduce every customer setup, but it proves whether your DKIM signature survives common forwarding and security scanning. For broader checks, a domain health check helps confirm the base DMARC, SPF, and DKIM setup before blaming forwarding.
Policy choices for critical alerts
For high-value operational alerts, split policy decisions by domain purpose. RFC 9989 warns that p=reject can disrupt indirect mail flows and advises against it for general-purpose email. A dedicated alert subdomain can use a separate policy after every legitimate source is authenticated and the recipient-forwarding impact is understood.
DMARC policy posture for forwarded alert mail
Use source classification and customer impact. A universal pass-rate threshold is not reliable.
Stable enforcement
Failures understood
Legitimate failures are rare, classified, and acceptable to the business.
Staged enforcement
Impact measured
Known forwarding failures remain and affected recipients have a mitigation path.
Monitor or quarantine
Risk unresolved
Failure sources are unknown, customer impact is unclear, or disposition data is incomplete.
A strict reject policy on an alert subdomain can punish a customer who configured an internal route you cannot see. Quarantine is often the pragmatic middle ground for a subdomain that exists only to send customer-configured alerts. It signals that unauthenticated mail is suspicious while leaving the receiver free to apply local evidence and handling.
If you need simpler policy management, Suped's Hosted DMARC can manage changes without repeated DNS edits. That is useful when one subdomain needs a slower rollout than the main domain.
The better long-term setup is to keep the alert domain isolated, maintain strong DKIM, publish clear customer-facing mail-flow guidance, and add real-time monitoring for new unknown sources. If a new source starts sending unauthenticated mail under the alert domain, that is different from known forwarded mail and should trigger investigation.
What ARC can and cannot solve
ARC can help a receiver assess forwarded mail, but only when the forwarding system seals the original authentication result and the final receiver trusts that seal. If you do not control the recipient's forwarding environment, ARC is not something you can switch on from your own domain and expect the final mailbox to honor.
Where ARC helps
- Trusted forwarders: The forwarder records that DMARC passed before it changed the path.
- Mailing systems: Intermediaries can preserve authentication context after list or gateway handling.
- Receiver discretion: The final receiver can override a DMARC fail when the ARC chain is credible.
Where ARC does not help
- No seal: If the forwarder does not add ARC, there is no chain to evaluate.
- No trust: If the final receiver does not trust the ARC signer, it still treats DMARC as failed.
- Bad original authentication: ARC records prior results; it does not repair a bad original setup.
ARC explains why some forwarded messages get delivered even when DMARC fails in the final report. If the customer controls the forwarding platform and asks what to change, point them toward ARC-aware forwarding and DKIM-preserving mail handling. Otherwise, assume ARC coverage is inconsistent and design policy around measured results. The mechanics are covered in more depth in this ARC implementation guide.
Customer outreach that works
When you cannot change the forwarding path, use targeted customer education. Send customer admins a technical note that says exactly what is happening, why their forwarding path breaks authentication, and what they can change without weakening domain security.
Short customer admin notetext
Our alert emails are DKIM signed and DMARC domain-matched when sent. Your mail route appears to forward or reprocess these alerts before final delivery. That can break SPF and DKIM at the final mailbox. Please preserve DKIM signatures, avoid adding banners or modifying MIME content on these alerts, and use forwarding rules that preserve authentication results where available. If your platform supports ARC, enable ARC sealing for forwarded mail. Sending domain: alerts.example.com DKIM domain: alerts.example.com Return-Path domain: bounce.alerts.example.com
If you can identify the affected organizations, use targeted outreach. If you cannot, add a support article and send a technical setup reminder to all customers who use email alerts. Keep it operational: this is about preserving alert delivery, not asking them to trust unauthenticated mail.
A second alert channel is often the cleanest mitigation. Email should still work, but critical firmware, infrastructure, or monitoring alerts should also support webhook, push, incident platform, SMS, or API polling endpoints where the customer's mail forwarding setup is not in the path.
Add account-level visibility so customers can see whether recent alerts were accepted by your sending provider, whether bounces occurred, and whether their configured address has a forwarding warning. You cannot see every internal hop, but you can give customers enough evidence to involve the right mail admin.
A practical operating model
For a domain with heavy recipient forwarding, use an operating model rather than a one-time fix. It has four parts: isolate the traffic, make the original authentication consistently correct, measure the failures, and avoid hard reject until the unresolved failures are acceptable for the business.
- Create a subdomain: Send customer-configured alerts from a dedicated domain such as alerts.example.com.
- Authenticate every source: Match SPF where possible and make aligned DKIM mandatory for every alert stream.
- Monitor disposition: Track none, quarantine, reject, and override patterns instead of looking only at pass rate.
- Classify failures: Separate expected forwarding, broken customer routing, unknown senders, and true spoofing.
- Stage policy: Move the dedicated subdomain between p=none, p=quarantine, and p=reject only after measuring the impact of the full policy change.
Suped's product supports this model with DMARC source grouping, authentication issue detection, hosted policy management, and alerts for new unauthenticated sources. For MSPs and teams managing many customer domains, its multi-tenant view keeps forwarding exceptions visible instead of leaving them in XML files or one-off spreadsheets.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The main judgment call is policy. If the subdomain sends login codes, safety alerts, production monitoring messages, or firmware issue notifications, do not treat a known recipient-forwarding failure the same way as spoofing. Keep the domain protected without making a policy choice that silently breaks the customer's alerting architecture.
Views from the trenches
Best practices
Use a dedicated alert subdomain so forwarding risk stays away from the primary domain.
Group failures by receiver and source network before deciding whether policy needs to change.
Give customer admins a short setup note that explains DKIM preservation and forwarding.
Common pitfalls
Do not assume every DMARC failure means rejection; receiver overrides are common.
Do not move critical alert domains to reject when the main failures are still unexplained.
Do not rely on raw XML review when intermittent forwarding creates large failure spikes.
Expert tips
Add a second alert channel for high-impact notices that cannot depend on customer forwarding.
Treat ARC as a receiver-side aid, not a sender-side fix for every forwarding failure.
Track customer-facing impact separately from authentication failure percentages.
Marketer from Email Geeks says cross-tenant forwarding problems are common, and targeted outreach is usually the best option when the sender cannot change recipient mail flow.
2024-04-02 - Email Geeks
Marketer from Email Geeks says adding a second alert channel can reduce business risk when customer forwarding paths break authentication for critical notices.
2024-04-02 - Email Geeks
The right answer is controlled tolerance
When recipient forwarding causes DMARC failures, the right answer is controlled tolerance. Keep your original mail fully authenticated. Make DKIM resilient. Segment the sending domain. Use reports to identify the actual forwarding clusters. Keep enforcement strong where you control the flow, and stage the alert subdomain separately where customers control the final route.
Suped's product provides the report grouping, issue detection, hosted policy management, and alerting needed for this workflow without manual XML review. The visible failure pattern helps you protect the domain without breaking important customer workflows.
