# Why forwarded email fails DMARC—and how to diagnose it > Understand why SPF breaks after forwarding, when DKIM preserves DMARC alignment, how message modification changes the result, and what senders, forwarders, and mailing lists can fix. - **Category:** Deliverability - **Published:** August 4, 2026 - **Reading time:** 17 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/dmarc-failure-email-forwarding](https://emailbump.com/blog/dmarc-failure-email-forwarding) Forwarded email often fails SPF because the forwarding server—not the original sender’s authorized infrastructure—connects to the final receiver. DMARC can still pass when an original DKIM signature remains valid and its signing domain aligns with the visible From domain. If the forwarder or mailing list modifies signed content and breaks that DKIM signature, neither aligned path may remain. That does not mean every forwarded message fails or that DMARC is broken. It means indirect mail introduces another system between author and final receiver. Diagnosis requires the final message’s Authentication-Results, DKIM-Signature, From, Return-Path, Received, and ARC fields—not only a DNS lookup or a dashboard that says DMARC fail. > **SPF fail is not automatically DMARC fail** > > DMARC passes when at least one supported path passes and aligns: aligned SPF or aligned DKIM. A forwarded message can show SPF=fail, DKIM=pass, and DMARC=pass. Preserve those identities separately during investigation. ## Direct delivery versus forwarding ### What changes on the forwarded path ```text DIRECT Original sender IP -> final receiver SPF checks original MAIL FROM against original sender IP DKIM checks signed message against public key DMARC evaluates alignment with visible From FORWARDED Original sender IP -> forwarder -> final receiver SPF now sees forwarder IP; original MAIL FROM usually no longer authorizes it DKIM can survive if signed headers/body are not changed DMARC still needs aligned SPF pass OR aligned DKIM pass ``` ## Why SPF usually breaks after forwarding SPF authenticates an SMTP identity against the IP making the current connection. On the second hop, the forwarder’s IP is evaluated. If it preserves the original MAIL FROM, that domain probably does not authorize the forwarder. If it rewrites MAIL FROM to its own domain, SPF may pass for the forwarder but no longer align with the original visible From domain for DMARC. RFC 7960 describes both cases and concludes that forwarding generally cannot provide the original aligned SPF identifier; DKIM must carry the relevant aligned identity. Sender Rewriting Scheme can improve SPF behavior and bounce routing for a forwarder, but rewriting the envelope alone does not make the forwarder’s domain align with the author’s visible From domain. ## When DKIM preserves DMARC through forwarding DKIM signs selected headers and a canonicalized body. The final receiver retrieves the public key for the d= signing domain and verifies that the signed content still matches. When a valid signature uses the author’s domain—or an aligned organizational domain under relaxed alignment—DMARC can pass even though SPF failed after forwarding. ### Healthy forwarded result ```text From: alerts@example.com Return-Path: DKIM-Signature: ... d=example.com; s=transactional; ... Authentication-Results: final.receiver.example; spf=pass smtp.mailfrom=forwarder.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com SPF passes for the forwarder but is not aligned. Aligned DKIM carries DMARC. ``` ## How forwarding breaks DKIM - A mailing list adds a subject prefix such as [List] when Subject was signed. - A footer, unsubscribe block, or legal disclaimer changes the signed body. - A gateway rewrites links, re-encodes MIME, or changes content-transfer encoding. - An intermediary changes signed address headers or normalizes whitespace beyond the selected canonicalization. - The original selector is removed or its public key expires before delayed verification. - The original sender never attached an aligned DKIM signature, so SPF was the only possible DMARC path. Relaxed DKIM canonicalization tolerates some insignificant whitespace and header folding differences; it does not make arbitrary subject, body, URL, footer, or MIME changes safe. Inspect the exact signed-header h= list, body-hash result, signing domain, selector, and modifications on the route. ## Diagnose a forwarded DMARC failure step by step ### Evidence checklist ```text 1. Obtain raw source from the final receiver—not a screenshot or forwarded copy 2. Read the final receiver's Authentication-Results 3. Record visible From domain and DMARC policy domain 4. Record SPF result, smtp.mailfrom/helo identity, and alignment 5. Inspect every DKIM result with matching d= and s= 6. Compare DKIM d= with From under relaxed/strict alignment 7. Follow Received fields to identify direct and indirect hops 8. Inspect ARC sets and cv= result without treating ARC as DMARC pass 9. Compare an original delivered copy with the forwarded copy for modifications 10. Correlate aggregate DMARC reports by source IP, disposition, and auth result ``` Authentication-Results is meaningful only when you know which trusted receiver added it. A message can carry results from several hops, and arbitrary senders can add fake headers before delivery. Start with the final receiving system’s trusted header boundary and work backward. ## Read the four common result patterns ### Forwarding result matrix ```text SPF DKIM DMARC INTERPRETATION fail pass pass Normal forwarding pattern; aligned DKIM survived pass pass fail Neither passing identity aligns with visible From fail fail fail Forwarder IP unauthorized and DKIM absent/broken pass none fail Forwarder's SPF identity passes but is not author-aligned Also inspect policy override and local disposition. A receiver can accept a DMARC-failing message based on ARC, a known mailing list, local policy, or other evidence. ``` ## What ARC contributes Authenticated Received Chain lets participating intermediaries preserve authentication assessments and sign a chain describing handling across indirect hops. A final receiver can evaluate that chain as additional evidence. ARC does not make the current message pass DMARC, does not repair a broken original DKIM signature, and does not force a receiver to override the published policy. ARC value depends on chain validation and the receiver’s trust in the sealing intermediaries. Senders cannot solve a forwarding failure by adding an ARC header at origin and declaring success. Forwarders and mailing-list operators should follow RFC 8617 and their receiver ecosystem’s operational guidance. ## What the original sender can fix - DKIM-sign every legitimate stream with a domain aligned to the visible From domain. - Use current cryptography, valid selectors, stable key rotation, and signatures that verify on actual delivered messages. - Choose signed headers and canonicalization deliberately; do not omit important identity fields merely to survive mutation. - Inventory third-party platforms and ensure their DKIM signing identity aligns instead of relying only on SPF. - Monitor aggregate DMARC reports to separate direct unauthorized sources from known indirect flows. - Test important mailing lists and forwarding routes before moving an enforcement policy to broader coverage. - Do not weaken DMARC globally as the first response to one intermediary’s broken or modifying flow. ## What a forwarder or mailing-list operator can fix - Avoid modifying messages when the product does not require modification. - Preserve and evaluate original authentication results within a well-defined trust boundary. - Implement ARC correctly where the operator and downstream receivers support it. - Use a controlled re-sending model and From transformation only when the service’s role and user experience justify it. - Apply SRS or equivalent envelope handling for SPF/bounce operation without misrepresenting it as DMARC alignment. - Authenticate the intermediary’s own notifications and bounce paths. - Publish clear behavior for subject tags, footers, MIME transformation, and From rewriting so senders can test the route. ## Do not misdiagnose legitimate failure as forwarding Attackers can claim forwarding, and unauthorized platforms can appear beside real forwarders in aggregate reports. Confirm the Received chain, known intermediary, recipient route, volume, and authentication evidence. A source sending directly from an unknown network with no aligned DKIM is not excused merely because SPF failure also happens during forwarding. ## Frequently asked questions ## Does email forwarding always break DMARC? No. Forwarding often prevents SPF from contributing an aligned pass, but DMARC can still pass through an aligned DKIM signature that survives unchanged. Failure becomes more likely when the sender lacks aligned DKIM or an intermediary modifies signed content. ## Does SRS fix DMARC? SRS can rewrite the envelope sender so the forwarding server can pass SPF and route bounces. That new SPF identity usually belongs to the forwarder and does not align with the original visible From domain, so SRS alone does not make DMARC pass. ## Does ARC override a DMARC reject policy? ARC supplies a signed chain of intermediary authentication evidence. A receiver may use a valid, trusted chain in its local disposition decision, but ARC does not change the current DMARC result or compel an override. ## Inspect the headers from the failed forwarded message Parse Authentication-Results, Received, SPF, DKIM, DMARC, ARC, return path, and signing identities locally before changing DNS or policy. [Open the header analyzer](https://emailbump.com/tools/email-header-analyzer) ## Trace the complete authentication path - [DMARC phishing protection](https://emailbump.com/blog/dmarc-phishing-protection) — Deploy reporting, alignment, policy, exceptions, and enforcement without guessing. - [Gmail via label](https://emailbump.com/blog/gmail-via-label-dkim-alignment) — Understand visible identity when DKIM alignment is missing or delegated incorrectly. - [DKIM record checker](https://emailbump.com/tools/dkim-record-checker) — Inspect the exact selector, alias chain, algorithm, and published public key. - [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder) — Build a syntactically valid policy and reporting record with explicit evidence. ## Sources - [RFC 7489: DMARC](https://www.rfc-editor.org/rfc/rfc7489) - [RFC 7960: DMARC and indirect email flows](https://www.rfc-editor.org/rfc/rfc7960) - [RFC 8617: Authenticated Received Chain](https://www.rfc-editor.org/rfc/rfc8617) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208)