How to Set Up Email Forwarding on Your Domain Without Losing Mail

A domain email forwarding setup takes mail addressed to your own domain and delivers it to a mailbox you already read, usually at a different provider. The mechanics matter more than the control panel wording: forwarding works by rewriting the envelope recipient at your mail server, and everything that goes wrong later traces back to how that rewrite interacts with SPF, DKIM and DMARC at the destination.

There are two broad approaches. The first is a true mail server that receives the message, accepts it, and re-sends it to the destination. The second is a forwarding alias managed by your DNS or mail provider, where the provider receives the message on your behalf and relays it. Both end up as an SMTP conversation with a new envelope, and both are judged by the same authentication checks.

What actually happens during domain email forwarding setup

When someone sends to [email protected], their server looks up the MX records for example.com and opens an SMTP session. If you run your own server, that session terminates on your host. Your mail transfer agent looks up the address in its alias table, finds a mapping to your real inbox, and queues a new message. The new message keeps the original headers but gets a fresh envelope sender and recipient.

That distinction between the envelope and the headers is the source of most confusion. The Return-Path header, which mirrors the envelope sender, may be rewritten to your own address. The From header stays exactly as the original sender wrote it. Receiving servers care about both, and they disagree about which one to trust depending on the check.

A minimal Postfix alias entry looks like this:

# /etc/postfix/virtual
[email protected]    [email protected]
[email protected]  [email protected]

After editing, you rebuild the lookup table and reload the daemon:

postmap /etc/postfix/virtual
postfix reload
postmap -q [email protected] hash:/etc/postfix/virtual
# [email protected]

The postmap -q line is the part people skip. It queries the compiled database directly, so you find out immediately whether your mapping is loaded rather than discovering it from a bounce later. If it prints nothing, the table is not compiled or the file path in virtual_alias_maps is wrong.

Why forwarded mail lands in spam, and the header that explains it

SPF authenticates the envelope sender against the sending IP. When you forward, the envelope sender is often your address, and the sending IP is yours. If your domain publishes an SPF record that does not include that IP, the receiving server sees a soft fail or hard fail. The original sender's SPF record is irrelevant at this point, because the message is no longer coming from them.

DKIM is more forgiving in one direction and less in another. The original signature survives forwarding only if nothing in the signed headers changed. A mailing list that adds a footer breaks it. A plain forward that only rewrites the envelope leaves the signature intact, and the receiving server can still verify it against the original sender's published key. That is why a well behaved forwarder keeps the body and headers untouched.

DMARC ties the two together. It tells the receiver what to do when the From domain fails both SPF and DKIM alignment. Since the From header still shows the original sender, alignment is judged against that domain, not yours. A forwarder that breaks DKIM and rewrites the envelope can therefore fail DMARC on someone else's domain, which is why aggressive forwarders get blocked.

The fix is not to disable DMARC on your side. It is to forward in a way that preserves the original message. If you control the receiving server, you can also whitelist your forwarder, but that only helps for one destination.

SRS and why your forwarder rewrites the envelope sender

Sender Rewriting Scheme exists to solve exactly the SPF problem above. Instead of leaving the envelope sender as the original address, the forwarder rewrites it to something like [email protected]. The receiving server now checks SPF against your forwarder's domain, which publishes a record that passes. If the message bounces, the forwarder can decode the address and route the bounce back to the original sender.

Postfix implements this with a small configuration change:

sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient

That points at a postsrsd process listening on those ports. Without it, every forward to a strict destination is a coin flip. With it, the envelope is consistent and the bounce path works. The tradeoff is that the envelope sender no longer matches the From header, which some spam filters weigh negatively, so you are trading one signal for another.

Keeping replies working

A forward is one way. When your recipient hits reply, the reply goes to the original From address, not to [email protected]. If you want replies to come back through your domain, you need the reply to be addressed to your domain, which means the original message must have carried a Reply-To header pointing there.

You cannot add that header to inbound mail you are merely relaying without breaking DKIM, because Reply-To is typically inside the signed header set. The practical options are to accept that replies go to the original sender, or to send from your domain in the first place so the conversation is already anchored there. For a role address like sales@, the second is usually what you want, and forwarding is only a stopgap.

Test the whole path before you rely on it. Send from an external account you control, check the received headers at the destination, and confirm three things: the Return-Path is what you expect, the DKIM result is pass or at least none rather than fail, and the Authentication-Results header shows SPF aligned. If SPF shows softfail and DKIM shows fail, your forwarder is stripping or invalidating the signature and you need to fix that before adding more addresses.

Next, pick one address and wire it end to end, including the bounce path. Send a test that fails at the destination on purpose, for instance to an address you know rejects mail, and confirm the bounce arrives back at the original sender rather than disappearing or landing in your own inbox. Once that round trip works, the rest of your aliases are a table edit. Keep the alias file in version control, because the mapping between addresses and people changes more often than the server configuration does, and you will want to know who was receiving what at any given point.