Email Forwarding Best Practices: What Works and What Quietly Breaks

Email forwarding is one of those features that looks simple on the surface and turns out to be surprisingly complicated underneath. Set it up correctly and it works invisibly. Set it up wrong — or use it in ways it wasn't designed to handle — and you get deliverability failures that are genuinely hard to diagnose because the break point is often invisible to the person experiencing it.

What Server-Level Email Forwarding Actually Does

Server-level email forwarding receives a message at one address and re-transmits it to another — typically on a different server or domain. The mail server receives the original message, then connects to the destination server and delivers a copy, often preserving the original sender's From address.

This is different from client-side forwarding, where your email client downloads a message and sends a new copy. Client forwarding creates an entirely new message with you as the sender. Server forwarding passes the original message through — and that's where authentication complications arise, because the message now arrives at the destination from a server that had no part in the original sending relationship.

How Forwarding Breaks SPF

SPF checks whether the server delivering a message is authorized to send on behalf of the envelope sender's domain. When your mail server forwards a message, it becomes the delivering server — but the envelope still claims to be from the original sender's domain. Your forwarding server is almost certainly not listed in that domain's SPF record.

Result: SPF fails at the destination. The destination server sees a message arriving from your forwarding server, claiming to be from someone else's domain, with no SPF authorization. That's exactly what spoofed spam looks like.

The technical solution is SRS (Sender Rewriting Scheme), which rewrites the envelope sender to be under the forwarding server's domain. SRS passes SPF at the destination because the rewritten envelope sender comes from a domain the forwarding server is legitimately authorized to send for. Not all forwarding setups implement SRS, and when they don't, SPF failures are the predictable consequence.

How DKIM Survives Forwarding (Mostly)

DKIM signatures travel with the message as a header and are tied to the specific content of the message. If the forwarding server passes the message through without modification, the original DKIM signature remains valid at the destination — the receiving server verifies it against the sender's public key in DNS and it checks out.

The problem is that some forwarding configurations do modify messages: adding footers, inserting disclaimers, modifying subject lines, or adjusting certain headers. Any change to the signed content invalidates the DKIM signature. A corporate email gateway that appends a legal disclaimer to every forwarded message will consistently break DKIM in ways that are invisible until you start investigating bounces and spam folder placement.

The DMARC Problem

DMARC requires that either SPF or DKIM passes and aligns with the From domain. When SPF fails because the forwarding server isn't authorized, and DKIM fails because the message was modified during forwarding, DMARC fails. For domains with p=reject, the destination server may reject the message outright.

This is why forwarding has become more problematic as DMARC adoption has grown. A message that forwarded reliably five years ago from a sender with no DMARC policy may now fail delivery because that sender has since implemented a strict DMARC policy — and your forwarding setup hasn't changed to account for it.

Better Alternatives to Forwarding

For some use cases, forwarding is the only option. But for others, there are cleaner alternatives:

• Email aliases: An alias for info@company.com that delivers directly to person@company.com routes mail without forwarding through an intermediate step. No authentication complications.
• Shared mailboxes: Multiple people accessing one mailbox avoids the need to forward to individuals. This works well for role addresses like support@ or billing@. See group mailboxes vs distribution lists for how to structure these.
• Email client rules: Configure rules in your email client to copy specific messages to another account. This creates a client-originated copy rather than a server-side forward, with you as the sender — authentication is clean.

When Forwarding Is Necessary

If server-level forwarding is genuinely required, take these steps to make it as reliable as possible:

• Ensure your forwarding server implements SRS to rewrite the envelope sender correctly
• Avoid modifying message content or headers during forwarding — no footers, no disclaimers added at the forwarding stage
• Check whether the domains you're forwarding from have strict DMARC policies; those messages are at elevated risk of delivery failure
• Monitor bounce rates on forwarded mail — unusually high bounces from the destination are often the first sign that authentication failures are causing rejections

Understanding how email routing works at the MX level helps clarify why these failures happen and what layer they occur at. The MailDog mail service supports alias-based delivery that sidesteps many of these forwarding complications. If you have a specific scenario to work through, the support team can help you find the cleanest approach.