Why Email Forwarding Breaks DMARC (And What to Do About It)

Someone sets up an email forwarding rule in Microsoft 365. All outgoing notifications from their domain start failing DMARC. SPF and DKIM both pass at the original sending server. The forwarding service is not spoofing anything. So why does DMARC report a failure?

The answer is structural. Forwarding changes the envelope sender while leaving the From header untouched. DMARC alignment checks whether the From header domain matches the authentication identity. A forwarded message can pass SPF and DKIM at the original sending server and still fail DMARC at the destination, because the forwarding service's domain is now the envelope sender, not the original From header domain.

This is not a configuration error. It is a predictable consequence of how email forwarding and DMARC interact.

How DMARC Alignment Works with Forwarded Email

DMARC runs two authentication checks: SPF and DKIM. After both pass, DMARC then checks alignment. Alignment asks one question: does the From header domain match the domain that SPF verified, or the domain that DKIM signed?

SPF alignment checks the MAIL FROM domain (the envelope sender). If a message is forwarded, the forwarding service becomes the envelope sender. The original MAIL FROM domain from the original sender is lost.

DKIM alignment checks the domain in the DKIM-Signature header. If the original sending server signed the message with its own domain, that signature remains valid through the forwarding chain. DKIM may still pass at the destination because the signature was created before forwarding happened.

Here is where it falls apart. The From header still shows the original sender's domain (e.g. notifications@example.com). The forwarding service's server shows up as the source IP in DMARC aggregate reports. SPF passes at the original server but DMARC never sees that result because the envelope sender has been replaced. DKIM may pass. But alignment fails because no authenticated domain matches the From header domain.

What Forwarding Looks Like in DMARC Aggregate Reports

In a DMARC aggregate report, a forwarding problem looks like this:

• Source IP: a server you do not recognize (the forwarding service)
• auth_result: SPF pass, DKIM pass (sometimes one or both)
• alignment: fail

This pattern is distinct from spoofing. In a spoofing case, the source IP belongs to an attacker-controlled server and SPF or DKIM often fail entirely. In a forwarding case, the source IP belongs to a legitimate forwarding service and both SPF and DKIM usually pass at the original server.

If you see high-volume alignment failures from a single source IP you do not recognize, check whether that IP belongs to a known forwarding or mailing service: Google, Microsoft, Mailgun, SendGrid, a mailing list host, or an internal mail relay. If it does and SPF/DKIM pass, you are looking at forwarding, not spoofing. Forwarding is benign. It means someone is routing mail from your domain through a third party without malicious intent.

Common Scenarios That Break DMARC

The most frequent cases:

1. Employee sets up client-side forwarding in Outlook or Gmail to a personal account. The mail relay now sits between your domain and the destination.
2. HR system, CRM, or ticketing tool auto-forwards notification emails to a different address. These tools often relay through their own SMTP infrastructure.
3. Mailing list software that redistributes messages. The list re-envelopes mail, replacing the original sender with the list's own domain. Recipients see the original From header but the envelope is the list's.
4. Domain migration where the old domain forwards to the new domain. The forwarding chain keeps the old From header but uses the new domain as the envelope sender.
5. Cloud email gateways that relay and re-envelope. Some secure email gateways rewrite the envelope for routing purposes, breaking alignment downstream.

How to Fix DMARC Failures Caused by Forwarding

SRS (Sender Rewriting Scheme)

SRS is the standard fix for forwarding chains. When a forwarder re-envelopes a message, SRS rewrites the return path so the original sender domain is preserved in a rewritten form that passes alignment at the final destination. Most modern mailing list software (Mailman3, Sympa) supports SRS. Some forwarders like Gmail and Microsoft 365 do not apply SRS, which is why forwarding from those platforms often breaks DMARC at strict policy domains.

If you control the forwarding service, enable SRS. If you do not, ask the forwarder whether they support SRS.

Subdomain Separation

For automated mail that is likely to be forwarded (notifications, alerts, transactional email), use a dedicated sending subdomain (e.g., notifications@example.com) that has its own SPF and DKIM records and a relaxed DMARC policy (p=none or p=quarantine). This subdomain can forward freely without affecting the main domain's DMARC policy or risking alignment failures that trigger rejections.

