Aliases, .forward files and DMARC

8 June 2026 · 15 min read

An alias looks like the most innocent thing in email. You point sales@yourcompany.com at three colleagues, you set up info@ to land in a shared mailbox, a member of staff configures their university address to drop a copy into their personal Gmail, and from the outside nothing seems to have changed. The sender still types one address; the message still arrives. Underneath, though, an alias is not a label on a mailbox. It is a re-sending instruction, and the moment a mail server re-sends a message on someone else's behalf it becomes a new originator in the eyes of SPF, DKIM and DMARC. That single fact is responsible for an enormous share of the "but the mail is genuine and it still failed DMARC" confusion that lands on help desks every week.

This article takes aliases and .forward files apart mechanism by mechanism. It explains what an alias actually does to a message at the SMTP level, why that re-sending step is the thing that matters rather than the alias itself, what happens to each authentication identifier when a message is forwarded, how DMARC adjudicates the result, and what you can realistically do to keep forwarded mail aligned. The aim is to leave you able to look at an alias and predict, before you ever read a report, whether mail through it will pass or fail and why.

An alias is a re-send, not a relabel

The word "alias" hides a fork in the road, and the two branches behave completely differently for authentication.

The harmless branch is a local alias that delivers into a mailbox on the same system. When info@yourcompany.com is configured so that mail simply lands in a shared mailbox hosted on the same mail platform, no message ever leaves the building. Nothing is re-sent. SPF, DKIM and DMARC are all evaluated once, at the moment your server first accepted the message, and the alias is invisible to them. This kind of alias never breaks authentication because it never creates a second hop.

The branch that causes trouble is a forwarding alias that re-sends the message to an address on a different system. When alice@university.edu is set to forward to alice@gmail.com, the university's mail server receives your message, then opens a brand-new SMTP connection to Gmail and re-injects the message there. From Gmail's point of view a message has just arrived from the university's IP address carrying your domain in its headers. Gmail does not know, and has no reliable way to know, that this is a forward rather than a fresh send. It runs SPF, DKIM and DMARC on what it sees. And what it sees has changed in exactly the ways that break those checks.

So the useful mental model is this: an alias that delivers locally is a label, and an alias that sends onward is a re-send. Only the re-send touches authentication. Everything else in this article is about the re-send case, because that is the one that fails.

What a .forward file actually does

The classic Unix .forward file is the oldest and most literal version of a forwarding alias, and it is worth looking at directly because it makes the mechanism obvious.

On a traditional Unix mail system, every user can place a file called .forward in their home directory. The local mail transfer agent (Sendmail, Postfix, Exim and their relatives all honour the convention) reads this file during delivery. If it contains an email address, the MTA does not deliver the message into the local mailbox; instead it re-sends the message to the address in the file. A .forward containing

alice@gmail.com

means "take everything that arrives for this local user and re-inject it towards Gmail". You can also keep a local copy and forward at the same time with a leading backslash and a comma:

\alice, alice@gmail.com

which delivers locally and forwards. There are richer forms too, piping to a program or to a :include: list file, but the address form is the one that creates the authentication problem, because it is the one that opens a new outbound connection.

The reason .forward matters beyond nostalgia is that almost every modern "forward my mail to..." feature is the same operation wearing a friendlier interface. A mailbox rule in a hosted mail platform, a catch-all that redirects to an external address, a control-panel "forwarders" table, a Sieve redirect action, an alias map in a mail server's configuration: all of them culminate in the same SMTP behaviour as a .forward file. The server accepts the message, then re-sends it onward from its own IP. Whatever the user interface calls it, if it re-injects the message towards another system, it is a forward and it carries every consequence below.

The two identities a forwarded message carries

To predict what forwarding does, you have to hold two separate addresses in your head, because forwarding treats them differently and DMARC only cares about one of them.

• The envelope sender, also called the Return-Path or envelope-from, set in the SMTP MAIL FROM command. It is the address bounces go back to. It is not normally shown to the reader. SPF authenticates this address and only this address. The concept is laid out in the return-path glossary entry.
• The header From, the address a human actually reads at the top of the message, for example news@yourbrand.com. This is the identity DMARC is anchored to. SPF on its own never looks at it. There is a fuller treatment in header From vs envelope from and a short definition in the header-from glossary entry.

