![]() The problem is strictly an application behavioral problem. ![]() The problem is NOT one of mail flow or really anything to do with mail. The domain has not and cannot be verified, those folks don't have the ability to do that. Separately an employee here signed up for and starting allocating 365 accounts. If nobody ever signed up for Office 365 then everything would be working 100% perfectly. ![]() ![]() A completely traditional 100% on premises domain network, with all related internal & external DNS. This is a "parallel" deployment where we have a fully functioning Exchange 2016 + Outlook 2016 deployment working. this is exactly the problem I had searching for an answer. I suspect there is a setting within the Office 365 admin that tells it where mail actually lives and to stop doing this, but I can't find the setting and I can't come up with the search terms to describe this phenomenon. This plays out on iPhones, Windows PCs, etc. ![]() You can actually watch this happen - for example in Outlook 365 on my Android tablet, when I add account, and enter my domain email address the banner instantly changes to "Office 365" and it rejects my domain password, but accepts my office365 password. and add account, it instantly recognizes the user account as a valid Office 365 user and then tries to get mail settings for that user from Office 365 instead of from autodiscover. When you use Outlook 365, or Windows Mail, etc. This problem is specific to certain Microsoft apps, or Office 365. The problem isn't with DNS - the on-premises Exchange and everything related works fine, MX is point to Exchange, autodiscover works properly. When you open Outlook 2016 and "add account" it goes off and looks for autodiscover and everything works properly. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2022
Categories |