How to handle DMARC failures when email is forwarded by recipients?
Updated on 6 Oct 2026: We clarified forwarded-email troubleshooting with final-hop header checks, DKIM preservation, and current DMARC policy guidance.
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 a new alert subdomain at p=none while the risk is measured, using DMARC reports to identify forwarding sources and reporting receivers, and giving affected customers a short technical note they can hand to their mail admins. Consider p=quarantine after measuring its effect on legitimate mail. 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 and then depends on DKIM remaining valid. 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. Relaxed alignment accepts authenticated domains with the same organizational domain; strict alignment requires an exact domain match.
This problem chiefly affects automatic forwarding or redirect rules that keep the original visible From address. A manual Forward normally creates a new message with the recipient's own From address, so DMARC evaluates that new sender. Forwarding the original message as an attachment also leaves the outer message subject to the new sender's authentication.
- SPF path: Ordinary forwarding usually breaks SPF for the original MAIL FROM domain when the forwarder's IP is not authorized. 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.
Automatic email forwarding changes the sending IP; DMARC depends on a surviving From-matched DKIM signature.
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. Correlate that pattern with recipient complaints and sending logs before attributing it to a customer forwarding rule, mail flow connector, security gateway, or internal system that 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: If the original signature was valid, the forwarder must preserve 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. Do not add recipient forwarding servers to your SPF record solely to hide these failures. That authorizes them to use your envelope domain and does not fix an SRS domain mismatch or a broken DKIM signature.
Check sender authentication before changing policy
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.
- Sign after processing: Apply DKIM after template rendering, link tracking, and MIME encoding so your own sending pipeline does not invalidate the signature.
- Segment subdomains: Use a dedicated alert subdomain so forwarding risk does not block enforcement on the primary domain.
Recipient controls
- Fix forwarding: Recipient admins can preserve DKIM or configure trust for a verified forwarding route.
- Preserve DKIM: Security gateways should avoid adding banners or changing MIME structure on signed alert mail.
- Use ARC: The forwarder must seal the authentication results, and the final receiver must validate the chain and trust the relevant sealer.
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 those groups with sending logs and recipient complaints. If one or two customer environments account for most confirmed forwarding failures, the next step is targeted outreach. If failures are spread across many forwarded environments, policy segmentation and alternate delivery channels matter more.
If your signing system supports it, use DKIM c=relaxed/relaxed canonicalization to tolerate specified whitespace changes and header rewrapping. It does not preserve DKIM through URL rewriting or added footers, and edits to signed header values beyond the specified formatting tolerance still break verification. This setting is separate from relaxed DMARC domain alignment. The canonicalization rules are defined in RFC 6376.
Monitoring TXT record at _dmarc.alerts.example.comtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com
RFC 9989 made pct historic and introduced t=y for testing. Receivers supporting this mode apply none instead of quarantine for p=quarantine; t=y, and quarantine instead of reject for p=reject; t=y. Older receivers ignore an unrecognized t tag and retain the published policy, so the example uses p=none for a clear monitoring request across implementations. It keeps aggregate reporting enabled and alignment at its relaxed defaults.
Publish the record at the alert subdomain's own DMARC hostname, and replace the reporting address with your configured report destination. Without a separate record, the subdomain inherits an applicable parent policy, including sp where specified. Remove t=y if used during testing, or set t=n, when you intend the published quarantine or reject policy to apply.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to read DMARC forwarding 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. A disposition of none means no DMARC quarantine or rejection was reported; it does not prove inbox placement. Aggregate reports do not reliably identify individual recipients or show every internal forwarding hop.
|
|
|
|---|---|---|
SPF fail, DKIM pass | Forwarding or SPF configuration | Check that passing DKIM matches From |
SPF pass, DMARC fail | SRS or another unaligned SPF domain, with no aligned DKIM pass | Compare both authenticated domains with From |
SPF fail, DKIM fail | Content changes, sender setup errors, or spoofing | Compare direct and forwarded headers |
Authentication pass, DMARC fail | No passing authentication matches From | Check domains and alignment modes |
DMARC fail, disposition none | Monitoring policy or receiver override | Read the published policy and override reason |
Sudden failure spike | Route change, configuration change, or unauthorized sending | Correlate report sources with logs |
These signals suggest causes to investigate; they do not prove forwarding.
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 reported source IP is the system that connected to that reporter, which can be a later forwarding hop rather than your application. Compare auth_results (raw SPF and DKIM outcomes) with policy_evaluated (DMARC domain matching and disposition), and inspect any override reason. RFC 9990 defines these report fields.
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 shows whether your DKIM signature survives the specific routes tested. For broader checks, use a domain health check to inspect the published DMARC, SPF, and DKIM records; a message-level test is still needed to verify actual signing and forwarded delivery.
How to check forwarded message headers
Ask the affected recipient for the raw message headers at the first mailbox and final destination. A pass recorded before forwarding does not prove that the last hop passed. Use the Authentication-Results added by the final receiving system within its trusted mail environment; earlier or sender-supplied copies are not authoritative. RFC 8601 explains this trust boundary.
Illustrative final-hop results after SRS and a broken DKIM signaturetext
Authentication-Results: mx.destination.example; spf=pass smtp.mailfrom=forwarder.example; dkim=fail header.d=alerts.example.com; dmarc=fail header.from=alerts.example.com Return-Path: <SRS0=hash=tt=alerts.example.com=alerts@forwarder.example> From: Alerts <alerts@alerts.example.com>
SPF passes here for the forwarder's envelope domain, but it does not match the original From domain. DKIM fails, so neither method provides the From-matched pass DMARC needs.
- Read the Received headers in chronological order, usually bottom to top, to identify the forwarding hop. Confirm the route against trusted receiving logs.
- Compare smtp.mailfrom with header.from, then check every DKIM header.d result. One passing DKIM signature matched to From is enough, even if another signature fails.
- Compare the direct and forwarded DKIM results. A body hash mismatch supports a content-change diagnosis; a missing selector or unavailable key needs a separate DNS investigation.
- If the message was rejected, collect the full non-delivery report (NDR), the rejecting host, and the SMTP response. A generic 550 5.7.1 response alone does not establish a DMARC cause.
After a recipient admin changes the route, repeat the same forwarding test and check both authentication results and actual mailbox delivery before changing your DMARC policy.
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
Known legitimate failures have a tested mitigation and acceptable business impact.
Staged enforcement
Impact measured
Known forwarding failures remain and affected recipients have a mitigation path.
Monitor first
Risk unresolved
Failure sources are unknown or customer impact is unclear. Diagnose them before increasing enforcement.
A strict reject policy on an alert subdomain can reject legitimate mail when a customer configures an internal route you cannot see. Quarantine requests suspicious-mail handling, often a spam folder or administrative quarantine, so it can still delay or hide critical alerts. Choose it only after measuring recipient impact; the receiver remains free to apply local policy.
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 monitor new unknown sources as aggregate reports arrive. 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
Authenticated Received Chain (ARC) records authentication assessments at participating mail-handling hops and seals those records. It can help a receiver assess forwarded mail when the chain validates and the receiver trusts the relevant sealer. If you do not control the recipient's forwarding environment, publishing a DNS record cannot make the final mailbox use ARC. RFC 8617 defines the protocol.
Where ARC helps
- Trusted forwarders: The forwarder records the authentication result it observed before making its changes.
- 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. An arc=pass result confirms chain validation, not that the receiver trusts the sealer or will deliver the message. Otherwise, assume ARC coverage is inconsistent and design policy around measured results. The mechanics are covered in more depth in this ARC implementation guide.
What to send recipient mail admins
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 pass DMARC through a From-matched DKIM signature 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 and avoid adding banners or modifying MIME content on these alerts. If your platform supports ARC, enable sealing and verify that the final receiver trusts the relevant sealer. Please share the final receiver's Authentication-Results and Received headers, or the full non-delivery report, so we can compare the two hops. Sending domain: alerts.example.com DKIM domain: alerts.example.com Original 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 the first recipient server, whether bounces occurred, and whether a forwarding warning is supported by a confirmed test or recipient report. Acceptance at the first hop does not confirm delivery after forwarding. 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 and publish its own DMARC record.
- Authenticate every source: Match SPF where possible and make aligned DKIM mandatory for every alert stream.
- Monitor disposition: Track pass, none, quarantine, and reject dispositions plus override reasons; receivers using older report formats do not emit a separate pass disposition.
- 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 view
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 view
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
Frequently asked questions
Not completely. Your DNS can make the original message authenticate correctly, but it cannot force a recipient's forwarder to preserve SPF, DKIM, or ARC.
Use reject only when legitimate failures are understood and acceptable. For critical alert subdomains with unresolved forwarding failures, start with a monitored p=none period. Quarantine still risks putting legitimate alerts in spam or administrative quarantine.
Not by itself. SRS rewrites the MAIL FROM address so SPF can pass for the forwarder's domain, but that domain usually does not match the unchanged visible From domain.
A From-matched DKIM signature can keep DMARC passing after forwarding. It must remain valid at the final receiver; changes to signed headers or body content beyond the signature's canonicalization tolerance break it.
ARC does not change the DMARC result. It can help the final receiver trust the original authentication result, but only when the forwarder seals the message and the final receiver trusts that ARC chain.
Group reports by source, reporter, disposition, DKIM domain, and SPF domain, then compare those patterns with sending logs and final-hop headers. An unknown source or a gateway IP alone does not prove spoofing or forwarding. Confirm that the original message passed before the route changed.
