Why Email Forwarding Breaks Authentication (And How to Fix It)

The Problem: Your Forwarded Email Gets Rejected

You have an email address through your university, alumni association, professional organization, or hosting provider — something like you@alumni.myuniversity.edu or you@acm.org. You do not run a mail server for that address. Instead, the organization forwards your email to your real mailbox — Gmail, Outlook, or wherever you actually read mail.

This worked fine for years. Then emails started bouncing. Senders get error messages like 550 5.7.1 DMARC policy reject or 554 5.7.1 Message rejected due to DMARC policy. The email was legitimate. The sender is real. But the forwarded message was rejected at your destination mailbox.

The cause: email authentication protocols — SPF, DKIM, and DMARC — were not designed for forwarding. When your alumni association or professional organization forwards email to your real mailbox, the authentication chain can break. This guide explains exactly how, why, and what everyone involved can do about it.

A Quick Refresher: How Email Authentication Works

Three protocols work together to verify that an email actually comes from the domain it claims. If you are already familiar with SPF, DKIM, and DMARC, skip to the next section.

SPF (Sender Policy Framework, RFC 7208) checks whether the server sending the email is authorized by the sending domain. The domain owner publishes a DNS record listing which IP addresses and servers can send on their behalf. When a receiving server gets an email, it checks whether the sending server's IP is in that list.

SPF checks the domain in the envelope sender (the Return-Path header), not the From: address you see in your email client. This distinction matters enormously for forwarding.

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to the email. The sending server signs parts of the message (headers and body) with a private key. The corresponding public key is published in DNS. The receiving server retrieves the public key and verifies the signature. If the message was altered in transit, the signature fails.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ties SPF and DKIM together. It checks that at least one of them not only passes, but passes in alignment with the From: domain — the address the recipient actually sees. DMARC also lets the domain owner publish a policy telling receivers what to do with messages that fail: none (monitor), quarantine (spam folder), or reject (bounce it).

For a deeper explanation of all three protocols, see the Complete Guide to Email Authentication.

What Happens When Email Is Forwarded

Here is the normal flow when someone sends you an email directly:

