You handed a site a masked address, the confirmation mail arrived, and nothing about your real mailbox was disclosed. Then a person writes back with a question you need to answer, and you do the ordinary thing. You hit Reply. That keystroke is where most masking arrangements come apart, because everything before it ran in one direction and the reply does not.
The asymmetry is structural rather than a flaw in any particular product. Forwarding is delivery, not a conversation held open. Mail addressed to your alias is accepted by the forwarding service, re-addressed, and dropped into a mailbox that has its own name, its own provider and its own outbound path. Your mail app never learns that any of this happened. A message arrived, and a reply goes out the way all your replies go out, from you.
What follows is the mechanism that closes the gap, what the person on the other end can and cannot see afterwards, and one exception that is not a bug and will not be engineered away. One distinction carries most of the weight. Answering a message that reached you through an alias needs no setup at all. Starting a fresh conversation as that alias needs real setup. The two feel identical and are not.
Where the mask slips
Consider what your client actually does when you reply. It composes a new message. The recipient comes from the incoming mail, which is correct and harmless. The sender comes from the account the mailbox belongs to, which is you. Both the envelope address your provider uses to hand the message over and the From line the recipient reads name your real mailbox, and nothing you type in the body changes that.
A reply therefore performs an introduction you did not intend, and a persuasive one. The recipient now holds an address that no leak or broker gave them. You supplied it yourself, in answer to their own message, which is the most credible way an address can arrive. It also happens silently. Nothing warns you, and the copy in your sent folder looks entirely normal.
How a reverse alias works
The fix uses a header field that predates masking by decades. RFC 5322 describes Reply-To as indicating the address to which the author of a message suggests replies be sent, and says that when the field is absent, responses default to the sender's mailbox. Mail clients honour that. A forwarding service that wants to keep you out of the reply simply supplies the field.
On the way through, the service rewrites the reply path on the forwarded copy, and usually the visible sender too, to an address it controls. Some services mint that address per pairing, your alias and that one correspondent. Others, Firefox Relay among them, publish a single shared reply address and work the pairing out from the message itself. It tends to look like a block of random characters, or an encoded form of the sender's address, at the service's own domain.
When you hit Reply, your client reads the header and addresses your answer to the service. That first hop is an ordinary message from your real account to a server that already knows who you are, so nothing is given away. The service confirms the reply came from the owner of the alias, discards the envelope and the headers that name you, sets the visible sender to the alias, signs the result on the alias domain so it authenticates, and relays it onward.
Two properties matter. There is no configuration, because the intelligence sits in the message rather than in your client, so it works in webmail, in Apple Mail, in Thunderbird and on a phone. And it is scoped to one conversation. Apple and Mozilla build the same behaviour into their own mask features and describe it in similar terms. If the vocabulary is new, start with what an email alias is.
What the recipient sees, and what they never do
Assume the relay is competent. Here is what lands in the other person's client:
- Your alias in the sender line, and the alias again if they reply.
- Your subject, your words, your attachments, and the time you sent them.
- Received lines added by the relay, naming the relay rather than your provider.
- Whatever display name the relay chose to put on the message. Some replace yours. Some pass it through, which quietly hands over your full name.
What they should never see is the address of the mailbox you read, the name of your provider, the IP address you connected from, or a message identifier minted on your provider's domain. That last one is easy to overlook, since identifiers of that kind are generated by whoever sends the message and habitually carry the sending host's domain inside them.
The relay controls headers. It does not control what you type. A signature block with your full name and mobile number, a stock line about being sent from a phone, a PDF whose properties carry your name, or a quoted message from a different account will all travel through untouched.
Reply all is the documented exception, and it is not a small one
Reply sends the message to the sender. Reply all sends it to the sender and to everyone in the To and Cc lines, which is how Google's own help pages define the two buttons. The rewrite only ever touched one address, the path back to the sender. Everyone else on the thread is sitting in your mail app as an ordinary address, exactly as it was written.
So Reply all builds one message addressed to the reverse alias plus those plain addresses, and your provider delivers to the plain ones directly, from your account. The original sender sees your alias. Every other person on the thread sees your real address, in the same message, at the same moment. The same applies to anything you add to Cc or Bcc yourself. Mozilla states it plainly in the documentation for its own mask product: adding a Cc or Bcc when you reply exposes your original address to the recipient and to everyone copied.
This is a property of the design, not a defect in one implementation. A relay can only rewrite what passes through it, and mail you address to a third party never does. The protective habit is small. Before sending any reply on a masked thread, read the recipient row. One address, belonging to the forwarding service, means send. Anything else means delete the extras or do not send. If a service claims it rewrites every address on a thread, verify that once against an address you control rather than taking it on trust.
Starting a new conversation is a different job
Replying is free because the inbound message did the work. The token in the reply path exists only because something arrived first, and it records which alias and which correspondent. Compose a fresh message and none of that exists. There is no thread to infer the alias from and no correspondent on file.
Sending as an alias from cold therefore needs the other half of the machinery. With a third-party forwarding service that means an authenticated submission path. Where the mask and the mailbox belong to the same provider, as with Apple's Hide My Email, the From menu already offers it. Your mail app connects to the service's outgoing server, usually on port 587, with credentials issued for that specific alias. Then the visible sender really is the alias, the message is signed on the alias domain, and the receiving side sees SPF and DMARC line up. In practice you add the alias as a second sending identity, which Gmail calls Send mail as. Outlook is fussier: Microsoft removed connected accounts from Outlook.com on the web, so the alias has to be added as an account in the desktop or mobile app instead. There are step by step versions for Gmail and Outlook.
That is configuration, and it is per alias. The inference to avoid is that because replying needed nothing, sending must need nothing either. Aliases on a domain you own are easier to reason about here, since the sending domain is already yours.
What a service should strip on the way out
If you would rather judge a service than believe it, this is the list. On the outbound leg of a masked reply, a careful relay removes or replaces:
- Return-Path, Sender, Delivered-To and X-Original-To, any of which can carry the mailbox you actually read.
- The Received lines added while the message travelled from you to the relay, plus X-Originating-IP and its equivalents. Some providers strip the client IP as policy, others keep it deliberately for administrators, so assume nothing.
- The message identifier your provider generated, replaced with one minted on the relay's own domain.
- The DKIM signature and authentication results from your provider. Rewriting the sender invalidates the old signature anyway, and the signing domain names your provider.
- Disposition-Notification-To and Return-Receipt-To, the fields that request a read receipt. They name a mailbox to notify, and untouched that mailbox is yours.
- User-Agent and X-Mailer, which identify your client, and the display name attached to your sending account.
References and In-Reply-To are the awkward pair. They have to survive or threading collapses at the far end, yet they contain identifiers minted on your provider's domain, so a relay that has thought about it keeps a mapping and rewrites them.
Checking takes a couple of minutes. Reply through a masked thread to an address you control, open the received copy, and use your client's view source or show original command. The list above says what should be missing, and anything of yours still present is a finding rather than a suspicion. The same habit is worth applying to tracking in incoming mail.
When the right answer is not to reply
A masked reply is not free of consequence. Any reply confirms the address is live and that a person reads it. If the sender is a stranger who found the address in a breach dump, silence tells them less than a polite masked refusal does, and costs nothing. If the correspondence will run for months and involve people who add each other to threads, an alias is the wrong shape for the job and a separate mailbox is a better fit. Retiring an address that has become a liability is still an option, and usually the cheapest one.