Aliases, .forward files and DMARC

23 June 2026 · 6 min read

An alias that delivers into a mailbox on the same system does not affect SPF, DKIM or DMARC. An alias or .forward file that sends mail on to another system does: the forwarding server opens a new SMTP connection from its own IP address, so SPF for the original sender fails, while a DKIM signature survives only if nothing in the signed content changes. DMARC needs just one of the two to pass with alignment, which is why clean forwards usually pass and forwards through a gateway that edits messages often fail.

Local aliases versus forwarding aliases

• Local alias. info@example.com delivers into a shared mailbox on the same mail platform. The message is accepted once, checked once, and never leaves the system. Authentication is unaffected.
• Forwarding alias. alice@university.example forwards to alice@gmail.com. The university's server accepts your message, then sends it on to Gmail from its own IP address. Gmail checks SPF, DKIM and DMARC against what arrives, and has no reliable way to know it is a forward.

Only the second kind matters for authentication, and most "forward my mail" features are this kind: mailbox forwarding rules, catch-all redirects, control-panel forwarders, Sieve redirect actions and alias maps that point outside the system.

What a .forward file does

On Unix mail servers such as Sendmail, Postfix and Exim, a user can put a .forward file in their home directory. If it contains an address, the server sends incoming mail on to that address instead of delivering it locally:

alice@gmail.com

To keep a local copy as well, list the local user with a leading backslash:

\alice, alice@gmail.com

Either way, the address entry makes the server open a new outbound connection, with the same consequences as any other forward.

Why SPF fails on a forwarded message

SPF checks whether the connecting IP is authorised by the domain in the envelope sender (the MAIL FROM, or Return-Path), as defined in RFC 7208. When you send, your server's IP is in your SPF record and SPF passes. When the university forwards the message, the connecting IP is the university's, which is not in your record. If the envelope sender still names your domain, SPF fails. Adding every forwarding server in the world to your SPF record is not possible.

Some forwarders rewrite the envelope sender to their own domain, a technique called the Sender Rewriting Scheme (SRS). Google's best practices for forwarding to Gmail recommend the same thing: change the envelope sender to reference the forwarding domain. SPF then passes, but for the forwarder's domain, which does not align with your From address. Either way, SPF stops counting towards DMARC once a message is forwarded.

Why DKIM can survive

DKIM signs selected headers and the body. The receiver checks the signature against the public key at <selector>._domainkey.<d-domain>, and the connecting IP plays no part. If the forwarder passes the message on unchanged, the signature still verifies, and if d= is your domain it still aligns with your From address.

DKIM breaks when the forwarder changes something the signature covers:

• adding a footer, disclaimer or "external sender" banner to the body;
• adding a tag to the Subject line;
• rewriting links for security scanning, or stripping attachments;
• re-encoding the body or rebuilding MIME parts.

Relaxed canonicalisation (c=relaxed/relaxed) tolerates whitespace changes and header re-folding, but not changes to the content. Google's forwarding guidance asks forwarders to avoid changing the body and headers protected by DKIM for exactly this reason.

How DMARC decides

DMARC passes if SPF or DKIM passes and aligns with the From domain.

The same alias can therefore pass for one sender and fail for another. What decides it is whether the sender signs with DKIM on their own domain and whether anything on the way edits the message.

ARC: a forwarder vouching for what it saw

The Authenticated Received Chain, defined in RFC 8617, lets a forwarder record the authentication results it saw on arrival and seal them into the message with its own signature. A later receiver that trusts that forwarder can choose to deliver a message that now fails DMARC, because the forwarder vouched that it passed before it was changed. Microsoft 365, for example, lets administrators name trusted ARC sealers for this purpose.

ARC does not oblige a receiver to accept anything, and it only helps when the forwarder implements it. You cannot add ARC to someone else's server. ARC explained covers the mechanism.

What you can do

If you send the original mail:

1. Sign every stream with DKIM using your own domain in d=. It is the only mechanism that can survive a forward. Check each selector with the DKIM checker.
2. Do not rely on SPF for forwarded mail. Keep your SPF record correct for direct mail, and accept that forwards will fail it.
3. Read your aggregate reports before tightening your policy. Forwarded mail typically shows SPF failing from university, ISP or hosting IP ranges while DKIM still passes and aligns. The DMARC report analyser separates those rows from real spoofing.

If you run the alias or forwarder:

1. Rewrite the envelope sender to your own domain (SRS), as Google recommends.
2. Leave the body and DKIM-signed headers alone wherever you can.
3. Add ARC seals if your mail server supports them.

Forwarding and enforcement

Some forwarded mail will fail DMARC on infrastructure you never see, so the goal is not to make every forward pass. It is to make sure aligned DKIM carries as much of it as possible, and that the failures in your reports are forwarding rather than spoofing, before you move to p=quarantine or p=reject. The current DMARC standard, RFC 9989, goes further: domains whose users post to mailing lists SHOULD NOT publish p=reject.

For the same problem seen from the receiving side, read why forwarding breaks authentication. If you want forwarding traffic identified for you, DMARC analytics groups forwarded mail separately from suspected spoofing, so you can tell the two apart.