Why forwarded email fails SPF or DMARC, and what SRS and ARC can do

Draw the actual route before editing records

Imagine a studio receiving mail at contact@studio.example and automatically forwarding it to reader@inbox.example. A supplier at sender.example sends the original message. There are now two delivery legs: supplier to studio, then studio’s forwarding service to the final inbox.

Record who operates each leg, whether the studio keeps a local copy and whether another rule forwards the message again. Distinguish automatic redirection from a person clicking Forward, an alias delivered within one mail system, or an application submitting a new message. These can produce different message identities and processing.

For each troublesome route, ask which exact recipient failed. “Email works” is too broad when the local copy arrives but the final copy does not. Avoid circular rules or multiple overlapping destinations that make ownership and duplicate-message behaviour difficult to understand.

Separate the displayed author from the envelope sender

SPF, defined in RFC 7208, evaluates whether a sending host is authorized for an SMTP identity, normally MAIL FROM, with HELO also relevant. It does not simply check the From label somebody sees in their email app.

On the second delivery leg, the final server sees the forwarder’s connection. If the envelope still claims the original supplier’s domain, that supplier’s SPF policy may not authorize the forwarding server. An SPF failure can therefore occur even when the original sender’s direct route was correctly configured.

Do not “repair” this by adding the studio’s own SPF include to a record you do not control, or assuming an SPF change for studio.example changes sender.example’s policy. Identify the evaluated identity and connection first. Our authentication setup guide covers the separate task of authorizing your own genuine sending systems.

Understand what SRS changes and what it leaves alone

A forwarding service may use Sender Rewriting Scheme, or SRS, to rewrite the envelope sender into a domain it controls. Microsoft’s SRS documentation describes that distinction: the SMTP MAIL FROM is rewritten while the visible From remains unchanged.

That can let SPF validate the forwarding leg against the forwarding domain. It does not automatically align that domain with the original author for DMARC. Treat “SPF passed after SRS” and “DMARC passed for the original author” as different questions.

Ask the forwarding provider whether SRS applies to your exact forwarding method and how non-delivery reports are routed. Support for one mailbox rule does not prove identical treatment for every group, relay, catch-all or hybrid configuration. Do not manually improvise an SRS-looking address in a mail rule.

Preserve an aligned DKIM signature where possible

RFC 6376’s DKIM specification describes signatures over selected headers and message-body content. A valid signature can survive a change of sending server, provided the protected material remains compatible with the signing and canonicalization rules.

Forwarding software that appends a footer, rewrites a signed subject or re-encodes content can invalidate a signature. Adding the forwarder’s own new signature may establish that domain’s involvement, but it is not automatically a signature aligned with the original author’s domain.

Google’s forwarding guidance emphasizes preserving DKIM-protected content and notes that Gmail performs its own authentication checks on forwarded mail. Review the provider’s actual transformation settings rather than assuming that a message which passed upstream stays authenticated everywhere.

Do not disable necessary malware controls merely to preserve a signature. If a security gateway must transform content, involve the gateway and destination operators in a supported design. Authentication and safe content handling need to work together.

Read DMARC alignment at the final destination

The current DMARC specification, RFC 9989, was published in May 2026 and replaces RFC 7489 and RFC 9091. Its central distinction remains important here: passing SPF or DKIM must involve an identifier aligned with the visible author’s domain for DMARC to pass.

A valid aligned DKIM signature can provide that route even if SPF fails after forwarding. A passing SPF check for an unrelated SRS domain cannot, by itself, supply the original author’s alignment. Strict and relaxed alignment rules differ, so compare the actual domains and published policy rather than matching only a familiar brand name.

The receiver still decides how to handle the message using its broader policy. A DMARC pass is not proof that the message is safe or deserves inbox placement. A failure warrants investigating the indirect route; it is not proof that the original sender deliberately spoofed the message.

Use ARC as receiver-evaluated evidence, not a delivery promise

Authenticated Received Chain, RFC 8617, lets participating intermediaries carry signed authentication assessments through a message-handling chain. It can help a final receiver evaluate an indirect flow after message processing has affected authentication.

A valid ARC chain does not establish that every intermediary is trustworthy, make the contents safe or force the receiver to deliver the message. It also does not simply change a failing original-domain DMARC result into an ordinary aligned pass.

Microsoft’s trusted ARC sealer guidance illustrates the operational trust decision at the receiving service. Trust must be configured and evaluated in that service’s context. Do not allowlist an unfamiliar sealer merely because its name appears in a header.

Investigate missing copies without guessing at a rejection

If no final copy arrives, inspect the local copy, spam/quarantine, relevant rules and the forwarding provider’s delivery record. Ask whether the second leg is pending, rejected or accepted. An absent message in one folder does not identify which stage failed.

When there is a delivery-status report, preserve its full diagnostic response and recipient-specific status. Use our bounce interpretation guide to distinguish queued retries from a final failure. Repeatedly resending without knowing the queue state can create duplicates when delayed copies eventually arrive.

Google’s sender guidelines also treat authentication as part of wider delivery requirements and provide rules for forwarding services. Authentication is not a replacement for spam handling, reputation and recipient policy. Do not weaken the original domain’s DMARC policy globally as a first response to one unexplained route.

Choose a simpler route when forwarding is unsuitable

For an important public contact address, evaluate a mailbox that receives the domain’s mail directly, or an alias delivered inside that mailbox service. Fewer external forwarding legs can make delivery ownership and investigation clearer. This is a design option, not a guarantee that every direct mailbox avoids filtering.

If the aim is reading several accounts in one place, a mail client connected to the original accounts may suit the task without re-forwarding every incoming message. Confirm current provider and client capabilities before relying on an import or collection feature.

Replying as the public address is a separate outbound configuration. Verify the authorized sending service and authentication for replies; receiving forwarded mail does not automatically grant the final inbox permission to send as the original domain. Use the custom-domain email checklist for that broader setup.