Whitelist the Forwarder

If you control both the sending domain and the forwarding path (for example, an internal mail relay between two systems you own), you can add the forwarder IP to an explicit SPF include or configure authentication teardown at the relay. This only works when you own both ends of the forwarding chain.

Block Forwarding at the MTA

If a domain does not need to receive forwarded mail, block forwarding at the MTA level. Some organizations disable client-side forwarding at the Exchange or Postfix level entirely. This prevents the problem from occurring but requires careful communication so internal teams do not lose expected mail.

Use ARC When Forwarding Cannot Be Changed

Authenticated Received Chain (ARC) was designed exactly for this problem. ARC preserves the original authentication results through a forwarding chain, allowing the final recipient to see that the message was authenticated at each step. Many modern email providers use ARC to make forwarding-compatible authentication decisions. If you receive forwarded mail and cannot change the forwarding behavior, ARC is the right tool.

How DMARCFlow Classifies Forwarding vs Spoofing Automatically

Forwarding patterns are easy to misread as spoofing in raw DMARC aggregate reports. The tell is in the auth_result fields: both SPF and DKIM pass, but alignment fails. Identifying that pattern manually across thousands of records is slow and error-prone. Most teams see alignment failures and treat them as incidents.

This is where DMARCFlow fits into the reasoning naturally. DMARCFlow parses aggregate reports and surfaces the source IP, auth_result, and alignment fields together, then cross-references the source IP against known forwarding and mailing service ranges. The forwarding versus spoofing distinction becomes an automated classification, not a manual investigation. Teams running DMARCFlow see a flag that says "this looks like forwarding from a known service" alongside the raw data, rather than a spike in alignment failures with no context.

That classification speed matters because the response to forwarding is a configuration decision, not an incident response.

Quick Diagnostic Checklist

Run this when you see alignment failures in your DMARC reports:

• Identify the source IP. Look it up in a BGP or whois database. Does it belong to a known forwarding or mailing service?
• Check auth_results. Do SPF and DKIM both pass? If yes and alignment fails, forwarding is the likely cause.
• Check volume. Is one IP responsible for most of the failures? Spoofing usually involves many source IPs. Forwarding usually involves one or two.
• Contact the forwarder. Ask whether they support SRS. If they do not, the forwarding will continue breaking DMARC at strict policy domains.
• If the forwarding cannot be changed, move affected sending subdomains to a relaxed DMARC policy to prevent unnecessary rejections.

The answer is not to loosen your DMARC policy and hope for the best. The answer is to understand what is actually happening in your reports, then make a targeted fix.

FAQ

Does SPF pass when email is forwarded?

SPF validation runs against the connecting server's IP address at the time of delivery. When a forwarding service connects to the final destination mail server, it is the forwarder's IP that is evaluated, not the original sender's. The forwarder's SPF record may pass (if they have one configured for their own domain), or it may fail, depending on their infrastructure. Either way, the domain being validated is the forwarder's, not the original From header domain. DMARC then checks whether that SPF-authenticated domain matches the From header. It does not. That is why alignment fails.

The original sender's SPF result is not visible in the DMARC aggregate report from the final destination. Only the forwarder's SPF result appears, because the forwarder is the last-hop connector.

Does DKIM survive forwarding?

DKIM usually survives forwarding because the DKIM signature is applied by the original sending server before forwarding happens. The signature is tied to the header content, not the envelope. However, if the forwarding service modifies headers or body, DKIM validation can fail. In most clean forwarding scenarios, DKIM passes and alignment fails.

Can you forward email without breaking DMARC?

Yes, if the forwarder supports SRS (Sender Rewriting Scheme). SRS rewrites the envelope sender in a way that preserves alignment at the destination. If SRS is not available, the alternative is to use a dedicated sending subdomain with a relaxed DMARC policy, or to block forwarding at the MTA if it is not needed.

Most consumer-grade forwarding services (Gmail, Outlook.com, iCloud) do not apply SRS. This is why forwarding from a personal Gmail account to an external address almost always breaks DMARC at strict policy domains. Corporate mail relays and modern mailing list software are more likely to support SRS, but the support is not universal. When evaluating a forwarder, ask specifically whether they implement SRS before relying on it as a fix.