Teams meeting invitations use an internal alias instead of my primary email - responses bounce

Question

Teams meeting invitations use an internal alias instead of my primary email - responses bounce

Ferreol Tournebize 0

Hello,

My Microsoft account primary email is on my domain When I send meeting invitations from Microsoft Teams, the reply-to address is set to an internal alias: non sense

This causes two problems:

When recipients accept or decline my meeting invitations, their response bounces with error: 550 5.5.0 Requested action not taken: mailbox unavailable (S2017062302)
I never see their responses.

I cannot remove or modify this internal alias from my account settings. I have tried adding and removing an @outlook.com alias, switching primary aliases, and signing out/back into Teams. The problem persists.

Request: Please update my account so that Teams uses my primary email address mydomain for meeting invitation responses, or remove/replace the internal alias with a functional address.

Thank you for your help.

0 comments

2 answers

Your answer

Answer 1

Hi @Ferreol Tournebize

First, please feel free to check out the AI answer

Thank you for clarifying the issue. Since you have already tried changing the primary alias, this no longer appears to be something you can correct through the available account settings.

As a temporary workaround, create and send meetings from the calendar service associated with your custom-domain email address, then add the Teams meeting link manually. This should allow acceptance and decline responses to return to your functional mailbox instead of the internal alias.

For the existing Teams calendar behavior, Microsoft Support would need to investigate the account’s calendar routing. When contacting Support, include the bounce code 550 5.5.0 (S2017062302) and specify that ordinary email works, but responses to Teams meeting invitations are routed to an inaccessible internal alias.

Please note that this is a user-to-user support forum. Moderators and contributors cannot access accounts or Microsoft’s back-end systems. We can only provide technical guidance on reported incidents, requests and ideas

Thank you for your understanding and time. Have a nice

Ian-T 15,605 Reputation points Microsoft External Staff Moderator

2026-11-05T01:18:11.38+00:00

Hi

Just checking in to see how things go, feel free to give me an update

Answer 2

This behavior matches a Microsoft account that uses a third-party or non-Outlook address as the sign-in alias. In that case, Teams and related meeting response flows can use a generated outlook_[long series of letters and numbers]@outlook.com address or another alias instead of the expected primary address, and acceptance/decline responses can fail or bounce.

The supported self-service action is:

Open Edit account info: https://account.live.com/names/manage
Select Add email.
Create a new Outlook.com alias.
Set that new Outlook.com alias as the primary alias.
Keep the existing domain address as a secondary alias if sign-in with that address is still needed.
Sign out of Teams and Outlook, then sign back in.

Important supported facts:

Aliases on a Microsoft account share the same password, contacts, storage, subscriptions, and account settings.
The primary alias is the one that appears on devices and is the address Microsoft account experiences commonly use.
Personal Microsoft accounts and Microsoft 365 work or school accounts cannot be merged.
If the account is showing the "Which account do you want to use?" prompt because both a personal account and a work or school account use the same email address, changing the personal account’s primary alias can remove that conflict.

What cannot be done from the documented self-service options:

There is no documented way here to directly edit or remove the generated internal Teams/Outlook response address if it is tied to how the Microsoft account is configured.
Support agents are not allowed to access and change account details directly.

If the Outlook.com alias workaround has already been tried and the problem still persists, the remaining documented path is to use Microsoft Support through the account support flow.

References: