Aliases, plus addresses and forwarding are different things
On narrow screens, scroll the table sideways.
| Term | Function | Limit |
|---|---|---|
| Mailbox | Stores messages; usually has its own sign-in or delegated access | An additional mailbox needs a distinct operational and access purpose |
| Alias | Additional recipient address that resolves to one or more other addresses | Need not stay within the same mail system; does not create a separate sign-in |
| Distribution group or mailing list | Distributes messages to several recipients; lists may change the reverse path and content | Not every simple alias expansion is a mailing list |
| Forwarding | Passes messages to another receiving destination | May affect SPF and DMARC; consider the reply route separately |
| Plus address | The provider interprets, for example, anna+shop@example.com as a variation of anna@example.com | The base address remains recognisable; the separator and ability to send depend on the provider |
| Catch-all | Accepts domain addresses that have not otherwise been individually configured | Catches typos, but also arbitrary invented recipients and additional spam |
| External alias service | Accepts mail at an alias address and forwards it to the actual mailbox | Adds an operator to the data flow; replies need its intended mechanism |
RFC 5321 section 3.9.1 describes alias expansion as replacing envelope recipients; the message may then be delivered or forwarded. With a list under section 3.9.2, by contrast, the reverse path for errors is changed to the list administrator. The product label “alias” does not guarantee that a provider means exactly the same function. RFC 5321 section 3.9, RFC 5598 section 5.1
The destination system interprets the local part before @. A plus sign is therefore not a universal feature of every address. RFC 5321 section 2.3.11, RFC 5233
ARC carries signed authentication information across intermediaries. BIMI concerns optional logo display. Neither creates your alias addresses or protects access to them.
Role addresses must match your services
Role addresses such as support@ or security@ remain stable when individual staff change. They need owners, cover arrangements, access rules and an inbox that someone actually handles. For shared access, a managed group or functional mailbox is often more suitable than copies sent to many personal accounts.
On narrow screens, scroll the table sideways.
| Address | Function and standards reference |
|---|---|
postmaster@ | SMTP operations. RFC 5321 section 4.5.1 requires it to be reachable on servers that relay or deliver mail; no blanket requirement for every parked null-MX domain |
abuse@ | Reports of inappropriate behaviour in the service offered, RFC 2142 section 4 |
security@ | Security reports, RFC 2142 section 4 |
hostmaster@ | DNS operations, RFC 2142 section 5 |
support@, sales@, info@ | Corresponding business functions, RFC 2142 section 3 |
RFC 2142 ties support for the names to the services offered. It defines no universal list of “five mandatory aliases for every domain” and does not replace RFC 822. An additional security.txt contact may facilitate security reports, but is a separate contact mechanism. RFC 2142 sections 1–6, RFC 9116
Native aliases: check reception and sending separately
A configured receiving address does not automatically mean your mail client can send or reply with it. Test the outgoing From, visible display name, Reply-To and the actual delivered headers. For important functional addresses, include cover arrangements and recovery in the test.
On narrow screens, scroll the table sideways.
| Environment | Documented detail as at 27 September 2026 | Implication |
|---|---|---|
| Microsoft 365 / Exchange Online | Additional aliases require no extra alias licence; Microsoft's admin help says 400, but service limits distinguish plans and a character budget. Sending as an alias is a separate organisation-wide setting and depends on the client. | No universal promise of 400; check the actual plan and client |
| Exchange Online plus addresses | Enabled for reception by default; Microsoft says these plus addresses cannot send | Do not plan a receiving filter as a separate sending identity |
| Google Workspace | Directory documentation states a maximum of 30 aliases per user; no aliases for guest users | Distinguish a user alias, a group and an independent account |
| Outlook.com | Aliases share one account; removing a Microsoft-domain address may be permanent | Check sign-in, recovery and dependencies before deleting |
| Other hosted mailboxes | Features depend on the offering, domain type, plan and user permissions | Use current provider guidance; do not carry over an old pricing matrix |
Sources: Microsoft aliases, Exchange limits, SendFromAliasEnabled, plus addresses, Google Directory, Outlook.com.
Announced Gmail change: Google says that “Send as” for third-party addresses such as Yahoo or Outlook is due to end from January 2027; Workspace aliases and other Gmail addresses you own are unaffected. Recheck this announcement before a transition that depends on it. Google: send from another address
Postfix: a mapping is not a complete setup
An excerpt for an already correctly integrated indexed virtual_alias_maps table might look like this:
# Excerpt from /etc/postfix/virtual — invented addresses
support@example.com anna@example.net
rechnung@example.com buchhaltung@example.netThese are external destination addresses; forwarding takes place. The domain must be configured as an appropriately managed alias domain, and the map integrated and updated with the backend appropriate to the installation. This excerpt does not configure a whole mail server. When replacing or extending an existing map, preserve existing mappings.
Indexed Postfix tables use the documented search order, not line position: this includes an exact user@domain match before user, before the catch-all @domain. Therefore, “put catch-all at the end of the file; Postfix reads from top to bottom” is wrong for hash and similar indexed tables. Regexp/PCRE tables have different rules. Postfix virtual(5), TABLE SEARCH ORDER
Local system aliases in aliases(5) are a different mechanism; changes there call for newaliases. owner-name may change the envelope sender for list handling. Do not confuse these files and their update commands. Postfix aliases(5)
Forwarding can change authentication
With external forwarding, the next recipient sees the forwarder's IP address. SPF for the original reverse path may then fail. A rewritten reverse path, for example using SRS, can make SPF pass for the forwarding domain, but does not automatically establish alignment with the original visible From domain. DKIM may survive if the signed parts are not changed in a relevant way. RFC 7960 section 3.2.1, RFC 7208 appendix D
ARC can convey an intermediary's incoming results. Whether the recipient trusts them is its decision. An alias service with ARC therefore does not guarantee freedom from DMARC problems. Test mailing lists, attachments, automatic replies and feedback from destination mailboxes in particular, where relevant to your use. A third-party forwarder does not automatically belong in the original sender's SPF record.
Use catch-all deliberately
Catch-all makes it easier to create new addresses, but harder to distinguish planned from invented recipients. A disabled individual address may still receive mail through a remaining catch-all. Conversely, disabling catch-all may cause an important address previously used only implicitly to disappear.
Postfix warns about additional spam and bounces. Accepting messages first and later generating non-delivery reports to forged reverse paths may cause backscatter. Explicitly managed recipients reduce this risk; actual acceptance and forwarding checks remain the server's responsibility. Postfix VIRTUAL_README
Before disabling it, inventory the addresses actually used, create them explicitly, and check reception and replies; only then remove catch-all. If errors occur, restore the specific missing mapping; an uncontrolled catch-all is a poor permanent substitute for a repair.
Choose external alias services by their actual data flow
An external service processes forwarded messages. Its address may shield your primary address from the service you contact, but does not make traffic anonymous and is not end-to-end encryption. Signature text, earlier quotations, contact cards or the wrong reply route may also reveal your primary address.
On narrow screens, scroll the table sideways.
| Example | Documented feature | Check before deciding |
|---|---|---|
| SimpleLogin | Forwarding aliases and custom domains; replies or new messages through a reverse alias | A reverse alias belongs to a specific contact; check actual plan limits, export and reply route |
| addy.io | Custom domains on paid plans; forwarding alone can be set up with MX, while outgoing sending needs additional authentication records | Reception verification is not full sending authorisation; avoid unintentionally redirecting an existing mail domain |
| Apple Hide My Email | Randomly generated addresses with labels and notes in the iCloud+ context; creation requires two-factor authentication | Check availability in your account, the destination address and deactivation; do not equate it with custom iCloud Mail aliases or every Sign in with Apple variation |
Sources: SimpleLogin FAQ, addy.io custom domains, Apple: manage addresses. These examples are not a ranking. Prices and allowances change; the feature descriptions reflect the stated source date.
A custom domain can make changing providers easier if you retain control of the domain and address inventory. It also increases responsibility for renewal, DNS and migration, however, and a shared domain can make several aliases linkable. Do not inadvertently switch a live mailbox domain's MX records to an alias service. A separate subdomain may separate responsibilities.
Which solution suits which task?
On narrow screens, scroll the table sideways.
| Task | Likely approach | What matters |
|---|---|---|
| Stable organisational role | Managed native alias or shared functional mailbox | Ownership, cover arrangements, correct sender address |
| Sorting your own newsletters | Plus address, if supported | The base address remains recognisable and is often reachable without the plus tag |
| Limit disclosure of your primary address to many services | Individual aliases that are hard to guess, potentially through an external service | Reply route, recovery and availability |
| Change providers while keeping the same addresses | Custom domain and exportable register | Domain ownership and complete migration |
| Particular confidentiality needs | Assess data flow and protection requirements first | Location or self-hosting alone do not prove suitability |
Unexpected use is an indication, not proof of origin
Spam sent to shop-7k2@example.com, which you assigned to just one shop, narrows your investigation. It does not prove that this particular shop sold or lost data. The address may have been guessed, collected from other correspondence, exposed to a participating provider or used differently in the past. With plus addresses, the tag can also easily be removed.
- Check the actual addressed recipient in a trusted delivery header; the visible
Toalone is insufficient, for example with Bcc. - Compare the alias register with possible disclosures or earlier use.
- Independently check notices from the affected service. A breach-database entry is a limited additional finding; an absent entry is not an all-clear.
- If you suspect compromised access, secure the account: check the password, active sessions, recovery routes and any reused credentials.
- Create a new alias if needed, change it in the service account first, and test sign-in, messages and recovery. Only then disable the old alias.
- Record the suspicion and its uncertainty. Do not assert that the service definitely caused it.
Have I Been Pwned can help research known data breaches. Submit only your own addresses or addresses you are authorised to investigate; this chapter promises neither complete database coverage nor free domain monitoring or a particular API plan.
Maintain an alias register and lifecycle
A small register in a suitable protected management system is often sufficient:
On narrow screens, scroll the table sideways.
| Field | Synthetic example |
|---|---|
| Alias and purpose | shop-7k2@example.com, orders at service A |
| Destination and owner | Personal mailbox, responsible person |
| Sending/replies | Reply only through the intended reverse alias |
| Dependencies | Sign-in, invoices, account recovery |
| Status | Active; latest own reception/reply check documented |
| Change | New address confirmed, old one disabled; no confirmed source of a leak |
The register itself may contain sensitive relationships. Restrict access and keep recovery data separate and secure. Protect the destination mailbox, alias service and registrar with suitable strong authentication. If all your aliases arrive in one account, a takeover of that account still puts all those messages at risk.
Schematic explanation · not a measurement
Several addresses, one mailbox to protect
Three services each receive their own alias address. All reach the same target account: separating addresses does not create separate account security boundaries.
Combine incoming mail
- Service A / B / C → alias A / B / C
Different addresses for each service.
-
Messages to the respective alias
Alias serviceThe forwarding provider is explicitly part of the data flow.
-
Shared forwarding destination
Protected target mailboxSign-in, recovery and access permissions affect every alias.
Route the reply back
- Target mailbox → reverse alias
Use the service’s designated reply route.
-
Through the intended return route
Alias service → original senderTest the visible sender address and replies in practice.
A direct reply may expose the main address. Unexpected mail proves use of the address, not the source of its disclosure.
Replace an affected alias
- Create a new alias
Document access and its assigned service.
-
New address available
Confirm it at the serviceChange the address stored there.
-
Change confirmed
Check reception and recoveryAccount for infrequent and security-related messages.
-
Required checks passed
Disable the old aliasOnly once necessary dependencies have moved; account for catch-all behaviour.
Changing addresses can limit risks; it does not prove a leak source or replace account protection.
Complete description of the flow
Three services use three different alias addresses, with arrows leading to the same protected destination mailbox. One alias receives unexpected mail; beside it is the label “indicates use of this address; source unproven”. Its replacement follows the sequence “create new alias → confirm at service → check reception and recovery → disable old alias”. The alias service is visible in the data flow. A reply arrow leads back through the intended reverse alias; a direct reply arrow carries the warning “may disclose primary address”. A frame around the destination mailbox makes clear that account protection affects all aliases.
Treat privacy and deletion separately
Disabling an alias may close a delivery route. It does not erase messages or relationships already stored at the service, or automatically withdraw consent given there. An alias may also be personal data and identifiable through additional information. The legal assessment of data flows, roles and provider relationships is covered in email compliance, not determined by the country in a provider's name.
What a public domain check cannot see
The Email Security Check reads public DNS and limited SMTP features. Known MX patterns may indicate a provider. It does not read an alias register, check role mailboxes, send a message or test catch-all acceptance. Even a recognised MX pattern does not prove which specific addresses exist or where they forward. Alias hygiene receives no separate security rating.
Frequently asked questions
Is an alias a separate account?
Usually not. It may point to the same mailbox with the same access and recovery routes. Check the provider's actual feature.
Can I reply from every alias address?
No. Receiving, sending as an alias and replying through a relay service are different features. Check a delivered reply of your own and its sender details.
Is a plus address enough for privacy?
It can help with sorting. The base address remains recognisable, however; it does not change provider rules or account security.
Does spam sent to one alias prove the source of a leak?
No. It shows unexpected use of that address. Establishing its origin requires further facts.
Should I delete an affected alias immediately?
First check sign-in and recovery at every dependent service. Some deletions are permanent. A controlled replacement is often safer.
Is catch-all insecure?
It is an operational choice with additional spam and bounce load. Recipient verification, the forwarding destination and an inventory of addresses actually used are decisive.
Does an external alias service make my messages anonymous?
No. The service, destination mailbox and people you communicate with may obtain information about you. The reply route and content may disclose your primary address.
Sources and next chapters
Sources as at 27 September 2026. The basis is the RFCs, Postfix manuals and provider guidance linked in the text. The Postfix example was checked only locally as an indexed table; no message was sent.
Further reading: MX and migration, SPF, DKIM, DMARC, ARC and gateways and phishing.