Masked Email Addresses Guide

When masked addresses help

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

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

When a recipient replies, Postscale routes the message back through the alias. 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.