Aliases vs Forwarding vs Full Masking: What Each One Actually Hides
Privacy blogs use "alias", "forwarding", and "masking" interchangeably — but they defend against three completely different adversaries. Here's what leaks at the SMTP, DNS, and header level in each case, and how to pick by the threat you actually face.
EvilMail TeamAugust 2, 202611 min read
People buy an "email privacy" product, plug in a random-looking address, and assume they've disappeared. Then they hit reply, and their real [email protected] sails out in the From: header. The address they were paying to hide is now sitting in the sender's inbox in plaintext.
The confusion is baked into the vocabulary. Alias, forwarding, and masking get used as synonyms in most privacy writeups, but they are three orthogonal mechanisms that hide three different things from three different adversaries:
An alias hides your *canonical address* from the sender's database.
Forwarding hides *where mail actually lands* from anyone reading the address.
Masking (a relay) hides your *sending identity* on the reply.
Almost every consumer product ships one or two of these and lets the marketing imply all three. If you don't know which property you're buying, you can't know which adversary you're still exposed to.
Email Alias vs Forwarding vs Masking: The Real Threat Models — EvilMail Blog
What each word actually means
Define the primitives first, because the whole argument rests on one distinction: alias and forwarding are inbound-only. Only masking touches the outbound path.
Alias. A distinct RCPT TO address that resolves — via virtual_alias_maps, a catch-all, or a Sieve rule — to a mailbox you already own. No rewriting happens on the way out. [email protected] and [email protected] both land in one Dovecot mailbox. Zero new storage, zero new outbound identity.
Forwarding. An alias *plus* an onward SMTP hop to an external destination — the alias catches the mail and re-injects it toward [email protected]. This introduces a second Return-Path, a new sending IP (the forwarder's), and the SRS problem we'll get to. Still inbound-only from your side: when you reply from Gmail, you reply *as Gmail*.
Masking / relay. Forwarding *plus* outbound reply rewriting. When you reply, the relay swaps your real address out of From, Return-Path, and Message-ID, then re-signs the message with its own DKIM key. Your real identity never reaches the far side. This is the only one of the three that does anything on the outbound path, and that one fact drives the rest of this piece.
Threat model: who are you actually hiding from
Pick the mechanism by the adversary you fear, not by the word on the pricing page. There are four distinct adversaries, and each mechanism scores differently against each.
1. The sender's own database and breach correlation. When shop.example gets breached — and it will — does the leaked address link back to your other accounts? Hand every service the same [email protected] and one dump correlates you across all of them. A unique alias per service breaks that link cleanly: the breach exposes [email protected], which appears nowhere else. This is the single highest-value privacy move most people never make, and *aliases alone* win it. Forwarding and masking inherit the benefit because they're built on aliases.
2. The sender reverse-looking-up or profiling you on delivery. A sender who wants to enrich your record queries the address against data brokers. A per-service alias defeats the trivial "same address across platforms" join; forwarding and masking add nothing beyond what the alias already bought you.
3. Reply de-anonymization. You reply, and your real address rides out in the outbound headers. This is the one that catches people. Only masking helps. Plain forwarding fails hard — the forwarder never touches your outbound path, so your reply leaves your actual mailbox with your actual From. If your threat model includes ever replying to the party you're hiding from, forwarding is not privacy. It's inbound routing.
4. Your own mailbox provider or a network observer. None of these encrypt content. All of them leak metadata — who's talking to whom, when, how often — to whoever operates the relay or forwarder. This is the trust shift: masking defeats the sender by handing full plaintext visibility to the relay operator. You didn't remove the observer; you swapped the sender for the relay. If the relay can be subpoenaed and that's your adversary, masking buys you nothing.
What leaks on the wire
Theory is cheap. Send a probe and read the source. A swaks one-liner delivers a controlled message so you can trace exactly what shows up:
Alias. Clean. To: shows the alias, Delivered-To: and X-Original-To: reveal which alias caught it, and everything else is your normal infrastructure. Nothing about your canonical address reaches the sender — but your outbound reply would carry your real From.
Forwarding. The tell is in the envelope. You pick up an extra Received: hop, and the Return-Path becomes SRS-encoded so bounces can route back:
That SRS0=HHH=TT=originaldomain=user@forwarder structure is a truncated HMAC (HHH) plus a base32 timestamp (TT), rewritten so the forwarder owns the envelope sender. SRS1 appears when an already-rewritten address is forwarded a second time.
Masking reply. On the outbound side, From: is rewritten to alias@relay, Reply-To/Return-Path point at a reverse alias, and the Message-ID domain is the relay's — not your real hostname. The classic leaks to audit either way: the Message-ID domain betraying your real MX, the DKIM d= betraying your real domain, User-Agent/X-Mailer fingerprinting your client, Autocrypt headers, and NDR bounces that helpfully quote your original recipient address back into the world.
The forwarding trap: SPF, DKIM, SRS, and DMARC
This is the section consumer blogs skip, and it's why "just forward it" quietly lands legitimate mail in spam.
When you forward, the forwarder's IP becomes the sending IP at the destination. The original domain's SPF record — v=spf1 include:_spf.example.com -all — does not list your forwarder, so a naive forward earns Received-SPF: fail and the bounce has nowhere to go. SRS fixes *that* by rewriting the envelope sender to the forwarder's own domain, so SPF now passes for the forwarder. But passing SPF for the forwarder is not the same as passing SPF *alignment* for the original From.
DMARC needs alignment, and alignment is the trap:
SPF alignment requires the Return-Path domain to match the From domain. After SRS, Return-Path is your forwarder — aligned to the forwarder, not the original From. SPF alignment fails for DMARC purposes.
DKIM alignment requires the signature's d= to match the From domain. This is the *only* path left for forwarded mail to pass DMARC.
And DKIM survives forwarding only if the signed content is untouched. The moment your forwarder appends a [EXTERNAL] subject tag or injects a footer banner, the body hash bh= no longer matches, the signature breaks, and your last DMARC pass goes with it. This is exactly why l= body-length limits — used by some setups to tolerate footers — are discouraged: they open a content-injection hole.
Net result: forwarded mail passes DMARC on a surviving DKIM signature, or not at all. Forward through anything that rewrites the body, and strict-policy senders' mail goes to spam. If you must forward, send it to a mailbox that re-signs, or use a relay that re-DKIMs.
Full masking done right
A proper relay — SimpleLogin, addy.io, Firefox Relay, Apple Hide My Email, or an evilmail-style setup — solves the reply problem with reverse aliases. When mail from [email protected] reaches you through shopping@relay, the relay mints a per-conversation address like [email protected] and sets it as your Reply-To. Your reply goes to that reverse alias; the relay maps it back to the original sender, rewrites From to your masked alias, and re-signs with the relay's DKIM selector so it aligns and delivers. Your MUA never talks to the real sender, and the sender never sees your real address.
Apple's implementation is the strict-but-narrow reference: Hide My Email only forwards to your Apple-linked mailbox and re-signs from icloud.com, which is why its deliverability is excellent and its flexibility is nil.
What still leaks even with perfect masking: your writing style, the time zone baked into your Date: header, any tracking pixel or remote image you load, and — the big one — the relay operator sees everything in plaintext. Masking defeats the *sender*. It fully trusts the *relay*.
Temp addresses vs persistent aliases — where evilmail fits
There's a fourth tool that isn't on the matrix because it changes the game structurally: the temp/disposable inbox. It's receive-only and ephemeral, with no outbound path at all. Reply de-anonymization is *structurally impossible* because there is no reply — but "the provider sees your mail" is guaranteed, and public temp inboxes are often guessable, so treat anything that lands there as world-readable.
Frame the choice by the *relationship*, not the feature list:
Disposable and reply-less — a one-time OTP, a download gate, a signup you'll never revisit: use a temp address. You never need to reply and you actively don't want a persistent link.
Ongoing but compartmentalized — a service you'll keep, that might email you for years: use a persistent alias, ideally a unique one per service so you can revoke it surgically.
Never use temp mail for account recovery. When the inbox evaporates, so does your reset link.
Decision checklist
Fear breach linkage across your accounts → unique alias per service. Log which alias each service got.
Need to reply without exposing yourself → relay/masking. Never plain forwarding — the reply leaks.
One-time OTP, no reply needed → temp address, then let it die.
Care about deliverability of forwarded mail → forward to a mailbox that re-signs, or use a relay that re-DKIMs. Assume plain forwarding fails DMARC unless DKIM survives intact.
Adversary can subpoena the relay → none of these. You need PGP for content plus a mailbox you actually control.
Operational hygiene → when an alias starts pulling spam, disable *that alias*, not your real address. Verify a mapping with postmap -q [email protected] /etc/postfix/virtual and audit your policy with dig +short TXT _dmarc.evilmail.pro before you trust any of it.
Match the mechanism to the adversary. An alias, a forward, and a mask are not three grades of the same product — they're three different tools, and the marketing word tells you nothing about which one you're holding.
