Masked Email Addresses Guide

When masked addresses help

This guide covers Postscale Shield for application-managed privacy aliases. Ordinary forwarding on your own domain has a different reply workflow: your mail client needs an authorized outgoing identity. It does not automatically receive Shield's tokenized Reply-To behavior. See the Shield API and SMTP reference for the respective settings.

Masked addresses are useful when two parties need to communicate but should not know each other's real inboxes.

Examples:

1. Marketplace buyer and seller messaging.
2. Patient and provider communication.
3. Creator or community replies.
4. Support intake for privacy-sensitive products.
5. Trial accounts that should not expose personal addresses to vendors.

Model aliases by relationship

Choosing routes for your own domain? Compare named aliases, catch-all and mailboxes before deciding which reply behavior your users need.

Prefer one alias per relationship or workflow:

seller-8392-buyer-1847@shield.example.com
case-20491@shield.example.com
trial-vendor-77@shield.example.com

This lets you disable one relationship without breaking every other conversation for the same user.

Preserve reply context

For Shield aliases, Postscale adds a tokenized Reply-To address to forwarded messages. Replies through that address can be routed back using the alias. Check the actual Reply-To and test the return path; do not assume an arbitrary reply from the user's real address will be masked. Your application should store:

1. Alias id.
2. External participant.
3. Real recipient address.
4. Thread id or business object id.
5. Current alias status.

Use that state to decide whether to forward, store, reject, or moderate replies.

Control abuse

Masked addresses reduce exposure, but they still need controls:

1. Rate-limit new aliases.
2. Disable aliases after reports.
3. Block known abusive senders.
4. Log moderation actions.
5. Give users a way to stop forwarding.

Do not rely on address secrecy alone. Treat aliases as part of an abuse-control system.

Retire aliases cleanly

An alias should have a lifecycle:

1. Created.
2. Active.
3. Paused.
4. Disabled.
5. Deleted or retained for audit.

Keep the lifecycle visible in your product so support teams can explain why a message was or was not forwarded.