Email aliases, in one screen
Almost every guide defines an alias as “a second address that forwards to your inbox.” That sentence merges four different mechanisms that fail in four different ways. Here is the short version.
| What an alias is | A routing entry on the receiving server that points a second address at an existing mailbox |
| What it is not | An account, a mailbox, a password, a licence, or a sending identity |
| DNS changes needed | None. The domain’s MX record already points at the mail host; the alias lives inside it |
| SPF, DKIM, DMARC | Untouched. Those authorise sending, and an alias only affects receiving |
| Sending from it | A separate feature that has to be configured on its own, and is missing on some providers |
| When you delete one | Mail to that address bounces as unknown, immediately and permanently |
Email aliases are the cheapest structure you can add to a mailbox. One user, one licence, one password, and as many addresses as the provider allows: sales@, billing@, hello@, a throwaway for a signup form, a separate address for a side project. Nothing is duplicated and nothing is paid for twice.
The confusion starts with the definition everyone repeats. Proton, Wikipedia, GoDaddy and Google’s own help centre all describe an alias as an address that forwards messages to your primary inbox. For a consumer masking service that is literally true. For an alias on your own domain it is not, and the difference decides whether your mail passes authentication, whether verification tools can see the address, and whether a reply exposes the account behind it.
An alias is a routing rule, not an account
When mail arrives for billing@yourdomain.com, the receiving server looks the address up in its own directory before it accepts anything. If the address maps to a mailbox, the server accepts the message and files it there. That map entry is the alias. There is no second delivery, no second server, and no second copy of the message.
Three consequences follow, and each one answers a question people ask constantly.
No DNS record is involved. Adding an alias never requires a new MX, TXT or CNAME entry. The domain’s MX already sends mail to the host, and the alias is created inside that host’s user directory. If a tutorial tells you to publish a DNS record to create an alias, it is describing something else.
No authentication record changes. SPF authorises the servers allowed to send for your domain, DKIM signs outgoing messages, and DMARC checks alignment between them. All three describe outbound mail. An alias is an inbound routing rule, so none of them need editing when you add one.
No storage is added. The alias shares the mailbox, the quota and the password of the account behind it. That is the whole point, and it is also the reason aliases are not a way to give a second person their own mail.
Alias, forwarding, masked address, plus addressing
Four mechanisms are sold under the same word. They behave differently at the protocol level, so choosing the wrong one produces problems that look inexplicable later.
| Mechanism | What actually happens | Main limitation |
|---|---|---|
| Alias | The receiving server maps a second address to an existing mailbox. One hop, one delivery. | Lives only on that provider. Sending from it is a separate setting. |
| Forwarding | The message is accepted, then sent again to an address somewhere else. Two hops, two deliveries. | The second hop is sent by your server, not the original sender’s, which is why forwarding breaks SPF unless the forwarder rewrites the envelope. |
| Masked address | A third party accepts mail at a random address and forwards it to you. Same two hops as above, on somebody else’s infrastructure. | Filters treat these ranges the way they treat disposable addresses, and some signup forms reject them outright. |
| Plus addressing | No configuration at all. Gmail and several other providers deliver you+anything@ to the same mailbox as you@. | The tag is visible and trivially removed by anyone who wants your real address. Useful for filtering, useless for privacy. |
A fifth case sits next to these. A catch-all address accepts every address on the domain rather than a defined list. It is not an alias, it is the absence of one, and it changes how the domain behaves for everyone who mails it.
Receiving is free, sending is a separate problem
This is where most people get caught. Creating an alias makes the address reachable. It does not make it usable as a From address, because sending is handled by a different part of the system entirely.
Gmail requires you to add the address under the send-as settings before it appears in the From selector. Microsoft 365 exposes the same split: an administrator adds the address to the user in one place, and whether it can be selected as a From address depends on the account settings rather than on the alias itself. Some providers do not support sending from an alias at all, in which case the address receives perfectly and simply cannot be chosen when composing.
The failure mode is quiet and embarrassing. A reply that goes out from the account rather than from the alias tells the recipient exactly which mailbox is behind hello@, which is usually the one thing the alias existed to avoid. Test it once, in both directions, before you print the address anywhere.
Worth knowing before you plan around it. Google states that a Workspace user supports up to 30 aliases and that a new alias can take up to 24 hours to start working, though it usually works sooner. The full click path is in our guide to creating an email alias in Google Workspace. Other hosts set their own ceilings, and those ceilings are one of the real differences between plans rather than a technical limit; our breakdown of what each business email hosting plan actually lets you do compares them.
Four places aliases break
Deleting one turns a working address into a hard bounce
The moment the routing entry disappears, the receiving server stops recognising the address and rejects mail for it. The sender gets a 550 5.1.1 user unknown response, permanently. If the alias was ever printed on an invoice, a business card or a website footer, that mail is now gone rather than delayed. Retire an alias by leaving it in place and filtering it, not by deleting it.
Nobody outside can tell an alias from a mailbox
At SMTP time an alias answers exactly like a real account, because to the server it is a real address. That is fine until someone runs a list check against it. Email verification can confirm that the address is accepted and can say nothing about who reads it or whether anyone still does. An alias pointed at a mailbox nobody opens verifies as valid and behaves as a dead address, which is how a clean list still produces silence.
Role addresses attract different treatment
Addresses such as info@, admin@, sales@ and support@ are the classic use for an alias, and many mailing platforms suppress them on purpose because they usually reach more than one person and generate complaints. Using one as the destination for a marketing signup often means the subscription silently never arrives.
An alias for each person is the wrong tool
Aliases point at one mailbox. If two people need to see what arrives at support@, an alias gives them a shared password and no way to tell who answered. That is a group or a shared mailbox, which every serious provider offers separately, and it is worth the extra step.
How to create an email alias
The mechanics are similar everywhere because the underlying object is the same. The address is added to an existing user, not created as a new one.
- Find the user, not the mail settings. On Google Workspace the alias is added in the Admin console on the user record, under alternate email addresses. On Microsoft 365 it is on the user in the admin centre, in the section that manages usernames and email addresses. On a consumer Outlook.com account it sits in the Microsoft account settings rather than in the mailbox.
- Add the address on a domain the account already hosts. An alias can only be created on a domain the provider already accepts mail for. Adding a new domain first is a separate operation with its own verification.
- Wait for propagation before you test. Directory changes are not always instant, and a failed test five seconds after saving proves nothing.
- Configure sending separately, if you need it. Add the alias as a send-as identity and send one message from it to an outside address.
- Set the filter before you publish the address. The value of an alias comes from mail arriving pre-sorted. A rule that labels everything addressed to that alias takes ten seconds while you are already there.
When an alias is the right answer
Use one when the mail has a different meaning but the same reader: a function that should outlive the person doing it, a project that needs its own address, a signup you want to be able to trace back. Use one when you want to look bigger than one inbox without paying for accounts nobody reads.
Reach for something else when the mail has a different reader, when two people need to answer it, when the address needs its own storage or its own password, or when the address must keep working after you stop wanting it. Those are accounts, groups and shared mailboxes, and an alias used in their place fails quietly rather than loudly, which is worse.
Frequently asked questions
What is an example of an email alias?
billing@yourcompany.com pointed at the mailbox of the person who handles invoices is the standard example. Mail sent to the alias lands in that person’s inbox with no forwarding step, and the address survives if someone else takes the job over.
What are the disadvantages of email aliases?
They share one mailbox, one quota and one password, so they cannot separate people. Sending from them needs separate configuration and is not always possible. Deleting one makes mail to that address bounce immediately. And because an alias is invisible from outside, nobody mailing it can tell whether anyone still reads it.
Can you send email from an alias?
Usually yes, but never automatically. The address has to be added as a sending identity in the mail client or the provider settings before it appears as a choice in the From field. Some providers do not offer this at all, in which case the alias can only receive.
Is an email alias the same as email forwarding?
No. An alias is delivered once, by the server that accepted it. Forwarding accepts the message and then sends it again to another address, which is a second delivery from a different server and the reason forwarded mail can fail SPF checks at the final destination.
Do email aliases need their own SPF or DKIM record?
No. SPF, DKIM and DMARC apply to outbound mail sent for a domain. An alias is an inbound routing rule on an existing mailbox, so adding one requires no change to any authentication record and no DNS entry of any kind.
What happens to mail sent to a deleted alias?
It bounces. The receiving server no longer recognises the address and rejects it with a permanent unknown-user error, so the message is returned to the sender rather than delivered late. There is no grace period unless the provider explicitly offers one.
Are Gmail plus addresses the same as aliases?
Not quite. A plus address needs no setup because everything after the plus sign is ignored during delivery, which makes it excellent for filtering and for spotting who leaked your address. It is not a privacy tool: removing the tag to recover the underlying address takes one second, and many forms strip it automatically.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
