Email sent over a VPN: where the reply actually goes

You send a message through the tunnel, disconnect, and the reply arrives the next morning. Nothing about that needs the old VPN address, and nothing about it breaks. Email does not route replies to the address a message was sent from; it routes them to a mailbox. Three paths get collapsed into one question here, and separating them answers most of the worry.

Three paths that people collapse into one

Submission, delivery and reading are three separate connections, and only two of them involve your device.

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

The VPN can affect the first and the third, because those are connections your device makes. It cannot affect the second, because that path runs between two mail servers you do not control. A reply is not a packet returning to the address you sent from. It is a new message that the other side's mail service delivers to your mailbox service.

Once you hold those three apart, the question of whether the reply finds you stops being mysterious.

A Reply-To field is an address, not a route

RFC 5322 defines Reply-To as the mailbox or mailboxes that replies should be sent to. Without it, the usual default is the From mailbox, unless the person replying types something else. Both are mail addresses sitting in a header. Neither is an instruction to reopen the network connection that submitted the original message.

This is why a VPN exit address never appears in the reply path. Even when the submission server recorded that exit address somewhere, the reply is addressed to a mailbox, and the sending server looks up the domain's mail exchanger rather than your old socket.

If a reply goes somewhere unexpected, read Reply-To and the sender's own client settings before you suspect the tunnel.

What the trace headers actually record

Each SMTP hop prepends a Received header describing the connection it handled, and the topmost one is the last hop before delivery. A submitted message can therefore carry network details worth reviewing, and those details are written by servers rather than chosen by you. What they contain depends on the provider's submission architecture and its header handling.

Read them instead of guessing, from a saved message:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

The useful discipline is identifying which trusted service added each field. Arbitrary text earlier in the header block is not reliable evidence, and a product name is not a permanent promise that your home address is always present or always absent.

Reading mail later is a new connection

When you open the reply, your client connects to your mailbox service over whatever network you are on now. That is a fresh connection with its own source address, not a continuation of yesterday's submission socket. It follows the current policy of the network you are using at that moment.

Remote content is a third thing again. A mail client that loads a remote image or follows a link makes a separate request under its current settings, and that request can carry whatever identifiers the message embedded. It is not the SMTP reply arriving at an old address, and treating it as one hides the real exposure.

Turn off remote content if you want to read a message without announcing that you opened it.

What to check before you call it a leak

Start with the original message view and the Reply-To field. Then identify which service added the Received entries that worry you, and compare that with the provider's current documentation rather than an old forum answer.

Finally, separate the questions: what did the submission server observe, what did the delivery chain add, and what did your client request when you opened the message?

Answering those three separately is more work than checking an IP page, and it is the only version that produces a conclusion you can defend. Replying to an email address does not reveal your home address, and it does not require the old tunnel to stay up.