Forward Email to Another Address Without Breaking DMARC

You set up a forwarding rule. Send a test. It works. You move on.

Then a client says they never got your reply. No bounce. No NDR. The message just stopped existing somewhere between servers.

Here's what happened: when you forward email to another address, your server opens a fresh SMTP connection to the destination. That destination runs SPF against your IP — not the original sender's. Your IP isn't on their SPF record. SPF fails. If DKIM also breaks because something touched the message body in transit, DMARC fails too. With p=reject, the message is silently discarded. No bounce. No trace.

This isn't a config typo. It's a structural collision between how forwarding works and how modern authentication works. The complete email forwarding setup and fix guide covers every scenario end to end. This article focuses on the authentication layer: the failure modes, the error codes, and what actually fixes them.

Why Authentication Fails When You Forward Email to Another Address

When you forward email to another address, the destination's receiving MTA runs authentication checks against the forwarding server's IP — not the original sender's. Every email has two distinct identity layers, and forwarding desynchronizes them. SPF validates the Envelope; DMARC checks alignment between both layers and rejects the message if both fail.

The chain: Server A sends to your forwarding server (B), which opens a new TCP connection to the destination (C). C sees B's IP. SPF asks the original sender's DNS: "Is this IP authorized to send for your domain?" The original sender never listed B. SPF fails — every time, on every forward, with no exceptions.

DMARC only needs one of SPF or DKIM to pass, so DKIM can rescue a forwarded message — but only if the body arrives completely unmodified. If anything in the forwarding path touches the content, DKIM's hash breaks. Both checks fail. With p=reject, the message is gone.

Three Failure Modes to Expect

When you attempt to forward email to another address without server-side rewriting, failures follow three distinct patterns. Each has a specific error code, a different cause, and a different fix. Knowing which pattern you're dealing with cuts debugging time from hours to minutes.

1. Microsoft 365 Outbound Block (550 5.7.520)

Microsoft 365 treats external forwarding as a data exfiltration vector by default. Configure a mailbox rule to forward email to another address outside the tenant, and Exchange Online blocks it before the message leaves Microsoft's infrastructure.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

This is a policy block, not a protocol error. The fix is administrative:

1. Open the Microsoft 365 Defender Portal.
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Edit the Outbound spam filter policy.
4. Set Automatic forwarding to On — Forwarding is enabled.

Enabling this globally increases your exposure if any account is compromised. Apply MFA to all accounts, enable this intentionally, and monitor outbound mail volume after the change.

2. The DMARC Double Failure

The silent kill shot. When you forward email to another address, SPF already fails because the IP changed. DKIM can still save the message — but only if the body arrives completely untouched. If anything in the forwarding path modifies the content, the DKIM hash breaks and both checks fail simultaneously.

The most common culprits that break DKIM in transit:

• Antivirus software appending a footer: "Scanned by [Product Name]"
• Subject-line tags from the destination gateway: [EXT] or [EXTERNAL]
• "External Sender" warning banners injected into the HTML body
• Mailing list software rewriting headers or appending unsubscribe footers

When both SPF and DKIM fail, DMARC (RFC 7489) returns FAIL. With p=reject, the message is discarded with no bounce to the original sender. You never know it happened — which is what makes this the most dangerous failure mode.

3. Routing Loops (554 5.4.14)

Loops happen when two servers keep handing a message back and forth until the hop count limit is reached. They're loud — they generate NDRs immediately. But they can still lock up mail queues and trigger cascading delivery delays.

Common triggers:

• User A forwards to User B; User B has a rule that forwards back to User A.
• User A forwards to User B, who has an active Out-of-Office. The auto-reply hits A's forwarder, which sends it to B again. Repeat.
• A catch-all address forwards to a mailbox that then forwards to a non-existent address at the same domain.

554 5.4.14 Hop count exceeded - possible mail loop

Always verify the full routing chain — including auto-replies and catch-all destinations — before you forward email to another address in a production environment.

The Fix: SRS and ARC

To forward email to another address without deliverability failures, you need two server-side mechanisms working together. SRS rewrites the Envelope Sender so SPF passes. ARC lets trusted forwarders vouch for the authentication chain so receivers can override DMARC failures on the receiving end. Neither works as a client-side rule — both must be implemented at the mail server level.

SRS: Sender Rewriting Scheme

SRS rewrites the Envelope Sender (P1) to a domain you control. Instead of claiming the email is from alice@bank.com — a domain you're not authorized to send for — your forwarding server rewrites the Return-Path to:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF now checks your domain. Your sending IP is on your SPF record. SPF passes.

The hash and timestamp handle bounce routing: if delivery fails, the NDR comes back to your SRS address, your server decodes it, and routes the bounce to the real Alice — without making your server an open relay. These addresses are time-limited and single-purpose.

