Email forwarding is a rule that takes a message arriving at one address and sends a copy to another. An alias is a second address that delivers into an existing mailbox; a redirect resends the original message largely unchanged, while a forward often rewraps it. Where replies go depends entirely on which of these you set up and which address sits in the From header. Forwarded mail frequently fails SPF alignment, which is the single most common reason it lands in spam or is rejected outright.
Forwarding, aliases and redirects: what is actually different?
The three terms get used interchangeably in casual conversation, but mail servers treat them differently, and the differences explain most of the confusion people hit later.
- Forwarding — a rule on the receiving mailbox that sends a copy onward. The copy may keep the original sender in From (an inline forward) or be rebuilt as a new message from the forwarding account (a rewrap). Many consumer providers now rewrap, which changes the headers.
- Alias — an additional address that points at a real mailbox. Mail is delivered to the mailbox; nothing is resent. The alias is usually recorded in a Delivered-To or envelope header, not in From.
- Redirect — a server-level resend that preserves the original envelope sender and headers as far as possible. Conceptually it is the closest thing to passing the letter on untouched.
- Group or list address — one address that fans out to many recipients. This is a mailing list, not personal forwarding, and it has its own deliverability rules.
The practical consequence: an alias almost never breaks authentication, because the message is delivered rather than resent. A forward frequently does, because the resending server is not the domain the message claims to come from.
Why does forwarded email fail SPF and land in spam?
SPF publishes a list of servers authorised to send mail for a domain. When you forward a message, the forwarding server is now sending that message, and it is not on the original domain's list. The receiving server checks SPF against the envelope sender, sees a mismatch, and records an SPF fail.
Whether that matters depends on what the destination does with the result:
- SPF alone — a soft fail is often tolerated; a hard fail may be rejected or junked.
- SPF plus DKIM — if the original DKIM signature survives forwarding intact, a DKIM pass can override the SPF fail. This is why some forwards work perfectly and others never do.
- DMARC enforcement — the destination applies the domain owner's published policy. Under a strict policy with alignment required, a broken forward is much more likely to be rejected.
Things that commonly break the DKIM signature in transit: the forwarder rewriting the subject line, adding a footer or disclaimer, stripping attachments, or converting the body from HTML to plain text. Any byte-level change to signed headers or the body invalidates the signature.
If you want the mechanics in more depth, our guide to SPF, DKIM and DMARC walks through each record and what a failure actually means at the receiving end.
What you can realistically do about it
- Prefer an alias over a forward when the provider offers both. Delivery avoids the problem entirely.
- Use a forwarder that preserves the original message and does not add footers.
- Add the forwarding address to your allow list at the destination, and check the spam folder before assuming mail is lost.
- Accept that some senders will always break: banks, ticketing systems and anything with aggressive DMARC policies are the usual suspects.
Where do replies go when you send from a forwarded address?
This is where most people get caught out, and the answer is: it depends on the From header, not on where the mail was delivered.
If you receive a forwarded message and hit reply, your mail client typically addresses the reply to whatever sits in the From header — the original sender. That is usually what you want. But if you want to reply as the alias or forwarding address, you need the sending side to be configured for it.
| Setup | What the recipient sees in From | Where their reply lands |
|---|---|---|
| Plain alias (receive only) | Your real mailbox address | Your real mailbox |
| Alias with send-as configured | The alias address | The alias, which delivers to your mailbox |
| Forwarding rule, replying normally | Your real mailbox address | Your real mailbox |
| Forwarding rule, spoofing the alias in From | The alias address | The alias — but the message will likely fail authentication |
That last row is the trap. Typing an alias into the From field of a mail client that is not authorised to send for that domain produces a message that fails SPF and DMARC at the recipient. It may be silently junked, and it teaches receiving servers to distrust that domain. Proper send-as requires the provider to relay the message through an authorised server, usually with its own SMTP credentials.
Rule of thumb: a receive-only address is a letterbox, not a pen. If the service cannot send, do not try to make it appear to.
Disposable inboxes are receive-only by design, which is worth knowing before you plan to reply from one. We covered the details in can you send email from a temp mail address.
How hidden forwarding rules become an attacker's tool
If someone gains brief access to your mailbox — a reused password, a session token stolen by malware, a phished code — one of the quietest things they can do is add a forwarding rule. No password change, no visible alert, no new device left signed in. Mail simply starts arriving somewhere else.
The pattern that matters most is forwarding plus filtering. An attacker who forwards everything and then deletes the copies of security alerts, password resets and bank statements leaves you with a mailbox that looks normal. The absence of notifications is the attack.
What to check, and how often:
- Forwarding and auto-forward settings in your mail provider's settings page. Look for addresses you did not add.
- Filters and rules that delete, archive or mark as read — especially any that target words like "security", "invoice" or a bank name.
- Connected apps and delegated access, which can read mail without a forwarding rule at all.
- Recovery options: an added recovery address or phone number is a back door in plain sight.
- Sent items and trash for messages you did not write or delete.
Most major providers expose these under Settings → Forwarding, Filters, or Security. Check them after any suspected compromise, and again a week later, because rules have been known to be re-added. If you are working through a breach, our checklist on what to do after a data breach covers the order of operations.
Why a receive-only inbox sidesteps this
A throwaway address that expires has no forwarding rules to hijack and no long-term archive to mine. It is not a substitute for securing your real mailbox, but it removes one class of persistent access. The trade-off is that you cannot recover it later — see can you recover a temp mail for the honest limits.
When should you forward, alias, or use a disposable address?
There is no universal answer, but the decision usually comes down to how long you need the address and whether you need to reply from it.
- Use a permanent alias for anything you will need to log into for years: banking, government portals, utilities, work accounts. Aliases survive, can be revoked individually, and usually support send-as.
- Use forwarding when you want one inbox to collect several addresses you already own, or when consolidating after changing jobs or providers.
- Use a disposable inbox for one-off verification, downloads, trials and forums where you expect no further correspondence. Our comparison of temp mail, VPNs and aliases sets out where each tool stops being useful.
- Avoid forwarding for anything with two-factor codes unless the path is short and reliable. A code that arrives late because a forward was greylisted is worse than no forward at all.
One more caution: forwarding does not make you anonymous. The destination mailbox still receives the full headers, including the original sender's details and often your own address in the envelope. If your goal is to keep a signup away from your main identity, forwarding into your real inbox defeats the purpose.
Sources
- NIST SP 800-63-4 — Digital Identity Guidelines, relevant to account recovery and authenticator binding.
- RFC Editor — the official index of internet standards, where the current SPF, DKIM and DMARC specifications are published.
In short
Forwarding copies mail and often breaks SPF alignment; aliases deliver mail and rarely do. Replies go to whatever sits in the From header, so a receive-only address cannot be used to send without failing authentication. And the same forwarding feature that consolidates your inbox is a favourite hiding place for attackers, so audit your rules after any suspected compromise. Match the tool to the lifespan of the account: alias for the long haul, disposable inbox for the one-off, and forwarding only when you control both ends.