Email aliases, catch-all addresses and mailboxes: what changes when you reply?

Receiving mail at shop@example.com and replying as shop@example.com are separate capabilities. Start with the route you need, then decide how replies should work.

Compare receiving and identity

For the broader service choice, read forwarding, SMTP or a hosted mailbox.

Named aliases make routes explicit

Suppose you want hello@example.com and receipts@example.com to reach your existing inbox. Named aliases make those intended addresses easy to inventory and disable independently. A typo such as reciepts@example.com needs its own route or a catch-all to be accepted.

In a compatible client, a separate outgoing identity for hello@example.com can select that From address and an authorized SMTP service. Receiving the forwarded message does not ensure that the client selects this identity when you press Reply. Check the outgoing From field and the result at another inbox.

Catch-all trades convenience for a larger intake

A catch-all can receive new local parts without creating a named alias for each one. It can also admit typo traffic and guessed addresses you never intended to use. Monitor volume, spam and destination capacity before using it on a public domain. See catch-all configuration for the supported routing model.

If a message arrives for invoice-184@example.com, that does not create a mailbox or client identity called invoice-184. A new message using that From address still needs to satisfy the sending service's domain and account rules. Decide whether you need many outgoing identities or only a stable reply address.

MX applies to the entire hostname. It cannot direct one local part to Postscale and another to a different mailbox host by assigning different MX priorities. Use explicit forwarding at the receiving service, or separate receiving subdomains, when your architecture calls for different destinations.

Plus tags are not private aliases

A plus tag often exposes the base address: alex+shop@example.com makes alex@example.com easy to infer. A site's acceptance of the tag, your provider's subaddress handling and your client's reply identity are separate questions. Test them before using tags as an address-management strategy. Do not treat a tag as an independently revocable privacy boundary unless the provider enforces it.

Shield has a different reply path

Shield creates masked addresses and inserts a tokenized Reply-To into forwarded messages. Supported replies through that address can be sent using the alias. This differs from a normal domain alias whose user sends through SMTP directly. Read the Shield API and masked-address guide for its limits and lifecycle.

Before relying on masking, inspect Reply-To and test a complete conversation. Signatures, quoted text or attachments can reveal identifying information even when the visible sender is an alias. SRS is another separate mechanism: it routes delivery failures, not human replies. See SRS and forwarding.

Count traffic as well as addresses

Plan allowances govern active aliases and domains; catch-all coverage is not a promise of unlimited traffic. Postscale shares the monthly email allowance between sending and receiving. Check plan allowances and inbound limits for your expected volume.

Test the identity you intend to use

Send to a named address, then an otherwise unmatched address if you use catch-all. Confirm each destination. Compose a new message and reply to a received one; check the correspondent's From, Reply-To and actual reply destination. Confirm where sent copies are stored and that your original mailbox identity still works.

Use SMTP connection settings for outgoing configuration. When your address choices are settled, review DNScale automatic setup or manage existing routes through the inbound routing documentation. Before changing receiving MX, prepare each address you need and configure catch-all explicitly if you want it.