Proxy addresses and email aliases in Exchange Online

Every Exchange Online mailbox answers to a list of addresses, not just one. That list — the proxy addresses on the recipient object — is behind a whole family of everyday admin questions: "can Anna also receive mail as anna@oldbrand.com?", "why does mail to a.svensson@ bounce after the rename?", "why does the user sign in as one address but send as another?". Understanding one attribute clears up all of them.

The model

Each mailbox (and group, and shared mailbox) carries an EmailAddresses collection — in the directory, the proxyAddresses attribute. Entries look like:

SMTP:anna.svensson@contoso.com     ← primary (capital SMTP)
smtp:anna@contoso.com              ← alias
smtp:anna.svensson@oldbrand.com    ← alias from the old domain

The capitalisation convention is load-bearing: SMTP: in capitals marks the primary address, lower-case smtp: entries are secondary aliases. There is exactly one primary. Every address in the list receives mail into the same mailbox; the primary is what recipients see on outbound mail by default. A proxy address is simply any of these entries — the primary is technically one too, though in practice people use the word for the aliases.

Two properties follow from this model and answer most support tickets:

• Aliases receive; the primary sends. Mail to any listed address lands in the mailbox. Replies and new mail go out stamped with the primary — unless the user explicitly sends from an alias (more below).
• Addresses are unique tenant-wide. An address can exist on exactly one recipient. The "this address is already in use" error means some object — a user, a group, a shared mailbox, a soft-deleted mailbox in its retention window — already holds it. Get-Recipient -Filter on the address finds the culprit, including the non-obvious ones.

UPN vs primary SMTP: related, not the same

The User Principal Name — what the user types to sign in — is a separate attribute from the primary SMTP address. Nothing forces them to match. Everything gets easier when they do: users understand "your email is your login," Teams and calendar sharing look consistent, and support calls drop. Make matching them a standard, but know the distinction exists — after acquisitions and domain migrations you'll meet tenants where sign-in and email diverge, and "which one do you mean" becomes the first question of every troubleshooting session.

Managing addresses

In the admin centers: Microsoft 365 admin center → user → Manage email aliases, or the Exchange admin center's mailbox properties. In PowerShell, the pattern that adds without clobbering:

Set-Mailbox anna.svensson -EmailAddresses @{add="anna@contoso.com"}

The classic mistake is -EmailAddresses "anna@contoso.com" without the add-syntax, which replaces the whole list. Use the add/remove hashtable form in scripts, always.

Behind the scenes, email address policies can stamp addresses on recipients automatically from a template (firstname.lastname@domain). In Exchange Online these apply to groups rather than user mailboxes, so most tenants stamp user aliases at provisioning time — make alias conventions part of the joiner automation rather than a manual afterthought.

Sending from an alias

For years the answer to "can I send as my alias?" was "no, buy a shared mailbox." That changed: Exchange Online now supports sending from aliases once the tenant enables it (Set-OrganizationConfig -SendFromAliasEnabled $true). With it on, Outlook and Outlook on the web let users pick any of their own addresses in the From field, and the message goes out genuinely stamped with the alias — not rewritten to the primary.

Where the requirement is a role address (support@, info@) used by several people, aliases remain the wrong tool — that's a shared mailbox with Send As permissions, which also gives you a separate mailbox, its own automatic replies, and delegation. Rule of thumb: one human with several identities → aliases; several humans behind one identity → shared mailbox.

Rebrands, acquisitions, and hybrid — where this attribute earns its keep

Domain changes are proxy-address projects. The safe pattern for a rebrand: add the new domain, add new-domain addresses as aliases to everyone (nothing breaks — old mail still arrives), flip primaries to the new domain in a controlled wave, and keep the old-domain aliases for years. Old addresses live in signatures, supplier systems, and password-reset flows for far longer than anyone expects; removing them is the last step, not an early one, and often never worth doing at all.

In hybrid environments, one more rule dominates: the source of authority is on-premises Active Directory. If Entra Connect synchronises a user, edits must be made on the on-prem object's proxyAddresses attribute and synced up — the cloud attributes are read-only, and the Exchange admin center will tell you so. The related classic bounce: a synced user missing the @tenant.mail.onmicrosoft.com routing address breaks hybrid mail flow — the Hybrid Configuration Wizard's email address policy exists to prevent exactly that.

A short operational checklist

• Standardise: UPN = primary SMTP, one documented alias convention, stamped at provisioning.
• Never remove an address that ever received external mail without a deprecation period — measured in years, not weeks.
• In scripts, only ever add/remove; never assign the full list.
• When an address "already exists", check groups and soft-deleted mailboxes before doubting the error.
• In hybrid, edit on-prem, sync, verify — in that order.

It's a humble attribute, but it routes every message your organisation receives. Treat the address list as managed configuration rather than per-ticket improvisation, and an entire category of email mysteries disappears.