Users switch to the .onmicrosoft.com domain after an INKY install

Written By Nathan McCurley

Last updated 3 days ago

Short version

INKY does not modify user principal names, email addresses, or any other Entra ID attribute. The install verifies a domain in your tenant. Verifying a domain causes Microsoft to run ProxyCalc, a background process that re-evaluates every object in the tenant. Any account whose identity data was already inconsistent gets rewritten to the default .onmicrosoft.com domain when that runs. This can affect a few accounts or the entire tenant. It does not resolve on its own. The underlying data has to be repaired in Active Directory or Entra ID.

What you're seeing

Shortly after an INKY install, users' email addresses and sign-in identities no longer show your organization's domain. They now use the tenant.onmicrosoft.com domain that came with your Microsoft 365 subscription. Affected users are signed out, cannot sign in with their usual address, and get repeated credential prompts in Outlook and other Microsoft 365 apps.

What it means

Microsoft Entra ID runs a background process called ProxyCalc that keeps each account's UserPrincipalName and proxyAddresses consistent with the tenant's verified domains. It does not run continuously. It fires in response to tenant-level configuration changes, and verifying a domain is one of those changes. When it fires, it evaluates every object in the tenant, not just the objects involved in the change.

The INKY install verifies a domain as part of setup, which is enough to start it.

When ProxyCalc evaluates an account and finds no valid identity on a verified domain, it falls back to the tenant's default .onmicrosoft.com domain, which is always present and cannot be removed. For cloud-only accounts, the UPN is converted to that suffix. For directory-synced accounts, the UPN is expected to match the value Entra Connect syncs up from on-premises Active Directory. If it does not match and no correct suffix is available, the default domain is used instead.

INKY does not write to user principal names, proxy addresses, or any other identity attribute during installation. The recalculation surfaces an identity problem that was already present in the directory.

Microsoft describes this behavior in Understanding bulk user updates during verified domain changes, which confirms that adding a verified domain triggers the operation against every object in the tenant.

Before you start

The commands below run in three different places. Connect to the right one before running each:

  • Exchange Online PowerShell for Get-Mailbox and Set-Mailbox. Install the ExchangeOnlineManagement module, then run Connect-ExchangeOnline.

  • Microsoft Graph PowerShell for Update-MgUser. Install the Microsoft.Graph.Users module, then run Connect-MgGraph -Scopes "User.ReadWrite.All".

  • On-premises Active Directory for Get-ADUser. Run from a domain controller or a machine with RSAT installed, using an account with domain administrative permissions.

Replace user@domain.com in the examples with the address you are working on.

What to do

Work through these in order. Steps 1 and 2 make no changes.

If every account in the tenant is affected rather than a few, check the domain before correcting users. Confirm the domain carrying your identities is verified and set as the default. Corrections to individual accounts will not hold while a domain-level problem remains.

1. Confirm the cause in the Entra ID audit log

In the Microsoft Entra admin center, go to Identity > Monitoring & health > Audit logs and filter to the date and time of the install.

Look for a group of Update user entries with:

  • Category set to UserManagement

  • Service set to Core Directory

  • Actor empty or showing N/A, with Actor Type of Other

The empty actor field is what identifies these. Changes made by an administrator or an application record the actor's name. ProxyCalc does not.

Compare the timestamps against the install. Domain verification runs a few minutes before the identity changes appear. Actions performed by the INKY installer are recorded under its own app registration name, and none of them are user attribute changes.

Open one of the entries and expand Modified Properties to see the old and new values.

2. Determine whether the tenant is hybrid or cloud-only

This decides where the fix belongs. If accounts are directory-synced, correcting them in the cloud gets overwritten at the next sync cycle, so the on-premises data has to be fixed first.

Get-Mailbox -Identity user@domain.com | Select-Object DisplayName, UserPrincipalName, PrimarySmtpAddress, IsDirSynced

If IsDirSynced is True, go to step 3. If False, skip to step 4.

3. Repair the source data in on-premises Active Directory

To inspect a single user in Active Directory Users and Computers:

  1. Open the View menu and enable Advanced Features, otherwise the Attribute Editor tab stays hidden.

  2. Locate the user account, right-click it, and select Properties.

  3. Open the Attribute Editor tab and find the proxyAddresses and userPrincipalName attributes.

  4. Confirm proxyAddresses holds one entry beginning with an uppercase SMTP: on your organization's domain. Aliases use lowercase smtp:.

  5. Confirm userPrincipalName uses your organization's domain and matches what the user signs in with.

The same check from PowerShell:

Get-ADUser -Identity username -Properties proxyAddresses, userPrincipalName | Select-Object userPrincipalName, proxyAddresses

Correct any account missing an uppercase SMTP: entry or carrying a .onmicrosoft.com UPN. Then force a delta sync from the Entra Connect server and check the account again in Entra ID.

Do not run a bulk script that overwrites proxyAddresses across every user object. Replacing the attribute wholesale discards aliases, x500: entries, and older addresses that mail flow and calendar delegation still depend on. Find the affected accounts first and correct only those.

For how Microsoft builds the final values from these attributes, see How the proxyAddresses attribute is populated in Microsoft Entra ID and Microsoft Entra UserPrincipalName population.

4. Correct cloud-only accounts

Find every affected account before changing anything:

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.PrimarySmtpAddress -like "*.onmicrosoft.com" } | Select-Object DisplayName, UserPrincipalName, PrimarySmtpAddress

This filters on the client side and takes several minutes on a large tenant. Review the results before acting on them. Some accounts legitimately use the default domain, including service and system accounts.

Correct the sign-in identity, using the account's current .onmicrosoft.com UPN to identify it:

Update-MgUser -UserId user@tenant.onmicrosoft.com -UserPrincipalName user@domain.com

Changing a UPN signs the user out of Microsoft 365 and can affect OneDrive and Teams. Have the user close their apps first and sign back in afterward.

Correct the primary email address:

Set-Mailbox -Identity user@domain.com -PrimarySmtpAddress user@domain.com

The previous primary address stays on the mailbox as an alias, so mail sent to the .onmicrosoft.com address still arrives.

5. Verify

Get-Mailbox -Identity user@domain.com | Select-Object DisplayName, UserPrincipalName, PrimarySmtpAddress

Have the user sign out and back in, then send a test message and check the From address on the recipient's copy.

Checking a tenant before an INKY install

Run this against the tenant before installing. Any account it returns is already inconsistent and is a candidate to be rewritten:

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.UserPrincipalName -like "*.onmicrosoft.com" -or $_.PrimarySmtpAddress -like "*.onmicrosoft.com" } | Select-Object DisplayName, UserPrincipalName, PrimarySmtpAddress

Also confirm the domain-level conditions, which determine whether the impact is limited to a few accounts or reaches the whole tenant:

  • Every domain carrying user identities is verified in the tenant

  • Your organization's domain is set as the default domain

  • Directory synchronization is running without errors

These checks are worth running whether or not you are installing INKY. Any future domain change in the tenant produces the same result.