Site icon Windows Active Directory

Create email aliases & retrieve user mail info in AD

Arun Kumar

Admins often say “add an email alias in Active Directory,” but that phrase hides an important distinction. Active Directory stores identity attributes. Exchange and Exchange Online turn those attributes into mail-enabled behavior. So the right procedure depends on whether you are working with an Exchange Online mailbox, an on-prem Exchange recipient, or just raw AD attributes with no supported Exchange management layer. In hybrid, that distinction matters even more because directory synchronization keeps the on-premises directory authoritative for many recipient properties. (

At a first-principles level, an email alias is usually just another SMTP proxy address attached to the same recipient. It is not a separate mailbox. Mail sent to the alias is delivered to the mailbox’s primary SMTP address. Microsoft’s Exchange Online documentation explicitly describes additional addresses as proxy addresses, stored in the mailbox’s multivalued EmailAddresses property.

That leads to the core rule for sysadmins:

The attributes that actually matter

For this topic, the important attributes and properties are:

The most important formatting rule is this: uppercase SMTP: marks the primary SMTP address; lowercase smtp: marks secondary aliases. Microsoft documents that distinction directly in Exchange PowerShell parameter help.

Decide the environment before you touch anything

Before you add an alias, answer one question: where is the mailbox actually managed?

Case 1: Exchange Online only

If the user mailbox is cloud-only, add the alias in Exchange Online. Microsoft documents two supported paths: Exchange admin center and PowerShell. The same documentation also notes that the Microsoft 365 admin center can be used as an alternative surface.

Case 2: Hybrid with synchronized users

If the object is synchronized from on-premises AD, Microsoft’s own guidance is clear: you generally cannot manage most recipient properties directly in Exchange Online. The authoritative side is on-premises, and Microsoft recommends Exchange-supported tools for recipient management.

Case 3: AD-only directory data

If you are only storing addresses in AD, or you do not have Exchange recipient management in scope, then AD cmdlets can update the raw LDAP attributes. That is directory editing, not full Exchange recipient management. It can be useful, but it is not the same support boundary as using Exchange tools in hybrid.

Procedure 1: Add an alias to a cloud mailbox in Exchange Online

This is the cleanest case.

Exchange admin center steps

Microsoft’s documented path is:

  1. Open Exchange admin center.
  2. Go to Recipients > Mailboxes.
  3. Select the mailbox.
  4. Under General > Email addresses, choose Manage email address types.
  5. Add an SMTP address.
  6. Save. (Microsoft Learn)

Exchange Online PowerShell

Use Set-Mailbox to append an alias without overwriting the existing list:

Set-Mailbox "John Doe" -EmailAddresses @{add="john.doe@contoso.com"}

To add multiple aliases:

Set-Mailbox "John Doe" -EmailAddresses @{add="jdoe@contoso.com","sales.john@contoso.com"}

To verify:

Get-Mailbox "John Doe" | Format-List PrimarySmtpAddress,EmailAddresses

Microsoft’s Exchange Online documentation shows the same @{add=...} pattern and treats EmailAddresses as a multivalued property.

Procedure 2: Add an alias in a hybrid environment

This is where many admins get into trouble, because the mailbox may be in Exchange Online while the recipient attributes are still sourced from on-premises AD.

Microsoft states that when directory synchronization is enabled, most user properties for synchronized recipients must be managed on-premises, not directly in Exchange Online. Microsoft also says that non-Microsoft tools and even ADSI Edit are not supported tools for managing Exchange users in hybrid.

Supported approach: use Exchange management tools and Set-RemoteMailbox

For synchronized remote mailboxes, Set-RemoteMailbox is the supported cmdlet on the on-premises side. Microsoft documents that Set-RemoteMailbox configures Exchange attributes for an on-premises mail user and that those settings synchronize to the associated cloud mailbox.

Add a secondary alias:

Set-RemoteMailbox -Identity "jdoe" -EmailAddresses @{Add="smtp:jdoe@newdomain.com"}

Set a new primary SMTP explicitly:

Set-RemoteMailbox -Identity "jdoe" -PrimarySmtpAddress "jdoe@newdomain.com"

Or replace the full address set carefully:

Set-RemoteMailbox -Identity "jdoe" -EmailAddresses `
"SMTP:jdoe@newdomain.com","smtp:jdoe@olddomain.com","smtp:john.doe@contoso.mail.onmicrosoft.com"

Then verify on-prem:

Get-RemoteMailbox "jdoe" | Format-List PrimarySmtpAddress,EmailAddresses,RemoteRoutingAddress

And verify in Exchange Online after sync:

Get-Mailbox "jdoe" | Format-List PrimarySmtpAddress,EmailAddresses

Microsoft’s Exchange PowerShell help documents that EmailAddresses contains all proxy addresses, that SMTP: indicates the primary address, and that smtp: indicates secondary addresses.

Important hybrid warning: do not accidentally flip the primary address with targetAddress

Microsoft documents a real hybrid failure mode here: if targetAddress is written with uppercase SMTP:, it can replace the primary SMTP address during email address policy updates. Their workaround is to use lowercase smtp: for targetAddress instead. (Microsoft Learn)

That matters because in hybrid, mail flow attributes interact. A careless targetAddress edit can silently change what you thought was just a secondary routing value.

Procedure 3: Stamp mail attributes directly in Active Directory

This procedure is useful when you need raw AD attribute management or when you are preparing directory data. It is also the pattern many admins use for reporting, lab work, or non-Exchange directory scenarios.

Use Set-ADUser to append to proxyAddresses:

Set-ADUser -Identity "jdoe" -Add @{
    proxyAddresses = "smtp:jdoe@contoso.com"
}

Set mail and mailNickname:

Set-ADUser -Identity "jdoe" -Replace @{
    mail         = "john.doe@contoso.com"
    mailNickname = "jdoe"
}

Replace the entire proxyAddresses set:

Set-ADUser -Identity "jdoe" -Replace @{
    proxyAddresses = @(
        "SMTP:john.doe@contoso.com",
        "smtp:jdoe@contoso.com",
        "smtp:john@contoso.net"
    )
}

Remove one alias:

Set-ADUser -Identity "jdoe" -Remove @{
    proxyAddresses = "smtp:john@contoso.net"
}

Microsoft’s Set-ADUser documentation confirms that non-default attributes are managed through -Add, -Remove, -Replace, and -Clear, and that when combined, the order is Remove, Add, Replace, Clear. That matters operationally because -Replace rewrites the attribute’s values, while -Add appends without replacing the current set.

For Exchange-managed hybrid recipients, this still falls into direct attribute editing rather than Microsoft’s preferred Exchange-supported management path. Use it when you intentionally want raw directory changes and understand the support boundary.

How to retrieve user mail information from Active Directory

Retrieval is where AD PowerShell shines, because Get-ADUser can pull both default and additional properties as long as you request them.

Microsoft documents that Get-ADUser returns only a default set of user properties unless you specify -Properties. It also states that non-default or non-extended properties may require the LDAP display name.

Retrieve one user’s mail-related attributes

Get-ADUser -Identity "jdoe" -Properties mail,mailNickname,proxyAddresses,targetAddress,userPrincipalName |
    Select-Object Name,SamAccountName,UserPrincipalName,mail,mailNickname,targetAddress,proxyAddresses

Retrieve all attributes for inspection

Get-ADUser -Identity "jdoe" -Properties *

Find the primary SMTP from proxyAddresses

Get-ADUser -Identity "jdoe" -Properties mail,proxyAddresses |
    Select-Object Name,mail,
        @{Name="PrimarySMTP";Expression={
            (($_.proxyAddresses | Where-Object { $_ -cmatch '^SMTP:' }) -replace '^SMTP:','')
        }},
        proxyAddresses

Query all users with mail data in an OU

Get-ADUser -Filter * `
    -SearchBase "OU=Users,DC=contoso,DC=com" `
    -Properties mail,mailNickname,proxyAddresses,targetAddress,userPrincipalName |
    Select-Object Name,SamAccountName,UserPrincipalName,mail,mailNickname,targetAddress,proxyAddresses

Query by alias domain

Get-ADUser -Filter { proxyAddresses -like "*@contoso.com" } `
    -Properties mail,proxyAddresses |
    Select-Object Name,mail,proxyAddresses

Get-ADUser supports -Filter, -LDAPFilter, -SearchBase, and -Properties, and Microsoft explicitly notes that additional properties must be requested through -Properties.

How to interpret what you retrieved

When you inspect a user, read the fields in this order:

  1. proxyAddresses tells you the full address set.
  2. The value beginning with SMTP: is the primary reply address.
  3. Values beginning with smtp: are secondary aliases.
  4. mail usually reflects the primary address in plain form.
  5. mailNickname is the Exchange alias, not necessarily every user’s sign-in name.

In synchronized environments, do not assume cloud values mirror on-prem values exactly. Microsoft’s Entra sync documentation says the service can discard malformed or noncompliant proxy values and can remove proxy addresses with non-verified domain suffixes for Exchange Online-licensed users. It also notes that the user principal name is added as a proxy address for Exchange Online recipients. (Microsoft Learn)

That is why an admin can look at AD and Exchange Online and think the system is “wrong,” when the real issue is that Entra proxy calculation applied service-side rules.

A practical example

Suppose John Doe currently has:

AD retrieval first

Get-ADUser -Identity "jdoe" -Properties mail,mailNickname,proxyAddresses,targetAddress |
    Select Name,mail,mailNickname,targetAddress,proxyAddresses

If cloud-only mailbox

Set-Mailbox "John Doe" -EmailAddresses @{add="jdoe@newdomain.com"}
Get-Mailbox "John Doe" | Format-List PrimarySmtpAddress,EmailAddresses

If hybrid synced remote mailbox

Set-RemoteMailbox -Identity "jdoe" -EmailAddresses @{Add="smtp:jdoe@newdomain.com"}
Get-RemoteMailbox "jdoe" | Format-List PrimarySmtpAddress,EmailAddresses,RemoteRoutingAddress

If you only need the AD attribute stamped

Set-ADUser -Identity "jdoe" -Add @{proxyAddresses="smtp:jdoe@newdomain.com"}
Get-ADUser -Identity "jdoe" -Properties proxyAddresses | Select Name,proxyAddresses

The command differs, but the underlying idea is the same: you are adding one more proxy address to the recipient’s address list. The critical difference is which system owns that list.

Common mistakes that break real environments

1. Replacing instead of appending

Using -Replace on proxyAddresses without rebuilding the entire existing list can remove valid addresses. -Add is safer when you only want one more alias. Microsoft’s Set-ADUser docs make the add-versus-replace distinction explicit.

2. Using uppercase SMTP: on the wrong value

Uppercase SMTP: marks the primary address. If you meant to create a secondary alias and used uppercase, you changed the primary.

3. Editing synchronized recipients in the wrong place

If the recipient is synchronized from on-prem, direct cloud edits may not stick because the source of authority is still on-premises. Microsoft says most recipient management still belongs there while sync is enabled.

4. Treating an alias like a shared address for multiple people

A user alias is still one mailbox. If several people need to monitor and reply from info@contoso.com, a shared mailbox is usually the correct construct. Microsoft’s support guidance explicitly positions shared mailboxes for group use around public addresses such as info@contoso.com.

When someone asks “how do I add members to an email alias in Outlook?”

That wording usually means the wrong object type.

You do not add members to a user alias. A user alias is just another address on one recipient. If multiple people need to receive and send from one shared address, use:

That distinction saves a lot of wasted troubleshooting because aliases, shared mailboxes, and groups solve different problems.

Final checklist for a sysadmin screen

Before change:

Get-ADUser -Identity "jdoe" -Properties mail,mailNickname,proxyAddresses,targetAddress |
    Select Name,mail,mailNickname,targetAddress,proxyAddresses

Cloud-only mailbox:

Set-Mailbox "John Doe" -EmailAddresses @{add="jdoe@newdomain.com"}
Get-Mailbox "John Doe" | Format-List PrimarySmtpAddress,EmailAddresses

Hybrid remote mailbox:

Set-RemoteMailbox -Identity "jdoe" -EmailAddresses @{Add="smtp:jdoe@newdomain.com"}
Get-RemoteMailbox "jdoe" | Format-List PrimarySmtpAddress,EmailAddresses,RemoteRoutingAddress

Raw AD attribute edit:

Set-ADUser -Identity "jdoe" -Add @{proxyAddresses="smtp:jdoe@newdomain.com"}
Get-ADUser -Identity "jdoe" -Properties proxyAddresses | Select Name,proxyAddresses

Safety checks:

The short version is this: the “alias” usually lives in proxyAddresses, but the supported way to manage it depends on who owns the recipient object. Once you get that boundary right, the task becomes straightforward.

Exit mobile version