Preventing Outlook (Classic) Autodiscover Hijack to Microsoft 365 (AWS WorkMail)

Question

Our company has used AWS workmail for years, however recently, our users, have one by one, been affected by outlook hijacking & priorizing Microsoft Exchange.

This is really painful and has caused alot of stress and wasted time.

The only "solution" we have found to solve this and force outlook to use Workmail Exchange (and not Microsoft exchange) is by following these steps:

### STEP 1
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"DisableOffice365SimplifiedAccountCreation"=dword:00000001

> Don't forget to restart your computer

### STEP 2
Clearing any associated (office,outlook,etc..) stored credentials in the window credential manager

### STEP 3
Deleting your outlook profile

### STEP 4
Start outlook, create a new profile when prompted and then add your email as a Exchange 2013 type.

---

Alternatively, we could move our emails to Microsoft / other providers but workmail has been integrated within our systems reasonably deeply so it would be a fair amount of work to migrate.

---

Anyway for more contect, CHAT GPT explains the following (please let me know if any of this is wrong, I'm by no way an expert on this but it does match 100% what our users are experiencing):

This procedure is required due to changes made by Microsoft to how Outlook (Classic) performs Autodiscover and account provisioning. Recent Outlook versions aggressively prioritize Microsoft 365 / Exchange Online endpoints over third‑party Exchange services such as AWS WorkMail.

As a result, even when AWS WorkMail is correctly configured and functioning, Outlook may:
- Silently redirect the mailbox to Microsoft Exchange Online
- Display the error: “Your mailbox has been temporarily moved to Microsoft Exchange”
- Rewrite the Outlook profile to use outlook.office365.com

This behavior is triggered by:
- Microsoft’s hard‑coded Autodiscover priority rules
- Microsoft 365 shadow tenants created automatically when users sign into any Microsoft service
- Cloud‑first identity behavior built into modern Outlook builds

This is NOT caused by:
- AWS WorkMail
- DNS misconfiguration alone
- User error

Now the big question... and I'll write in big letters so no one can miss it (for clarity and not to be agressive just to be 100% clear).

# Is AWS planning to work with MICROSOFT to "FIX" this behaviour? Or provide a more viable solution?

Additionally, if anybody else has any insight/help, please let me know, it would be much appreciated.

PS: I've posted a similar message with MICROSOFT : https://learn.microsoft.com/en-us/answers/questions/5637884/preventing-outlook-(classic)-autodiscover-hijack-t

rePost-User-0864075 · Accepted Answer

It seems like neither Microsoft or AWS cares,

This is the answer from Microsoft support confirming it is by design...:

*Thank you for sharing the details of your situation. I completely understand how frustrating and time-consuming it can be when Outlook keeps prioritizing Microsoft 365 instead of AWS WorkMail. This issue occurs because Outlook (Classic) uses Autodiscover logic that is designed to favor Microsoft 365 endpoints, which can lead to “hijacking” the profile even though WorkMail is functioning correctly. Based on my research, there is no official roadmap or announcement indicating that Microsoft will revert or change the default Autodiscover logic that prioritizes Microsoft 365 endpoints. This behavior is by design in modern Outlook builds. *

AWS has already stated they can't do anything... so back to manually fixing everyone one by one.

Thats it's folks.

re:Post Agent · Answer

The issue you're experiencing with Outlook prioritizing Microsoft 365 over AWS WorkMail is a known challenge that affects WorkMail users. Your described workaround using registry modifications is indeed one of the approaches to force Outlook to use the correct autodiscover endpoint for AWS WorkMail.

The root cause is related to how newer versions of Outlook handle autodiscover protocols. Microsoft has been moving away from supporting Basic Authentication (which AWS WorkMail uses) in favor of modern authentication methods like OAuth and 2FA. This creates compatibility issues between AWS WorkMail and newer Outlook clients.

Regarding whether AWS is planning to work with Microsoft to fix this behavior or provide a more viable solution - there's no public information available about specific plans for AWS to collaborate with Microsoft on this issue. However, this is a significant pain point for WorkMail customers, as it affects core functionality with one of the most popular email clients.

For now, the registry modifications you've outlined are a valid workaround. The keys you're setting:
- "ExcludeExplicitO365Endpoint" prevents Outlook from prioritizing Microsoft 365 endpoints
- "ExcludeHttpsRootDomain" prevents certain autodiscover fallback methods
- "DisableOffice365SimplifiedAccountCreation" prevents the simplified Office 365 account creation process

In addition to your steps, ensuring your DNS is correctly configured with the proper CNAME record pointing to "autodiscover-service.mail.[region].awsapps.com" is important.

For a more permanent solution, AWS would need to implement modern authentication methods like OAuth for WorkMail to better integrate with newer Outlook clients, but there's no public timeline for such an implementation.  
**Sources**  
[AWS Workmail incompatibility with Microsofts new Outlook 365 Client | AWS re:Post](https://repost.aws/questions/QUjr6rnAb2R0qIirVTVJg8rQ/aws-workmail-incompatibility-with-microsofts-new-outlook-365-client)  
[Outlook autodiscover fails for new WorkMail mailboxes — points to wrong endpoint (autodiscover.mail.us-east-1.awsapps.com instead of autodiscover-service.mail.us-east-1.awsapps.com) | AWS re:Post](https://repost.aws/questions/QUQ4uJvhs6TySjirSsr4Hdjw/outlook-autodiscover-fails-for-new-work-mail-mailboxes-points-to-wrong-endpoint-autodiscover-mail-us-east-1-awsapps-com-instead-of-autodiscover-service-mail-us-east-1-awsapps-com)  
[features](https://aws.amazon.com/workmail/features/)  
[Enabling AutoDiscover to configure endpoints - Amazon WorkMail](https://docs.aws.amazon.com/workmail/latest/adminguide/autodiscover.html)

Preventing Outlook (Classic) Autodiscover Hijack to Microsoft 365 (AWS WorkMail)

STEP 1

STEP 2

STEP 3

STEP 4

Is AWS planning to work with MICROSOFT to "FIX" this behaviour? Or provide a more viable solution?

Add your answer

Relevant content