Main user name on email doesn't receive emails Alias name still does affecting all emails in business

That "Alias works, primary doesn't" pattern points pretty specifically at a directory-level conflict rather than a mail-flow/connector problem, since aliases and the primary address live on the same mailbox object but resolve through Entra ID differently. A few things to check, roughly in order:

Check for a duplicate proxy address in the tenant: The most common cause of this exact symptom is that the main email address exists as a proxyAddress or primary SMTP on more than one object in Entra ID (a leftover guest account, a mail-enabled contact, a disabled/soft-deleted user, a distribution list, or a duplicate object from a migration). Entra ID requires SMTP addresses to be unique across the directory, and when there's a silent conflict, mail to that specific address can get rejected or misrouted while aliases (which don't have the conflict) work fine. In the Exchange admin center or via PowerShell, run: Get-Recipient -Identity "******@domain.com" -ErrorAction SilentlyContinue and also search broadly: Get-Recipient -Filter {EmailAddresses -like "*******@domain.com*"} to see if it returns more than one object.

Check message trace for the actual NDR: In the Exchange admin center under Mail flow > Message trace, search for a recent failed delivery attempt to the main address and look at the detailed trace — it'll usually show the actual rejection reason rather than the vague "Entra ID issue" the client/AI support gave you.

Check the mailbox's PrimarySmtpAddress vs UserPrincipalName: Run Get-Mailbox -Identity ******@domain.com | fl PrimarySmtpAddress,UserPrincipalName,EmailAddresses — if the address that's failing isn't actually set as the PrimarySmtpAddress (or isn't in the EmailAddresses list at all, e.g., someone changed the UPN without updating the mailbox's SMTP addresses), that mismatch alone can cause this.

If you're in a hybrid environment (on-prem AD + Entra Connect): This is a very common cause — an attribute change made on-prem (proxyAddresses, mail, or UPN) that hasn't synced correctly to Entra ID, or a sync conflict where the cloud object and on-prem object disagree on which address is primary. Check Entra Connect Health / sync logs for errors tied to that specific user object around the time this started.

Check Entra ID sign-in/audit logs for the specific error code: Entra ID admin center > Monitoring > Audit logs (or Sign-in logs if it's throwing an actual auth-style error) — filter by that user and look for the exact error code rather than relying on the "Entra ID issue" label, since that's likely just Exchange summarizing a directory lookup failure.

If none of that turns up a duplicate or mismatch, it's worth opening a proper ticket with Microsoft 365 admin support directly (not the AI support flow) and referencing the message trace ID — directory object conflicts usually need someone with backend tenant access to fully resolve if it's not visible from your side.

Hi @Malcolm Taylor
The fact that the alias still receives mail is a useful clue. It suggests the mailbox itself is probably working, but the primary SMTP address may be incorrect, missing, or not syncing correctly through Entra ID.

I’d troubleshoot it in this order:

1. Check the mailbox in Exchange Admin Center Go to Exchange admin center → Recipients → Mailboxes → select the affected user → Email addresses. Make sure the address that should be the main email is listed as the primary SMTP address (shown in bold). Check for duplicate addresses If the primary address is also assigned to another user/contact/group, Entra synchronization can fail because SMTP proxy addresses must be unique. Check Entra ID → Users → Users with errors for a proxy-address conflict. If the users are synchronized from on-premises AD, don't fix the address only in the Microsoft 365 portal. Check the user's on-premises AD proxyAddresses attribute. The primary address should look like:

SMTP:******@yourdomain.com

Secondary aliases should use lowercase:

smtp:******@yourdomain.com

The uppercase SMTP: identifies the primary address.

Run a sync and check for errors in Microsoft Entra Connect. If the primary SMTP address is being overwritten or moved to an alias, investigate the on-premises proxyAddresses and, in a hybrid environment, the targetAddress attribute as well. Microsoft documents cases where targetAddress can cause the primary SMTP address to be replaced.

After correcting the address, allow synchronization to complete and test by sending a message from an external mailbox to the primary address. Also check the NDR/bounce message if one is generated.

I would not delete/recreate the users or mailboxes yet. Since the aliases are working, there is a good chance this can be corrected by fixing the primary SMTP/proxy address or an Entra synchronization conflict.

If you can post the exact Entra ID error message (with the domain/user details hidden), that would be the next thing I'd look at. It can tell us whether this is a duplicate proxy address, synchronization problem, or an Exchange recipient issue.The fact that the alias still receives mail is a useful clue. It suggests the mailbox itself is probably working, but the primary SMTP address may be incorrect, missing, or not syncing correctly through Entra ID.

I’d troubleshoot it in this order:

Check the mailbox in Exchange Admin Center
Go to Exchange admin center → Recipients → Mailboxes → select the affected user → Email addresses.

Make sure the address that should be the main email is listed as the primary SMTP address (shown in bold).

Check for duplicate addresses
If the primary address is also assigned to another user/contact/group, Entra synchronization can fail because SMTP proxy addresses must be unique. Check Entra ID → Users → Users with errors for a proxy-address conflict.

If the users are synchronized from on-premises AD, don't fix the address only in the Microsoft 365 portal. Check the user's on-premises AD proxyAddresses attribute.

The primary address should look like:

SMTP:******@yourdomain.com

Secondary aliases should use lowercase:

smtp:******@yourdomain.com

The uppercase SMTP: identifies the primary address.

Run a sync and check for errors in Microsoft Entra Connect. If the primary SMTP address is being overwritten or moved to an alias, investigate the on-premises proxyAddresses and, in a hybrid environment, the targetAddress attribute as well. Microsoft documents cases where targetAddress can cause the primary SMTP address to be replaced.

After correcting the address, allow synchronization to complete and test by sending a message from an external mailbox to the primary address. Also check the NDR/bounce message if one is generated.

I would not delete/recreate the users or mailboxes yet. Since the aliases are working, there is a good chance this can be corrected by fixing the primary SMTP/proxy address or an Entra synchronization conflict.

If you can post the exact Entra ID error message (with the domain/user details hidden), that would be the next thing I'd look at. It can tell us whether this is a duplicate proxy address, synchronization problem, or an Exchange recipient issue.