ARC: Authenticated Received Chain

SRS fixes SPF but leaves the alignment gap between the Envelope and the Header open. ARC (RFC 8617) closes it. Your forwarding server adds a cryptographic seal to the message attesting: "I verified the authentication state when I received this message, and I'm vouching for it."

Google and Microsoft honor ARC seals from forwarders with good sending reputation. If your infrastructure has a clean IP history and passes ARC validation, Gmail and Outlook deliver the message even when raw SPF alignment fails.

Think of ARC as a chain of custody record. Each forwarding hop adds a signed attestation of the authentication state it observed. Downstream receivers can verify the full chain — and choose to trust it, even when standard SPF/DKIM alignment breaks at the envelope level.

If you forward email to another address through Gmail or Microsoft 365 infrastructure, those providers already add ARC seals automatically. The problem is when your forwarding runs through a server that doesn't implement ARC — your message arrives with no vouching record and raw DMARC failure.

Implementation: Two Paths

If you need to forward email to another address without silent delivery failures, you have two options. One means managing your own MTA. The other means using infrastructure where SRS and ARC are already handled at the platform level — and you're not holding the keys.

Option A: Postfix + postsrsd (Self-Managed)

On a Linux server running Postfix, install postsrsd and configure Postfix to route envelope rewriting through its daemon ports:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

What you take on with this approach:

• SRS secret key management. If keys leak, attackers can use your domain to relay bounce messages.
• Explicit exclusion of your local domains from rewriting — skip this and internal mail breaks.
• Your sending IP's reputation determines deliverability to Gmail and Outlook.
• ARC signing requires separate configuration beyond postsrsd.

It works. It's also ongoing maintenance for a problem that's solved at the infrastructure level by purpose-built mail platforms.

Option B: TrekMail (Managed Forwarding)

When you forward email to another address through TrekMail, SRS rewriting happens automatically at the edge — no config files, no key rotation. ARC signing is included on paid plans. Your forwarded mail routes through managed SMTP relays with established reputation rather than your own IP history.

For solo founders: if you're paying $6/month per mailbox just to forward info@yourdomain.com to your personal inbox, that's a per-user tax for something that should be infrastructure-level. TrekMail's Starter plan is $3.50/month flat for up to 50 domains — no per-user fees. See how mailbox forwarding works in TrekMail.

For agencies managing DNS across multiple clients: the SPF debugging cost, when a forwarded domain breaks, eats your margins fast. TrekMail standardizes the forwarding layer across all your managed domains from one dashboard. If you're deciding between aliases and full mailbox rules, the email alias forwarding guide covers the tradeoffs in detail.

Checklist: Before You Forward Email to Another Address

Check all four of these before enabling any live forwarding rule. Each point maps to one of the failure modes above. Miss one, and you're debugging silent delivery failures at the worst possible time.

1. SRS is active. Check the Return-Path header on a delivered test message. It must show your forwarding domain — not the original sender's domain.
2. No body modification. Disable antivirus footers, subject-line tags, and "External Sender" banners on the forwarding server. Any modification to the message body breaks DKIM.
3. Loop protection. Verify the destination address has no active reverse-forward rule and no Out-of-Office reply pointing back at your domain.
4. M365 outbound policy. If routing through Exchange Online, explicitly enable "Automatic Forwarding" in the Defender portal's outbound spam filter. Without this, the forward is blocked at departure.

When Not to Forward Email to Another Address

Sometimes the right answer isn't to forward email to another address at all. If the goal is routing mail from multiple domains into one inbox, a domain alias handles it without touching the forwarding authentication layer — and without SPF/DKIM complexity.

The domain email alias vs mailbox comparison covers when an alias is the right call versus a full forwarding rule. And if you need to forward email to another address because you're migrating away from a previous provider, TrekMail's built-in IMAP migration tool is the cleaner path — it pulls mail directly from the source server rather than relying on live forwarding rules that can fail silently.

Summary

When you forward email to another address, your server inserts itself as an unauthorized relay in the eyes of SPF. The original sender's SPF record doesn't list your IP. If DKIM also breaks, DMARC fails. The message disappears with no trace and no bounce to anyone in the chain.

The fix is server-side: SRS rewrites the Envelope Sender to a domain you control; ARC lets trusted forwarders vouch for the authentication chain. You can implement both on a self-managed Postfix server — or use a platform where it's already built in.

If you want to forward email to another address without managing SRS keys, ARC configuration, or sending reputation, TrekMail handles it at the infrastructure level. Starter plan is $3.50/month for up to 50 domains, flat rate, no per-user fees. See all plans.