I'm dealing with a frustrating issue where every time I add a new accepted domain to my Microsoft 365 setup, all of my users' primary SMTP addresses get reset to their tenant's onmicrosoft.com address. To clarify, I'm not making the new domain the primary one—I'm just adding it, but the moment I do so, Exchange Online overrides everyone's settings. My environment includes an on-prem Active Directory domain (corp.local), an Azure AD tenant domain (tenantname.onmicrosoft.com), and multiple external domains (like companyA.com and companyB.com). I'm using Okta for federation and AAD Connect for syncing users, and I've long since decommissioned my on-prem Exchange. However, due to the Okta federation, I'm unable to change the default domain in Microsoft 365. The fact that my on-prem domain is a .local makes UPNs non-routable, thus complicating matters. This leads me to manually change every user's SMTP back, which isn't a viable long-term solution. I've gone through various attempts to resolve this, including adjusting UPNs (which breaks legacy apps), setting Adsync to audit mode (but I don't see any useful changes), and contacting Microsoft support multiple times without any clear direction. I'm hoping to understand why this rewriting of SMTP happens and if anyone else has faced a similar issue with Okta-federated setups.
4 Answers
It sounds like the UPNs being non-routable are definitely creating issues here. You really should look into updating those UPNs, despite legacy applications possibly causing trouble. It’s necessary for future-proofing your setup.
To fix this, try setting the proxyaddress attribute to the correct domain format ([SMTP:[email protected]](mailto:[email protected])). You'll also want to check on the UPN configurations in your AD—having them match with a routable domain should help avoid the onmicrosoft.com fallback.
One solution could involve adding your routable fully qualified domain names (FQDNs) as valid UPN suffixes in your Active Directory. Aligning your users' AD UPNs to the preferred sign-in IDs should help clear this up as well.
You're correct that the .local domain is causing these problems. In theory, adding an additional UPN suffix and defaulting to that in AD shouldn't interfere with legacy apps too badly. You might want to explore configuring AD Connect to utilize that new UPN for syncing with Microsoft 365 directly—should simplify the whole process!
Yeah, definitely agree with you here! The user principal name (UPN) in AD is key, and setting it to the new domain might resolve most of the SMTP issues. Just make sure to sync it correctly.