The gap between these two addresses is the root of nearly everything that follows. Forwarding routinely rewrites the envelope while leaving the header From untouched, and DMARC keeps judging you on the unchanged From address. Hold that asymmetry in mind and the rest of the behaviour becomes predictable rather than mysterious.

Why SPF breaks through a forwarding alias

SPF asks one question: did the connection that just delivered this message come from an IP address authorised by the envelope-from domain's SPF record? It is a check on where the connection came from, nothing more.

Trace a forwarded message and the failure is inevitable. You send from your own authorised outbound server. The university accepts the message; at that first hop SPF passes, because your server's IP is in your SPF record. Then the .forward fires and the university re-sends the message to Gmail. Gmail now runs SPF. It reads the envelope-from domain, which in a naive forward is still yourbrand.com, fetches your SPF record, and checks the connecting IP. But the connecting IP is now the university's mail server, which is not in your SPF record and never should be. SPF fails.

This is not a misconfiguration you can fix. SPF binds authorisation to the sending IP, and forwarding changes the sending IP while keeping your domain in the envelope. The only "fix" would be to authorise every forwarding server on the internet inside your SPF record, which would both blow past the ten-lookup limit immediately and destroy the entire point of SPF. The classic symptom is a plain SPF fail or a PermError in your aggregate reports against IP ranges belonging to universities, ISPs, hosting companies and mail gateways. You can confirm what your own record authorises with the SPF checker, and the background to the mechanism is on the SPF product page and in the SPF glossary entry.

SRS rescues SPF but not DMARC

Some well-behaved forwarders implement the Sender Rewriting Scheme (SRS). Instead of leaving your domain in the envelope-from when they re-send, they rewrite it to one of their own, something like SRS0=hash=...=yourbrand.com@university.edu. Now Gmail checks SPF for the university's domain against the university's connecting IP, and SPF passes, because the forwarder is vouching for its own relay with its own SPF record.

The catch that almost everyone misses: SRS rescues the SPF check but does nothing for DMARC. DMARC does not care that SPF passed for university.edu. It cares whether SPF passed for a domain that aligns with the header From, which is still yourbrand.com. After SRS the SPF-authenticated domain is the forwarder's, so SPF is no longer aligned, and from DMARC's point of view the pass does not count. This is exactly why you cannot lean on SPF to carry a forwarded message through DMARC, and why DKIM does the heavy lifting in the next section. If alignment is a new idea, start with DMARC alignment explained and the dmarc-alignment glossary entry.

Why DKIM can survive a forwarding alias

DKIM works on an entirely different principle, and that difference is what lets it survive the journey SPF cannot.

DKIM does not care where the connection came from. It is a cryptographic signature over the content of the message: a chosen set of headers plus the body. Your server computes a hash, signs it with a private key, and stamps a DKIM-Signature header onto the message. That header names the signing domain in its d= tag and the key location in its selector s= tag. The receiver fetches the public key from DNS at <selector>._domainkey.<d-domain>, recomputes the hash over the same headers and body, and verifies the signature. None of that depends on the connecting IP.

So as long as the signed headers and the body arrive byte-for-byte unchanged, the signature verifies no matter how many servers relayed the message. A plain .forward that re-sends your message without touching it leaves DKIM perfectly intact. The university can pass it to Gmail and DKIM still verifies, because the bytes the signature covers never changed. This is why DKIM is the load-bearing identifier for any domain that wants to reach enforcement: it is the only mechanism built to survive multi-hop email. The mechanics of alignment specifically are in DKIM alignment and forwarding, and you can inspect a live signature with the DKIM checker.

A valid signature still has to align

As with SPF, surviving the trip is necessary but not sufficient. DMARC asks the stricter question: did a valid signature verify for a domain that aligns with the header From? If your platform signs as d=sendgrid.net while your From is news@yourbrand.com, the signature can verify flawlessly and still do nothing for DMARC, because sendgrid.net does not align with yourbrand.com. The fix is to sign with your own domain, which most reputable platforms support through a CNAME or TXT delegation. The DKIM product page covers how aligned signing is provisioned, and the dkim-selector glossary entry explains the selector mechanism.