Sender's server ──→ Your mailbox
   SPF: ✓ (sender's IP is authorized)
   DKIM: ✓ (signature valid)
   DMARC: ✓ (SPF or DKIM aligned with From: domain)

Now here is what happens with forwarding — say you have you@acm.org that forwards to you@gmail.com:

Sender's server ──→ ACM's server ──→ Gmail
   SPF at Gmail: ✗ (ACM's IP, not sender's IP)
   DKIM at Gmail: ? (depends — see below)
   DMARC at Gmail: ? (depends on DKIM)

Gmail receives the message from ACM's mail server, not from the original sender's server. This changes everything about how authentication is evaluated.

SPF Breaks on Every Forward

SPF always breaks when email is forwarded. Always.

SPF checks whether the IP address of the server delivering the message is authorized by the domain in the envelope sender. When ACM's server forwards the message to Gmail, the delivering IP address is ACM's server — not the original sender's server. The original sender's SPF record does not authorize ACM's IP. SPF fails.

This is not a misconfiguration. It is a fundamental limitation of SPF's design. SPF validates the last hop, not the original sender.

SRS: The SPF Fix for Forwarding

To solve the SPF problem, forwarding servers use SRS (Sender Rewriting Scheme, RFC 7208 Section 10.3, formalized in draft-ietf-sstpc-srs). SRS rewrites the envelope sender to a domain that the forwarding server controls. Responsible forwarding and email security services — like MailRoute — handle SRS automatically. You do not need to configure anything. The service rewrites the envelope sender on your behalf to protect SPF.

Before SRS:

Return-Path: <alice@example.com>
From: alice@example.com

After SRS rewriting by the forwarding service:

Return-Path: <SRS0=HHH=TT=example.com=alice@srs.mailroute.net>
From: alice@example.com

The Return-Path (envelope sender) has been rewritten to a domain the forwarding service controls — srs.mailroute.net in this example. The From: header that you see in your inbox is untouched.

Now SPF works. Gmail checks whether the forwarding server's IP is authorized to send for the rewritten domain (it is), and SPF passes. The From: header is untouched — you still see the email is from Alice.

SRS solves the SPF problem. But it creates a new one.

The Alignment Problem SRS Creates

DMARC requires alignment — the domain authenticated by SPF or DKIM must match the domain in the From: header. After SRS rewriting:

• SPF authenticates: acm.org (the rewritten Return-Path)
• From: header says: example.com (the original sender)

These domains do not match. SPF passes, but SPF alignment fails. SPF can no longer help the message pass DMARC.

This is not a bug in SRS. SRS was designed before DMARC existed. It solves SPF validation (which prevents bounces from being rejected), but it cannot solve SPF alignment (which DMARC requires). After SRS rewrites the envelope sender, DKIM is the only authentication mechanism that can provide alignment for DMARC.

DKIM Becomes the Only Hope

With SPF alignment off the table for forwarded mail, DMARC depends entirely on DKIM. For the forwarded message to pass DMARC:

1. The original sender must have signed the message with DKIM
2. The DKIM signature must be in alignment with the From: domain
3. The signature must survive the forwarding process intact

All three conditions must be met. If any one fails, DMARC fails and the message is handled according to the sender's DMARC policy — which increasingly means rejection.

Where DKIM Fails in the Forwarding Chain

DKIM can fail in forwarded email for three distinct reasons. Understanding which one is happening determines what can be fixed and by whom.

1. The Original Sender Did Not Sign with DKIM

Some sending servers do not sign outgoing messages with DKIM at all. Without a signature, there is nothing for the receiving server to verify. DKIM fails, SPF alignment already failed due to SRS, and DMARC fails.

This is the sender's problem to fix. Every sending system should sign outgoing email with DKIM. With the bulk sender requirements from Google, Yahoo, and Microsoft now in effect, unsigned email faces increasing rejection regardless of forwarding.

Who can fix it: The sender or the sender's email administrator. They need to enable DKIM signing and publish the public key in DNS. See the DKIM section of our authentication guide for setup instructions.

2. DKIM Is Signed, But the Domain Does Not Align

DKIM signatures include a d= tag that specifies the signing domain. DMARC checks whether this domain aligns with the From: domain. The alignment can be relaxed (organizational domain match) or strict (exact domain match), depending on the sender's DMARC policy.

Example of misaligned DKIM:

From: alice@example.com
DKIM-Signature: ... d=mailservice.example.net ...

The DKIM signature is valid, signed by mailservice.example.net. But the From: address is example.com. These are different organizational domains. Even with relaxed alignment, this does not match. DKIM passes, but DKIM alignment fails.

This happens when a sender's email provider signs with their own domain instead of the customer's domain. The sender needs to configure custom DKIM signing so that the d= value in the signature matches their From: domain.

Who can fix it: The sender's email administrator. They need to set up DKIM signing with their own domain (e.g., d=example.com) rather than the email service's default domain. Most email services support this — it requires publishing a DKIM key in the sender's DNS and configuring the service to use it.

3. The Forwarding Server Modified the Message

DKIM signatures cover specific parts of the message. If the forwarding server changes any of those parts — adding a footer, modifying the subject line, altering the body, rewriting URLs — the signature becomes invalid.

Common modifications that break DKIM:

• Adding footers or disclaimers (changes the body hash)
• Prepending [ListName] to the subject line (changes the signed Subject: header)
• Rewriting URLs for click tracking or security scanning (changes the body hash)
• Stripping or adding headers that were included in the signature
• Character encoding conversions (changes byte-level content)

When the DKIM signature breaks, the only authentication that could have provided DMARC alignment is gone. SPF alignment already failed due to SRS. DMARC fails.

Responsible forwarding services avoid this entirely. MailRoute, for example, processes email for spam and virus filtering without modifying message bodies or signed headers — DKIM signatures pass through intact. When evaluating a forwarding or email security service, DKIM signature preservation should be a baseline requirement, not a feature.

Who can fix it: The operator of the forwarding server. The fix is to forward messages without modifying them — or at minimum, without modifying the parts covered by the DKIM signature.

The Complete Picture

Here is how all the pieces interact for forwarded email:

Only the last row passes DMARC. The forwarded message needs SRS (for SPF to pass and avoid bounces to the wrong place), an aligned DKIM signature from the original sender, and a forwarding server that does not modify the signed content.

Real-World Scenarios

Alumni and Association Forwarding

Organizations like universities, ACM, IEEE, and professional associations offer lifetime email addresses (you@alumni.university.edu, you@acm.org). These addresses typically forward to your personal mailbox.

When someone sends email to you@acm.org:

1. The sender's server delivers to ACM's mail server
2. ACM's server rewrites the envelope sender (SRS) and forwards to your Gmail/Outlook
3. Gmail/Outlook evaluates the forwarded message

If the original sender did not sign with aligned DKIM — or if ACM's forwarding server modified the message — the email is rejected. The sender gets a bounce. You never see the message.

This is especially problematic because the sender and recipient often have no idea what happened. The sender sees a bounce mentioning DMARC. The recipient does not know they missed an email. The forwarding organization may not realize their system is causing authentication failures.

Mailing Lists

Mailing lists are a variation of the same problem, with an additional complication: most list software modifies the message. Adding [list-name] to the subject line, appending list footers, wrapping the body in a MIME container — any of these modifications break the original sender's DKIM signature.

Mailing list software has largely moved to wrapping the original message (preserving the DKIM signature) or re-signing with the list's domain and rewriting the From: header to the list address. But older or misconfigured list software still modifies messages in ways that break DKIM without providing a replacement signature.

Email Security Gateways

Services like MailRoute, Proofpoint, Mimecast, and Barracuda sit between the internet and your mailbox, filtering spam and malware. Some configurations involve forwarding — the MX records point to the filtering service, which then delivers to the actual mail server. If the gateway modifies the message during processing, DKIM signatures can break.

Well-configured gateways preserve DKIM signatures by avoiding body modifications. MailRoute, for example, focuses on header-based filtering and routing without modifying message bodies, preserving DKIM integrity through the delivery chain.

ARC: The Protocol Designed for Forwarding

ARC (Authenticated Received Chain, RFC 8617) was designed specifically to address authentication failures caused by forwarding. ARC lets each server in the forwarding chain record what the authentication results were when it received the message, and sign that record.

When a forwarding server receives a message:

1. It records the SPF, DKIM, and DMARC results as it saw them (the ARC-Authentication-Results)
2. It signs a snapshot of the message at that point (the ARC-Message-Signature)
3. It signs a seal covering both records (the ARC-Seal)

The receiving server can then look at the ARC chain and see: "The message passed DMARC when it arrived at the forwarding server. The forwarding server has a good reputation. I will accept it even though DMARC fails now."

ARC is a trust-based override. The receiving server must trust the forwarding server's ARC signature. Major providers — Gmail, Microsoft, Yahoo — evaluate ARC chains from known forwarders and can use them to override DMARC failure. But ARC is not universal, and not all forwarding servers implement it.

ARC does not change the authentication math. SPF alignment still fails after SRS. DKIM still breaks if the message was modified. What ARC does is preserve the evidence of what happened before the forward, so the final receiver can make an informed decision.

What You Can Do

The answer depends on your role in the forwarding chain.

If You Are the Recipient (You Have a Forwarded Address)

You cannot fix authentication on messages other people send to you. But you can:

• Give senders your direct address. For important contacts, provide your Gmail, Outlook, or direct mailbox address instead of your forwarded address. This avoids the forwarding chain entirely.
• Check your spam folder. Some receivers quarantine rather than reject DMARC failures. Messages may land in spam instead of being bounced.
• Contact your forwarding provider. Ask whether they implement SRS and ARC. If they do not, your forwarded address will increasingly have delivery problems as more domains adopt p=reject.

If You Manage the Forwarding Service

If you operate the server that forwards email (university IT, association infrastructure, hosting provider):

• Implement SRS. Rewrite the envelope sender so that SPF passes for your domain. This prevents bounces from being misdelivered and is a prerequisite for everything else. All major MTAs support SRS — Postfix (postsrsd), Exim (built-in), Sendmail (milter-based).
• Do not modify message bodies or signed headers. Preserve the original DKIM signature. Avoid adding footers, rewriting subjects, or altering content. If you must add content, add it as a separate MIME part if possible.
• Implement ARC. Sign an ARC chain so that receiving servers can see the authentication results before forwarding. This gives Gmail, Microsoft, and Yahoo the signal they need to accept the message despite DMARC failure.
• Publish SPF and DKIM for your own domain. Your SRS-rewritten envelope sender uses your domain. Make sure your own authentication is solid.

If You Are the Sender (Your Email Gets Bounced After Forwarding)

If you send email that gets rejected when recipients forward it:

• Sign all outgoing email with DKIM. Every message from your domain should have a DKIM signature. This is the single most important thing you can do for forwarding compatibility.
• Align your DKIM signature with your From: domain. The d= value in your DKIM signature must match your From: domain (at least at the organizational domain level for relaxed alignment). If your email service signs with their own domain, configure custom DKIM.
• Verify with the mxio DKIM Checker. Confirm your DKIM records are published and valid.
• Consider your DMARC policy carefully. p=reject protects your domain from spoofing, but it also means forwarded messages that fail alignment will be rejected. This is the correct tradeoff for most domains — the protection from spoofing outweighs the forwarding friction. But understand the impact.
• Use the mxio Header Analyzer to examine bounce messages and see exactly where authentication failed.

The Bottom Line

Email forwarding and email authentication are in tension by design. SPF validates the delivering server, not the original sender — so forwarding always breaks SPF. SRS fixes SPF validation but breaks SPF alignment. That leaves DKIM as the only mechanism that can carry authentication through a forwarding chain.

For forwarded email to survive DMARC:

1. The sender must sign with DKIM, aligned to their From: domain
2. The forwarding server must not modify the signed content
3. Ideally, the forwarding server implements ARC as a safety net

As more domains adopt p=reject and receiving servers enforce DMARC more strictly, forwarded email that lacks aligned DKIM will increasingly be rejected. The fix is not to weaken DMARC — it is to strengthen DKIM signing across the ecosystem and implement ARC at forwarding servers.

If you are troubleshooting a specific forwarded message, use the mxio Header Analyzer to inspect the full authentication chain. It shows you exactly which checks passed, which failed, and where the alignment broke down.