Guides / microsoft-365
Who decides a hybrid mailbox's primary address
Three components claim the same field: the email address policy, the command you are running, and Entra. They win in that order, and none of them says so.
In a hybrid environment, a mailbox’s primary address is not a field you write. It is the outcome of a contest between three components that never consult one another: the Exchange email address policy, the command being run, and Entra at synchronisation time. Each can overwrite the one before it, and none of them warns you.
First: the policy claims the field
Setting a mailbox’s primary address stopped here.
Couldn't update the primary SMTP address because this mailbox is
configured to use an email address policy.
The message is clear and tells the truth: with an email address policy in force, the primary address is decided by the policy, not by whoever runs the command. This is intended behaviour — it exists precisely so a hundred thousand mailboxes get consistent addresses — but it becomes an obstacle when a single mailbox needs to be an exception.
The instinctive workaround, adding the address by hand, produces a second and more obscure error.
There are multiple primary SMTP addresses.
The cause is a capital letter. In the -EmailAddresses parameter, the prefix SMTP: in uppercase means primary, while lowercase smtp: means alias.
# adds a SECOND primary: not allowed
Set-Mailbox <user> -EmailAddresses @{add="SMTP:[email protected]"}
A mailbox can have only one primary address. The addition does not replace the existing one: it sits alongside it, and Exchange rejects the resulting state.
The fix is to disable the policy on that mailbox and use the dedicated parameter, which demotes the old primary to an alias by itself — without losing it.
Set-Mailbox <user> `
-EmailAddressPolicyEnabled $false `
-PrimarySmtpAddress <user>@lab.impicciando.it
Second: the objects the tenant cannot see
Delegation assignment failed on every group.
Mailbox ufficio.acquisti or Group Gufficio.acquisti not found in EXO
Two overlapping causes, which makes the diagnosis slow: fixing only one changes nothing.
The groups were outside the synchronisation scope. They lived in CN=Users, while the Entra Connect filter was set to a dedicated organisational unit. As far as the tenant was concerned those objects did not exist at all — they were not wrong, they were absent.
The hybrid deployment option was missing. Without Exchange hybrid deployment enabled in Entra Connect, Exchange Online does not recognise on-premises objects as valid recipients, even when it can see them.
The fix needs all three steps: move the groups into the synchronised organisational unit, enable the option, and force a full cycle — not a delta, which will not re-examine objects previously ruled out of scope.
Start-ADSyncSyncCycle -PolicyType Initial
Third: Entra rewrites what it cannot verify
The groups made it into the tenant. With the wrong address.
Instead of @lab.impicciando.it they carried an address on @impicciando.onmicrosoft.com, which nobody had asked for.
The reason is the most reasonable of the three. Their on-premises primary address was on contoso.lab, the internal Active Directory domain, which cannot be verified in the tenant: it is not a public domain and nobody can prove ownership of it. Entra discards addresses on unverified domains — it cannot do otherwise, since accepting them would let anyone claim any domain — and assigns one on the service domain in their place.
This is not a fault. It is a system declining to believe an unprovable claim.
Set-DistributionGroup <group> `
-EmailAddressPolicyEnabled $false `
-PrimarySmtpAddress <group>@lab.impicciando.it
The three lessons
When a field has three masters, the order matters more than the value. Policy, command, synchronisation: writing the right value at the wrong moment is the same as not writing it.
An internal domain is not a domain. contoso.lab works perfectly well for Kerberos, LDAP and authentication, and is worth nothing as a mail identity. Keeping them separate from the start avoids this whole category of problem — and it is the structural reason the AD domain should not be the public domain.
A value that comes back wrong after you fix it is not a coincidence. It is an authoritative upstream source restating what it knows. Finding where it is generated is faster than fixing it again.
Lab built with the support of Ilie.