Changing the primary email address for Office 365 users

This content is 13 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In my recent post about configuring DNS for Office 365, I mentioned that Microsoft creates mailboxes in the form of  I outlined the steps for adding so-called “vanity” domains, after which additional (proxy) email addresses can be specified but any outbound messages will still be sent from the address (at least, that’s what’s used in the beta – I guess that may change later in the product’s lifecycle).

It is possible to change the primary address for a user (e.g. I send mail using an address on the domain) but it does require the use of PowerShell.  Time to roll up your sleeves and prepare to go geek!

Connecting to Office 365 from Windows PowerShell

I was using a Windows 7 PC so I didn’t need to update any components (nor do Windows Server 2008 R2 users); however Windows XP SP3, Server 2003 SP2, Server 2008 SP1 or SP2 and Vista SP1 users will need to make sure they have the appropriate versions of Windows Powershell and Windows Remote Management installed.

Once PowerShell v2 and WinRM 2.0 are installed, the steps to connect to Office 365 were as follows:

Prompt for logon credentials and supply the appropriate username and password:

$LiveCred = Get-Credential

Create a new session:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $LiveCred -Authentication Basic -AllowRedirection

Import the session to the current PowerShell console:

Import-PSSession $Session

At this point, the session import failed for me because script execution was disabled on my machine. That was corrected using Set-ExecutionPolicy -ExecutionPolicy unrestricted (although that’s not a great idea – it would be better to use a lower level of access) – I also had to run PowerShell as an administrator to successfully apply that command.

Once scripts were enabled, I was able to import the session.

List the current mailbox addresses

It’s possible that a mailbox may have a number of proxy addresses already assigned, so this is the code that I used to list them:

$Mailbox = Get-Mailbox -Identity Mark-Wilson

If you want to format the list of mailboxes as a single comma-separated line, then this might help:

ForEach ($i in $Mailbox.EmailAddresses) {Write-Host $i -NoNewline “`b, “}

(the `b is a backspace escape character.)

Set the primary email address

The primary email address is shown using an upper case SMTP: prefix whereas proxy addresses use a lower case smtp: prefix.

To change the primary email address, it’s necessary to reset all addresses on the mailbox with the Set-Mailbox cmdlet.  This is where some copying/pasting of the output from the previous command may help:

Set-Mailbox Mark-Wilson -EmailAddresses,,

Disconnect the session from Office365

Once all changes have been made, it’s good practice to break down the session again:

Remove-PSSession $Session

