How to Set Up a Vanity Email Address in Microsoft 365 (Exchange Online)

A vanity email address is a friendly, memorable address — like hello@contoso.com or sales@contoso.com — that delivers mail into an existing mailbox or group instead of having a mailbox of its own. This guide covers every way to set one up in Exchange Online, how to test it, common errors, and the edge cases (send-as, external targets, new domains).

All names, domains, and addresses in this article are examples.

---

How It Works

The cleanest way to implement a vanity address is not forwarding at all. If the address is on a domain your tenant already owns, you simply add it as a secondary SMTP proxy address (alias) on the target object. Exchange then delivers mail sent to the alias natively — no extra hop, no rule to maintain, nothing to break later.

Which cmdlet you use depends on what kind of object the target is, so identifying that is always the first step.

Before you start, decide three things:

1. The vanity address — and whether its domain is already an accepted domain in the tenant.
2. The target — the existing mailbox or group it should deliver to.
3. Incoming only, or send-as too? An alias handles incoming mail only. If outgoing mail must also show the vanity address as the sender, see the Send-As section — it changes the design.

---

Step 1: Connect and Verify

Connect-ExchangeOnline

Check the vanity address is not already in use. Email addresses must be unique across the entire tenant — mailboxes, groups, contacts, everything:

Get-Recipient hello@contoso.com

You want this to fail:

Get-Recipient: The operation couldn't be performed because object
'hello@contoso.com' couldn't be found on '<server>'.

"Couldn't be found" means the address is free. If an object comes back instead, stop and investigate what owns it.

Identify what the target is:

Get-Recipient support-team@contoso.com | fl Name,RecipientTypeDetails

The RecipientTypeDetails value decides everything:

RecipientTypeDetails	Object type	Cmdlet to use
MailUniversalDistributionGroup	Distribution list	Set-DistributionGroup
GroupMailbox	Microsoft 365 Group	Set-UnifiedGroup
SharedMailbox	Shared mailbox	Set-Mailbox
UserMailbox	A person's mailbox	Set-Mailbox
DynamicDistributionGroup	Dynamic DL	Set-DynamicDistributionGroup
MailContact / MailUser	External-pointing object	See "External Target" below

Tip: don't rely on the plain Get-Recipient table output — its RecipientType column shows UserMailbox even for shared mailboxes. Always check RecipientTypeDetails.

---

Step 2: Add the Vanity Address as an Alias

Pick the command that matches the object type:

# If it's a Distribution List:
Set-DistributionGroup -Identity "support-team@contoso.com" -EmailAddresses @{add="hello@contoso.com"}

# If it's a Microsoft 365 Group:
Set-UnifiedGroup -Identity "support-team@contoso.com" -EmailAddresses @{add="hello@contoso.com"}

# If it's a shared mailbox (or a user mailbox):
Set-Mailbox -Identity "support-team@contoso.com" -EmailAddresses @{add="hello@contoso.com"}

# If it's a dynamic distribution group:
Set-DynamicDistributionGroup -Identity "support-team@contoso.com" -EmailAddresses @{add="hello@contoso.com"}

Prefer the GUI? Exchange Admin Center → Recipients → (Mailboxes or Groups) → select the object → Email addresses → Add email address type → enter the alias → Save.

Verify it took:

Get-Mailbox support-team@contoso.com | fl EmailAddresses
# (or Get-DistributionGroup / Get-UnifiedGroup, matching the object type)

Expected output:

EmailAddresses : {smtp:hello@contoso.com, SMTP:support-team@contoso.com,
                 smtp:support-team@contoso.onmicrosoft.com}

Read the prefixes carefully:

• SMTP: (uppercase) = the primary address. Outgoing mail and replies are stamped with this. Adding an alias never changes it.
• smtp: (lowercase) = a secondary alias. It receives mail, nothing more.

That gives exactly the classic vanity behavior: mail to hello@ lands in support-team@, and replies still come from support-team@.

---

Gotcha: The GetResponseHeader Error

You may hit this on Set-Mailbox (or any EXO cmdlet):

Exception: Method invocation failed because [System.Net.Http.HttpResponseMessage]
does not contain a method named 'GetResponseHeader'.

This is a known bug in older ExchangeOnlineManagement module versions on PowerShell 7 — the module's internal retry/error-handling path calls a method that no longer exists in modern .NET. It is not a problem with your command, and sometimes the change even applies before the module trips over itself.

What to do, in order:

# 1. Check whether the change actually applied despite the error:
Get-Mailbox support-team@contoso.com | fl EmailAddresses

# 2. If not, reconnect (stale tokens are a common trigger) and retry:
Disconnect-ExchangeOnline -Confirm:$false
Connect-ExchangeOnline
Set-Mailbox -Identity "support-team@contoso.com" -EmailAddresses @{add="hello@contoso.com"}

# 3. Still failing? Update the module and retry in a FRESH window:
Update-Module ExchangeOnlineManagement -Force

A reconnect-and-retry usually fixes it. The Exchange Admin Center is also a perfectly good fallback — no module bug there.

---

Step 3: Test the Delivery

Send a test email to the new vanity address, then prove delivery with a message trace — no mailbox access required:

