Introduction
Forwarded mail fails DMARC because forwarding breaks SPF and sometimes breaks DKIM. The forwarder sends from its own IP address, which the original domain's SPF record does not authorise, so SPF fails or passes only for the forwarder's domain. DMARC then depends on aligned DKIM, which survives plain forwarding but breaks when a mailing list or gateway modifies the message.
This is the practical troubleshooting answer for forwarded mail: what breaks, which forwarding setups behave how, how it shows up in aggregate reports, and what an MSP should actually change. For the protocol background, see the DMARC guide. For the closely related case where SPF passes for the wrong domain, see why DMARC fails when SPF passes.
Key takeaways
- SPF almost never survives forwarding. Even when the forwarder rewrites the envelope sender (SRS), SPF then passes for the forwarder's domain, which does not align with the original From domain.
- Aligned DKIM is what keeps forwarded mail passing DMARC. It survives as long as nobody changes the signed headers or body.
- Mailing lists, subject tags, footers and content-rewriting gateways break DKIM. That is where forwarded mail genuinely fails, and where ARC and From rewriting come in.
- RFC 9989, Section 7.4, says domains that publish
p=rejectmust not rely solely on SPF and must apply valid DKIM signatures. - In aggregate reports, forwarding looks like DMARC results from IP addresses the client never authorised, often with
dkim=passand an unaligned or failing SPF result.
Why does SPF break when email is forwarded?
SPF breaks because it authorises IP addresses, not messages. When a forwarder relays a message, the final receiver sees the forwarder's IP address. If the envelope sender still names the original domain, SPF fails; if the forwarder rewrites it, SPF passes for the forwarder's domain instead. Either way, there is no aligned SPF pass.
RFC 7208, the SPF specification, says this directly. Section 10.3 describes mediators (such as mailing lists and forwarders) as systems that take delivery of a message and then post a new submission. Where the mediator keeps the original MAIL FROM address, "the SPF evaluation will fail unless mitigations such as those described in Appendix D are used." Section 10.2 also warns that SPF can return fail for legitimate mail that has traversed a mail alias.
RFC 9989, the current DMARC standard, makes the same point in Section 7.4: relayed mail "will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA", while "DKIM signatures will generally remain valid in these relay situations."
What does the Sender Rewriting Scheme (SRS) fix, and what does it not?
SRS rewrites the envelope sender to an address in the forwarder's own domain, so SPF passes at the next hop and bounces return to the forwarder. It fixes SPF, not DMARC. The rewritten domain belongs to the forwarder, so it cannot align with the original From domain.
Microsoft's SRS documentation is explicit: "SRS rewriting doesn't resolve the issue of forwarded messages not passing DMARC checks." It adds that a forwarded message passes DMARC reliably only when it is DKIM-signed with the From domain and the signature stays intact to the final destination. A Microsoft 365 forwarded message looks like this at the final receiver:
Return-Path: <john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com>
From: Bob <bob@fabrikam.com>
Authentication-Results: mx.final-receiver.example;
spf=pass smtp.mailfrom=contoso.com;
dkim=pass header.d=fabrikam.com;
dmarc=pass header.from=fabrikam.comThe SRS address format is Microsoft's own example. SPF passed for contoso.com (the forwarder), which is irrelevant to DMARC for fabrikam.com. DMARC passed only because fabrikam.com signed with DKIM and the forwarder left the message intact.
Why does DKIM usually survive forwarding?
DKIM survives because the signature travels inside the message and is checked against the signer's public key in DNS, regardless of which server delivers it. As long as the forwarder does not change the signed headers or body, the signature still validates and, if d= aligns with the From domain, DMARC passes.
RFC 7960, the informational RFC on DMARC and indirect mail flows, describes the same split: an alias may send mail along a path the originating domain's SPF record does not cover, but DKIM can survive if the alias keeps the content and makes no significant header changes.
What breaks DKIM on forwarded mail?
Anything that changes signed content breaks DKIM. The usual culprits are intermediaries that edit messages on purpose: mailing lists, disclaimer tools and security gateways. RFC 7960 (Section 3.2.3.1) describes the typical mailing list changes, and Google's forwarding guidance adds others.
- Subject tags, such as
[members]prepended to the Subject header. - Footers with unsubscribe links or legal disclaimers appended to the body.
- Link rewriting and attachment handling by security gateways and filtering services.
- Re-encoding of the body or changes to MIME boundaries. Google's forwarding best practices list these, plus Subject changes, as things that break DKIM.
- Header changes to fields such as To, Cc, Date or Message-ID, which are commonly covered by the signature.
When DKIM breaks and SPF has already gone, nothing aligned is left, and DMARC fails for a message that was legitimate when it left the sender.
How do different forwarding setups affect DMARC?
The outcome depends on two questions: does the forwarder modify the message, and does it keep the original From address? Plain forwarding that keeps the message intact usually passes on DKIM. Mailing lists and modifying gateways usually fail unless they rewrite From or the receiver trusts their ARC seal.
| Forwarding setup | SPF at final receiver | DKIM | Typical DMARC result for the original domain |
|---|---|---|---|
| Microsoft 365 mailbox (SMTP) forwarding or inbox rule redirect | Rewritten by SRS, passes for the forwarder's domain (unaligned) | Survives if the message is unchanged | Pass if the original sender signs aligned DKIM |
| Outlook inbox rule "forward" | Evaluated for the forwarding user's domain | New message from the forwarding user | The original domain is no longer in From; the forwarding user's domain is evaluated |
| Server or alias forwarding without SRS | Fails (forwarder IP not authorised) | Survives if unchanged | Pass on aligned DKIM, otherwise fail |
| Forwarding into Gmail from another provider | Often fails, per Google | Survives if unchanged | Gmail runs its own checks on forwarded mail |
| Mailing lists and group lists that add tags or footers | Passes only for the list's domain, if at all | Usually broken | Fail, unless the list rewrites From or the receiver trusts its ARC seal |
| Security gateway that rewrites content before the mailbox | Evaluates the gateway's IP | Often broken | Fail at the mailbox platform unless ARC trust or connector settings account for the gateway |
How do Microsoft 365 forwarding and redirect differ?
They differ in whose message it becomes. Microsoft's support article on forwarding rules says forwarded messages "will appear to be forwarded from you", while redirected messages "will appear to come from the original sender." Redirected and SMTP-forwarded mail keeps the original From, so the original domain's DMARC policy applies.
Microsoft lists the methods SRS covers: mailbox (SMTP) forwarding, inbox rule redirection, mail flow rule redirection, groups with external members, and mail contact and mail user forwarding. Two operational details matter for MSPs:
- External auto-forwarding may be blocked outright. The outbound spam policy controls automatic forwarding from inbox rules and SMTP forwarding. The default is "Automatic – System-controlled", which Microsoft says can behave as Off or On depending on the tenant, so it recommends setting it explicitly. Blocked messages bounce with
5.7.520 Access denied, Your organization does not allow external forwarding(Microsoft Learn). - Mail forwarded to on-premises servers is not rewritten by SRS, which can cause SPF failures in hybrid routing unless sender rewriting is enabled on the outbound connector.
What does Google say about forwarding into Gmail?
Google's best practices for forwarding email to Gmail state that forwarded messages "often fail SPF authentication" and that "Gmail does its own authentication check on forwarded messages." It also says Gmail "doesn't automatically authenticate forwarded messages that previously passed authentication." Google's advice to forwarders: change the envelope sender to the forwarding domain, keep DKIM-signed content unchanged, and filter spam before forwarding it.
That last point matters for client reputation. Google warns that if forwarded messages are marked as spam, future messages from the forwarding domain are more likely to be treated as spam too.
Why are mailing lists and group lists the hardest case?
Lists modify messages and redistribute them from their own infrastructure, so they break both SPF and DKIM. RFC 9989 Section 7.4 notes that list software has widely adopted From rewriting as a workaround: some lists use the list's own address, others use per-address modifications intended to be reversible. The message then passes DMARC for the list's domain rather than the author's.
RFC 9989 also says that "domains that host users who might post messages to mailing lists SHOULD NOT publish" p=reject. For a client whose staff post to external lists, that is a reason to check list traffic in reports before advancing policy, not a ban on enforcement. Group and list services vary in how they handle this, so test with a real message and read the headers rather than assuming.
Where does ARC fit?
ARC (Authenticated Received Chain, RFC 8617, Experimental) lets an intermediary record the SPF, DKIM and DMARC results it saw before it changed the message, and seal them. A receiver that trusts that sealer can use the earlier results to override a DMARC failure. It helps only when the intermediary seals and the receiver trusts it.
RFC 9989 Section 7.4 names ARC as the prominent proposal for avoiding From rewriting, while noting that no method had achieved widespread adoption at publication. In Microsoft 365 the practical step is configuring trusted ARC sealers for intermediaries such as a third-party gateway in front of the tenant. Microsoft says to add the vendor's signing domain from the d= value of its ARC-Seal header, not your own domain, and to trust only vendors you actively use, because each sealer widens the attack surface.
When it works, the receiving Microsoft 365 tenant records compauth=pass reason=130 (ARC override) in Authentication-Results. For the full mechanism, including the cv= chain validation tag, see ARC explained. For the gateway scenario, see why DMARC fails with a gateway in front of Microsoft 365.
How does forwarding show up in DMARC aggregate reports?
Forwarding appears as DMARC records from source IPs the client never authorised, usually belonging to mailbox providers, list servers or gateways. The tell is the combination: SPF fails or passes for a foreign domain, while DKIM passes for the client's own domain. If DKIM also fails, look for list or gateway modification.
RFC 9990, the aggregate reporting standard, gives you the fields to separate forwarding from spoofing:
<auth_results><spf><domain>names the domain SPF was checked for. A forwarder's domain here, with your client's domain in<header_from>, points to SRS forwarding.<auth_results><dkim>shows the signing domain and result. A pass for the client's domain from an unknown IP is the classic forwarding signature.<identifiers><envelope_from>is optional, but when present shows the MAIL FROM domain used for SPF.<policy_evaluated><reason><type>records why the receiver deviated from the published policy. RFC 9990 Section 3.1.6 definestrusted_forwarder(failure anticipated for a known forwarder),mailing_list(local heuristics detected a list),local_policy,policy_test_modeandother.
A trimmed forwarded record:
<record>
<row>
<source_ip>198.51.100.40</source_ip>
<count>12</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>forwarder.example</domain>
<scope>mfrom</scope>
<result>pass</result>
</spf>
</auth_results>
</record>This passes DMARC on aligned DKIM, so no action is needed. The same record with <dkim>fail</dkim> and a <reason><type>mailing_list</type></reason> tells you a list broke the signature and the receiver chose not to apply the policy. RFC 9989 Section 5.4 asks receivers to report such deviations this way, but reporting varies by receiver, as covered in why DMARC reports are not always perfect. Field-by-field detail is in DMARC aggregate reports explained.
What should MSPs tell clients about forwarded mail?
Tell clients that forwarding failures are usually caused by the recipient's mail path, not by their DNS, and that the fix on their side is aligned DKIM on every sending service. Then set expectations: a small residual of list and gateway failures is normal and is not a reason to stay at p=none forever.
A practical routine across a client portfolio:
- Confirm aligned DKIM on every sender. Microsoft 365, Google Workspace and each third-party platform should sign with
d=set to the client's domain. RFC 9989 Section 7.4 makes this a requirement forp=rejectdomains, not a nice-to-have. - Separate forwarding from spoofing in reports. Group unknown sources by the
<auth_results>domains. DKIM pass for the client's domain means forwarding of real mail; DKIM fail with no plausible intermediary means investigate. - Check the client's own forwarding. Review external forwarding settings in the client's tenant. Prefer redirect or SMTP forwarding with SRS over ad hoc rules, and set the outbound spam policy explicitly.
- Handle gateways at the receiving side. If the client runs a gateway in front of Microsoft 365, configure trusted ARC sealers or the connector settings described in Enhanced Filtering for Connectors.
- Watch list traffic before
p=reject. RFC 9989 Section 7.4 suggests using aggregate data first and stepping fromp=nonetop=quarantinebeforep=reject. Look formailing_listoverride reasons and list server IPs during that period. - Explain receiver discretion. RFC 9989 says receivers "MUST NOT reject incoming messages solely on the basis of a "p=reject" policy" and should use other knowledge and analysis. Clients may see a reject disposition on mail that was still delivered; see DMARC reports say reject but the email was delivered.
The enforcement steps themselves are covered in p=reject still requires care after RFC 9989.
DMARC AI is a multi-tenant platform for MSPs that processes aggregate reports across client domains, so grouping forwarding sources across many clients is the workflow it supports; see DMARC for MSPs.
FAQ
Does forwarding always break DMARC?
No. Forwarding almost always breaks SPF alignment, but DMARC needs only one aligned pass. If the original sender signs with DKIM using its own domain and the forwarder does not modify the message, DKIM still validates and DMARC passes. Failures happen when the forwarder also changes the content, as lists and some gateways do.
Should I add a forwarder's IP addresses to my SPF record?
No. You do not control which forwarders your recipients use, and adding their ranges authorises their infrastructure to send as your domain. If the forwarder uses SRS, SPF is checked against its domain anyway. Make sure your mail carries aligned DKIM instead, which is the fix RFC 9989 and Microsoft both point to.
Can SRS make forwarded mail pass DMARC?
Not on its own. SRS rewrites the envelope sender to the forwarder's domain so that SPF passes at the next hop and bounces go somewhere sensible. That domain cannot align with the original From domain, so DMARC still depends on aligned DKIM surviving the forward. Microsoft states this in its SRS documentation.
Should a client avoid p=reject if staff use mailing lists?
Not automatically. RFC 9989 says domains whose users post to mailing lists should not publish p=reject, because list modifications break DKIM. Check aggregate reports for list traffic first. If staff rarely post to external lists, p=reject with aligned DKIM is usually workable; if list use is heavy, discuss the trade-off with the client.
Why do forwarded messages appear under my client's domain in reports from unknown IPs?
Aggregate reports are sent by the final receiver, which sees the forwarder's server as the source. So a message your client sent to someone who forwards it elsewhere shows up with the forwarder's IP. If DKIM passes for your client's domain on those rows, it is real mail being forwarded, not spoofing.