Why DKIM sometimes breaks on forwarding too

If DKIM survives a clean forward, why do reports show DKIM failures on forwarded mail? Because the guarantee is conditional: the signed content must arrive unchanged, and plenty of forwarders change it, usually with good intentions. Any change inside the signed scope invalidates the signature. The common culprits sit on the path between your alias and the final mailbox:

• Footer or banner injection. A gateway or list-style forwarder that appends an unsubscribe line, a disclaimer, or an "external sender" banner to the body breaks the body hash.
• Subject rewriting. Prepending a tag to the Subject breaks the signature, because the Subject is one of the headers nearly every signer covers.
• Header reformatting. Re-folding long header lines, reordering headers, or rewriting MIME boundaries can break a signature depending on the canonicalisation in use.
• Content scanning and rewriting. Security gateways that rewrite URLs for link protection, strip or rewrite attachments, or insert warning text inside the body all alter signed content.
• Encoding changes. A relay that re-encodes the body from one transfer encoding to another changes the exact bytes the signature was computed over.

DKIM offers two canonicalisation modes, simple and relaxed. The relaxed mode tolerates trivial whitespace and header-case differences, so it survives some benign reformatting that simple would not. But canonicalisation only normalises trivial whitespace and folding. It will not let a footer, a rewritten subject or a stripped attachment slide. Relaxed/relaxed is the sensible default precisely because it maximises the chance of surviving a forwarder that touches headers without changing the meaning of the message. The trade-offs are in DKIM canonicalisation: simple vs relaxed.

This gives the asymmetry in one sentence: forwarding almost always breaks SPF because it changes the connecting IP that SPF is bound to, and it sometimes breaks DKIM, only when a forwarder edits content the signature covers. A bare alias that touches nothing usually keeps DKIM alive; an alias that runs the message through a gateway that rewrites it usually does not.

How DMARC adjudicates a forwarded message

DMARC sits on top of SPF and DKIM and applies one decisive rule: a message passes DMARC if at least one of SPF or DKIM passes and aligns with the header From domain. It does not need both. One aligned pass is enough, and that single OR is the reason forwarded mail so often survives.