Get-MessageTraceV2 -RecipientAddress support-team@contoso.com `
    -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
    fl Received,SenderAddress,RecipientAddress,Subject,Status

Expected result:

Received         : 8/7/2026 8:21:00 PM
SenderAddress    : megan.bowen@contoso.com
RecipientAddress : support-team@contoso.com
Subject          : Vanity alias test
Status           : Delivered

Three testing gotchas:

1. Get-MessageTrace is deprecated (retiring from September 2025) — use Get-MessageTraceV2.
2. Search by the primary address, not the alias. The trace logs messages against the mailbox's primary SMTP address, so searching -RecipientAddress hello@contoso.com returns nothing even when delivery succeeded. Searching by -SenderAddress <your address> also works.
3. Trace data lags 5–15 minutes behind real delivery. An empty result right after sending doesn't mean failure — wait and re-run. If it's still empty after 15+ minutes, check the sender's inbox for a bounce (NDR).

Status: Delivered = the alias works end to end.

---

Send-As: When Outgoing Mail Must Show the Vanity Address

An alias only handles incoming mail. By default, Exchange Online stamps all outgoing mail with the mailbox's primary address. If mail must go out as hello@contoso.com, choose one of two designs.

Option 1 — Keep the alias, enable send-from-alias (tenant-wide)

# Check whether it's already on:
Get-OrganizationConfig | fl SendFromAliasEnabled

# Grant Send As on the mailbox to the users who need it:
Add-RecipientPermission -Identity "support-team@contoso.com" `
    -Trustee "megan.bowen@contoso.com" -AccessRights SendAs

# Enable sending from aliases — ORG-WIDE setting:
Set-OrganizationConfig -SendFromAliasEnabled $true

Users then show the From field in Outlook/OWA and type the alias manually.

⚠️ Caution: SendFromAliasEnabled affects the entire tenant — every user becomes able to send from their aliases too. Treat it as an organizational change, not a quick fix.

Option 2 — Promote the vanity address to its own shared mailbox (scoped, cleaner)

No tenant-wide change; incoming behavior stays identical:

# 1. Remove the alias first (addresses must be unique tenant-wide):
Set-Mailbox -Identity "support-team@contoso.com" -EmailAddresses @{remove="hello@contoso.com"}

# 2. Create the vanity address as its own shared mailbox:
New-Mailbox -Shared -Name "Hello" -PrimarySmtpAddress "hello@contoso.com"

# 3. Forward everything to the real mailbox (no copy kept in the new one):
Set-Mailbox -Identity "hello@contoso.com" `
    -ForwardingAddress "support-team@contoso.com" -DeliverToMailboxAndForward $false

# 4. Grant Send As (and Full Access, if users will open it) to specific users:
Add-RecipientPermission -Identity "hello@contoso.com" `
    -Trustee "megan.bowen@contoso.com" -AccessRights SendAs
Add-MailboxPermission -Identity "hello@contoso.com" `
    -User "megan.bowen@contoso.com" -AccessRights FullAccess -AutoMapping $true

Notes: shared mailboxes need no license under 50 GB (a license is required only for archive, litigation hold, or >50 GB). There's a brief cutover between removing the alias and creating the mailbox — do it in a quiet window.

Rule of thumb: start with the plain alias. Only restructure to Option 2 if send-as is a confirmed requirement — it's scoped, reversible, and doesn't touch tenant config.

---

External Target: Forwarding Outside the Tenant

If the destination lives outside your organization (e.g. partners@fabrikam.com), an alias can't work — aliases only attach to objects in your own tenant. Instead:

# 1. Create a mail contact for the external address:
New-MailContact -Name "Partners (External)" -ExternalEmailAddress "partners@fabrikam.com"

# 2. Create the vanity address as a shared mailbox and forward it:
New-Mailbox -Shared -Name "Hello" -PrimarySmtpAddress "hello@contoso.com"
Set-Mailbox -Identity "hello@contoso.com" `
    -ForwardingAddress "partners@fabrikam.com" -DeliverToMailboxAndForward $true

⚠️ Check your outbound spam policy: automatic external forwarding is blocked by default in many tenants (Automatic forwarding: Off in the anti-spam outbound policy). You may need an explicit policy exception. Keeping -DeliverToMailboxAndForward $true retains a copy in the shared mailbox, which helps with compliance and troubleshooting.

---

New Domain: When the Vanity Domain Isn't in the Tenant Yet

If the address is on a domain the tenant doesn't own yet (e.g. hello@brand-new-product.com), everything above is blocked until the domain is onboarded:

1. Microsoft 365 admin center → Settings → Domains → Add domain, verify ownership via a DNS TXT record.
2. Publish MX, SPF, DKIM, and DMARC records for the new domain.
3. Confirm it appears as an accepted domain: Get-AcceptedDomain.
4. Then proceed with the alias or shared-mailbox setup above.

Adding a domain touches DNS ownership and mail routing — plan it as its own piece of work.

---

Rollback

Undoing the plain-alias setup is one line:

Set-Mailbox -Identity "support-team@contoso.com" -EmailAddresses @{remove="hello@contoso.com"}

(Use the matching Set-DistributionGroup / Set-UnifiedGroup variant for groups.)

---

Checklist / TL;DR

•  Decide: vanity address, target object, is send-as needed, is the domain in the tenant
•  Get-Recipient <vanity> → must return not found (address is free)
•  Get-Recipient <target> | fl RecipientTypeDetails → pick the matching Set-* cmdlet
•  Add the alias with -EmailAddresses @{add="..."} — lowercase smtp: = secondary, primary stays untouched
•  GetResponseHeader exception? → check if it applied, reconnect, update the module, or use the EAC
•  Test with Get-MessageTraceV2 — search the primary address, allow 5–15 min lag
•  Send-as needed? → prefer a dedicated shared mailbox over the tenant-wide SendFromAliasEnabled flag
•  External destination? → mail contact + forwarding + outbound-spam policy check
•  New domain? → verify domain and publish MX/SPF/DKIM/DMARC first
•  Keep the one-line rollback handy