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

Malcolm Taylor 0 Reputation points
2026-09-12T07:40:44.6466667+00:00

Hi I need help how to resolve the issue with main usernames as our incoming emails are not coming through and throws up Entra ID issue but the Alias names attached works fine the AI support just gives me the run around

if some can provide a step-by-step fix I would really appreciate it

Outlook | Windows | New Outlook for Windows | For business

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. zafar iqbal 0 Reputation points
    2026-09-13T06:16:16.9633333+00:00

    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.

    Was this answer helpful?

    0 comments
  2. Muhammad Bilal Khan 0 Reputation points
    2026-09-12T08:02:30.14+00:00

    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.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-09-12T07:40:58.9366667+00:00

    If the primary business address is not receiving mail but an alias still works, use this order of checks:

    1. Check whether mail is missing only in Outlook or missing from the mailbox itself
      • Sign in to Outlook on the web for the affected mailbox.
      • If messages arrive there but not in Outlook for Windows, the issue is the Outlook app or profile, not mail flow.
    2. Run Microsoft Support and Recovery Assistant on the affected PC
      • This is recommended for single-user Outlook or Microsoft 365 account issues.
      • It can detect profile and Outlook configuration problems.
      • Note: the Get Help troubleshooters are not available for new Outlook for Windows.
    3. If the user is synchronized from on-premises Active Directory, fix the alias there
      • If the account shows: “This user is synchronized with your local Active Directory. Some details can be edited only through your local Active Directory”, the address changes must be made on-premises.
      • Open Active Directory Users and Computers.
      • Turn on View > Advanced Features if needed.
      • Open the user account: Properties > Attribute Editor > proxyAddresses.
      • Add or correct the required address using the lowercase prefix smtp: for a secondary alias, for example smtp:******@contoso.com.
      • Then wait for the changes to sync to Microsoft Entra ID.
    4. If the tenant or custom domain was added recently, wait for setup to finish
      • If the error includes “A parameter cannot be found that matches parameter name EmailAddresses”, tenant or domain setup may still be completing.
      • Setup can take up to 4 hours.
      • Retry after that delay.
    5. If only one user is affected, verify Outlook profile behavior
      • If Outlook on the web works but Outlook for Windows does not, create a fresh Outlook profile or use Support and Recovery Assistant.
      • This helps rule out a corrupted local profile.
    6. If the mailbox still does not receive mail on the primary address after the above checks, contact support
      • If tenant setup delay is the cause and the issue persists, Support can perform a full sync.

    A practical way to isolate the problem is:

    • Primary address fails in Outlook on the web too: likely address or directory configuration.
    • Primary address works in Outlook on the web but not Outlook for Windows: likely Outlook client/profile issue.
    • User is directory-synced: update proxyAddresses in on-premises AD, then allow sync to Entra ID.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.