Two-way reply forwarding is the mechanism that lets a reply to a forwarded email leave from the alias address instead of the real address. The mechanism operates inside the forwarding service rather than inside the mail client: the forwarded message carries an encoded reply address, the reply travels back through the service, and the service re-sends it from the alias. AliasFleet documents the mechanism in its reply and threading guides, and the same encoded-address pattern appears in the documentation of addy.io and SimpleLogin.
The encoded reply address
A forwarded message arrives in the destination inbox with its Reply-To header rewritten to an encoded address. In the AliasFleet documentation the example takes the form alias+sender=company.com@yourdomain.com, where the alias identifies the receiving identity and the encoded portion identifies the original sender. When the user clicks Reply, the mail client sends the response to that encoded address instead of to the original sender, and the forwarding service receives it first. The service decodes the address, checks the destination permissions, replaces the personal address with the alias identity, and delivers the reply to the original sender. The recipient sees the alias in the From field, and the real address does not appear as the sender.
The routing depends on the reply being a reply to the forwarded message. A new compose carries no encoded reply address, so it does not route through the alias, and the service treats it as an ordinary message from the real address. A new conversation from an alias starts through a different route: the in-app Quick Send composer, or a relay address of the form alias+recipient=domain.com@yourdomain.com sent from a mail app. In both cases the service assigns a clean domain Message-ID to the outbound email, so no originating identifiers from the personal mail provider enter the message.
Threading
Email clients group messages into one thread when the reply carries headers that reference earlier messages in the chain and the subject matches apart from prefixes such as Re: and Fwd:. The grouping mechanism is defined by RFC 5322: each message carries a unique Message-ID header, and a reply adds In-Reply-To, which holds the Message-ID of the message being answered, and References, which holds the Message-IDs of the full chain in order. AliasFleet preserves both headers on forwarded mail and on replies, so clients such as Gmail, Apple Mail, and Outlook can rebuild the chain and display the exchange as a single conversation.
The thread breaks when either condition fails. A reply with a rewritten subject does not match the base subject, so the client opens a separate thread, and a new compose carries no In-Reply-To header, so the client cannot attach it to the existing thread. The AliasFleet documentation records both cases as properties of the threading mechanism rather than as errors in the reply itself. A split caused by the other party changing the subject, or by a client that groups by subject only, cannot be rejoined from the forwarding side, and the conversation continues from the newest message.
Permission modes
Reply forwarding is gated by two settings, one on the destination and one on the alias. The destination carries a Can Reply toggle, which is available only after the destination inbox is verified, and a greyed out toggle means verification is still incomplete. Without Can Reply enabled, a reply to a forwarded email is sent from the real address rather than the alias. The alias carries a permission mode that decides which destinations can reply through it: in Strict mode only the destination the alias is directly assigned to can reply through that alias, while in Open mode any destination with Can Reply enabled can reply through it. A reply that still shows the real address has Can Reply off for the destination used, a permission mode that blocks that destination, or a message that was a new compose instead of a reply to the forwarded email.
Authentication
Every forwarded email and outbound reply routed through AliasFleet carries three mechanisms that keep authentication intact across forwarding. DKIM oversigning under RFC 6376 section 8.15 signs headers that a downstream relay could otherwise add or alter, which guards against downstream spoofing and header injection. ARC sealing under RFC 8617 preserves upstream authentication results across multi-hop relays, so a forwarder in the chain does not break the authentication record. Sender Rewriting Scheme rewriting of the envelope sender keeps SPF alignment intact when mail passes across external mail providers. The service also removes the personal IP address, origin headers, and real email address before sending, and signs the outbound reply with domain-aligned DKIM.
Other implementations
The encoded-address pattern is not specific to one service. The addy.io documentation describes forwarded mail whose From header encodes the sender and the receiving alias, in the form shop+hello=store.com@johndoe.addy.io, and states that a reply goes to that address, is decoded by the service, and is delivered from the alias. The same documentation states that replying from an alias requires a Lite or Pro subscription and is not included on the Free plan. SimpleLogin documents a different shape of the same mechanism: a reverse-alias is created for each contact, and mail sent to the reverse-alias is delivered from the alias, with the feature available only on paid plans.
Top comments (0)