Walk the university-alias case through it. SPF fails (or, with SRS, passes for the forwarder's domain and so does not align). On its own that would be a DMARC failure. But if the .forward did nothing more than re-send your untouched message, your DKIM signature verifies and aligns with yourbrand.com. One aligned pass exists, so DMARC passes, and the message is delivered cleanly even at p=reject. The forward worked precisely because DKIM carried the load that SPF dropped.

Now change one thing: put a gateway on the path that appends an "external sender" banner. DKIM breaks because the body changed; SPF was already broken or unaligned. Neither identifier survives aligned, and DMARC fails. At p=none nothing visible happens, but at p=quarantine or p=reject your genuine message is spam-filed or rejected at the recipient. Same alias, different outcome, and the deciding factor was whether anything on the path touched the signed content. This is why two superficially identical forwarding setups can behave completely differently, and why "it's just an alias" is never a sufficient description. The companion piece why forwarding breaks authentication walks the same logic from the other direction, and the DMARC forwarding problem covers the receiver-side decision in more depth.

ARC: how a good forwarder can vouch for what it broke

There is a mechanism designed for exactly this situation: the Authenticated Received Chain, or ARC. When a forwarder that supports ARC receives your message, it records the authentication results it observed at that moment, that SPF and DKIM both passed and aligned for yourbrand.com, and seals that record into the message with its own signature. When the message reaches the next hop, even though your original SPF and DKIM are now broken by the forward, the receiver can read the ARC chain and see a trustworthy statement: "I, the forwarder, verified this message was authentic before I touched it."

ARC does not force the receiver to deliver. It gives the receiver a basis to apply a local override, to choose not to reject a message that fails DMARC if a forwarder it trusts has vouched that the message was legitimate on arrival. The large mailbox providers honour ARC from forwarders they trust, which is why mail through a well-run forwarder or list often lands in the inbox despite a raw DMARC failure. The limitation is that ARC is only as good as the forwarder's reputation and only helps if the forwarder implements it; you cannot add ARC to someone else's relay. The details are in mailing lists, DMARC and ARC and the ARC glossary entry.

Keeping forwarded mail aligned: what you can actually do

You cannot stop a forward from changing the connecting IP, and you cannot control gateways on the recipient's side. But there are concrete moves that maximise the share of forwarded mail that stays aligned, and they fall into two groups: things you do as the original sender, and things you do as the operator of the alias.

As the sender of the original mail

1. Make DKIM aligned and robust, because it is your only identifier that can survive a forward. Sign every outbound stream with d= set to your own domain (or an aligned subdomain), not your provider's. Use relaxed/relaxed canonicalisation. Sign a tight, sensible set of headers, no more than you need, so there is less surface for a forwarder to disturb. Verify the live result with the DKIM checker.
2. Do not rely on SPF to carry forwarded mail. SPF is still worth getting right for direct mail, and you should keep your record clean and under the lookup limit, but accept that it will not survive forwarding. Treat DKIM as the mechanism that gets you through, and use the DMARC checker and SPF checker to confirm the direct path is solid before you start chasing forwards.
3. Read your reports before you tighten policy. Forwarding failures show up clearly in DMARC aggregate data as failures from third-party IPs while DKIM remains aligned. Run the data through the DMARC report analyzer so you can separate genuine forwarding from actual abuse, rather than reacting to the noise. The aggregate reporting product turns that raw XML into a readable picture.

As the operator of an alias or .forward

1. Implement SRS on your forwarder. Rewriting the envelope-from to your own domain rescues SPF for your relay and keeps your own bounce handling sane, even though it does not, by itself, fix the recipient's DMARC alignment for the original sender. Most modern MTAs support SRS natively or through a plug-in.
2. Implement ARC. If your relay seals an ARC chain recording the authentication it saw before forwarding, downstream receivers that trust you can deliver mail that would otherwise fail DMARC. This is the single most effective thing a forwarder can do for the senders whose mail it carries.
3. Touch the message as little as possible. Every banner, subject tag, footer and URL rewrite you add is a DKIM signature you have just destroyed for someone else. If you must add an external-sender warning, consider adding it in a way that does not modify the signed body, or accept that you are converting surviving DKIM into a failure and that ARC is now doing all the work.
4. Forward from a clean, well-reputed IP. A forwarder's own reputation is what makes its ARC seals and SRS vouching worth anything to a receiver. Keep the relay off blocklists and its reverse DNS correct.

Where this fits in getting a domain to enforcement

Forwarding is the reason a careful, staged move to enforcement matters, rather than flipping p=none straight to p=reject and hoping. The honest position is that you cannot make every forwarded message pass DMARC, because some of those failures happen on infrastructure you neither own nor can see. What you can do is make sure the failures you see are forwarding rather than fraud, make DKIM as survivable as possible so the maximum share of forwards stays aligned, and lean on ARC for the rest. Then you can enforce with confidence that you are blocking spoofing without knocking out the genuine mail that takes the scenic route.

A done-for-you path through this is what the DMARC enforcement product is built around: it watches your aggregate reports, identifies forwarding and alias traffic specifically so it is not mistaken for abuse, and moves the policy from p=none through p=quarantine to p=reject only once the legitimate streams, forwarded mail included, are landing aligned. If you want to see where your domain stands today, the DMARC checker shows your current policy and the requirements page lays out what a sender and recipient each need to have in place. For the conceptual groundwork, why forwarding breaks authentication and the DMARC glossary entry are the right next reads.

The short version to carry away: an alias is a re-send, the re-send is what authentication sees, SPF cannot survive it, DKIM can if nothing rewrites the message, DMARC needs just one of those to survive aligned, and ARC is how a trustworthy forwarder rescues the cases where neither does. Once that chain is clear, every forwarding report you ever read will tell you its own story.