17 thoughts on “Changing the primary email address for Office 365 users

  1. This really helped me, thanks a bunch. Dont really know a lot about powershell but trying to learn to use it.

    Dont suppose you could give me some pointers on how to change a username in office365 via powershell (or maybe just change the postfix from the domain to my own)

    Cheers once again


  2. Ah, if anyone is watching the comments here, what about a site using ADFS. I get this if I try to re-order:

    The operation on mailbox “xxxxxxxx” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’,
    ‘EmailAddresses’, can’t be performed on the object ‘xxxxxxxx’ because the object is being synchronized from your on-premi
    ses organization. This action should be performed on the object in your on-premises organization.
    + CategoryInfo : NotSpecified: (xxxxxxxx:ADObjectId) [Set-Mailbox], TaskInvalidOperationException
    + FullyQualifiedErrorId : FC2AE2FB,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

    I’m guessing somehow I’ll need to reorder what we’re pushing from our side. I’ve used ADSI Editor to enter the values to synchronize, but it sure isn’t easy to get the right one to be your primary, I was really hoping powershell was the answer, but I should have known editing on the cloud servers wouldn’t do the trick.

  3. @Mihai Tanks for the links – they show that Microsoft’s documentation for Office 365 is starting to improve, however they are both focused on the enterprise version – not sure how applicable they are to organisations who are not federating

  4. Microsoft has truly created an obfuscated product here. Every time I create a new user for my Office365/active directory, I end up having to troll the forums to try and figure out how to set it up correctly. And each time I think I have a procedure laid out, I discover it is not quite right and end up with a instead of address. And it cannot be fixed either in Office365 OR in ADSI edit. I have learned that doing things in a slightly incorrect order makes everything break. For example, if you sync before doing the two important notes I list below, you will have this issue and nothing with fix it. The only way to fix it is to make the changes in ADSI edit / Active directory users and computers, delete the user in Office365, then resync the user again. Then everything will update correctly. Here is my final solution to the problem written out in terms any dummy like me can actually do:

    This assumes you are using ADFS with Office365…

    To add a new user:
    1. Open up “Active Directory Users and Computers” on your server (whichever one you use to administer your active directory).
    2. Under the “People” folder, click “Create a New User in the Current Container”
    3. Enter the name, a chosen logon name ( and choose next.
    4. Enter a password.
    5. Run “ADSI Edit” on the same server and navigate to: DC=domain,DC=corp -> OU=People, then right click on the new person and select properties. Under the Attribute Editor tab, click “ProxyAddress” and click “Edit”. Add “”

    *** IMPORTANT NOTE ***

    Be ABSOLUTELY certain that you capitalize SMTP. If it is lowercase at this stage, then when Office365 adds an onmicrosoft account by default (when it syncs), the default reply address will be “”, rather than “”, which is annoying and leads to lots of problems later. Capitalizing SMTP ensures that this is the default STMP address. This can only be changed in “ADSI Edit”; there are no exchange or office365 tools that can change this when using an active directory server.

    *** IMPORTANT NOTE 2 ***

    Be absolutely certain to fill in the “e-mail address” field in the “general” tab of the active directory users and groups for the new user. If this is not filled in, it will default to “”. Which really sucks. Do ALL of these steps BEFORE syncing with Office365 to avoid problems.

    Now log into the microsoft online portal (
    1. On the left pane (under “dashboard”, click “users and groups”)
    2. Wait until the active directory automatically syncs the new users with Office 365. This could take up to 4 hours. To manually sync, log into your ADFS server, open up “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1” and run the command “Start-OnlineCoexistenceSync”. This will force a sync between active directory and Office365.
    3. If needed, buy additional Office365 licenses.
    4. With the new users showing up in the “users and groups” tab, click the user you are interested in and assign a license.
    5. Set the location to U.S.
    6. Have the user change passwords on a site computer by typing CTRL+ALT+END and clicking “change password”.

  5. Certainly there are a lot of additional considerations if you are running a hybrid Office 365/on-premise Active Directory environment. If ADFS is over the top (depending on the circumstances, it can require a lot of additional infrastructure) then there is the Directory/Password sync option. Probably one for another post though as going off topic a little. Thanks for sharing the ADFS info though Ryan.

  6. I’m not so certain it’s that complicated. We migrated everyone well over a year ago. Every account we have has multiple aliases thanks to our migration tooll, but we’ve set many up since then and have even added or changed from one alias to another for the primary.

    While the vanity ( domain seems to get set and “locked” in when you set a user up – so if you have a typo there, it’s going to stay wrong even though you correct the name, but the e-mail address? It’s completely driven by the ProxyAddress field.

    I went away form using ADSIEdit for any of that in favor of ADUC. Just set the “SMTP” to your primary – and be sure you only have one with it all in upper case – and sync and that will be your primary e-mail address. Add all of your aliases as “smtp” and you are set. Like I said we have users with dozens of aliases and have changed or modified these for various reasons. I have had users get setup with the wrong domain (We support multiple) as their primary and we switch it later.

    We actually have a handy VBS script set up that lets us register the users and populates the e-mail address/ primary SMTP during setup along with every other field we find necessary, but on occasion we have to change things and it works once we sync.

  7. Good point Bill – I meant to mention this when I replied to Ryan this morning – SMTP denotes the primary address and smtp the aliases. That’s true with both Exchange Server and Exchange Online.

    Just one correction to Bill’s reply – the is not the vanity domain (I hate that term but Microsoft insists on using it!). The “vanity” domain is the DNS domain that you use reflecting your organisation – for example I use and

  8. Yep, I had that backwards. I should say “the domain nobody really knows about..” (at least our users) and that would clear it up. I honestly look back at my original post and thihk that the updating of the e-mail addresses came along quite nicely for us. We have a routine down when we need to change or correct something and it works quite well.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.