EAS can be heavily dependent on proper DNS - as outlook likes to refresh it's connection information from time to time.  We have found Outlook not stripping the trailing period off of server names when autodiscover is used - causing clients to fail to connect and sync properly.

There will most likely be issues with cached profiles.  Then consider whether NEW outlook is in use, or old -- as there are various problems between the two.

There are a whole myriad of issues that can be encountered.  Making sure your logfies are set to "Detailed" for the protocols in question may help at least diagnosing what's causing the issues.

There could be import problems bringing the data in that did not import properly - but that may not show it's face until the client tries to access the messages in question.

Devices should be double checked for lingering profiles / email account configurations - have their caches flushed if possible (powered off and restarted works wonders sometimes).

We gave up on Outlook mobile and have encouraged Thunderbird for mobile devices but that is out of the scope of your problems (and most likely not an option).  SmarterMail recommends emClient across the board as an Outlook alternative. It might be worth testing at least on one device and see if emClient is having the same problems Outlook is.

Our company has run SmarterMail for 3 years give or take but we don't use the EAS/EWS/MAPI.  In the end, logfiles set to their highest levels will be your friend in trying to track down the issue(s).

Oh I got you. Yes we have the log files at the highest and support has looked at them for me, but with no answers yet.

We have tried setting up these accounts on a totally new deployed machine. (Actually I just finished this about 10 minutes ago). With the exact same results, so I'm confident is not anything cached on the machine.

While yes, I agree with you, Outlook and MAPI are a mess, not using an advertised feature of Smartermail that we paid for is really not a viable solution if that makes sense. Actually it was the selling point during our testing, and even worked beautiful after the migration before the accidental domain deletion.

You need to triple and even quadruple check everything concerning that domain: DNS, domain controllers, permissions, everything.

It is entirely possible that there is an error or mistake or misconfiguration somewhere that was silently obscured in the background which has now reared its ugly head causing problems.

I completely agree on the feature-set and usability regarding what's offered and paid for!

I believe something has gotten corrupted in the data regarding the deleted domain - and you could additionally be seeing issues if clients are connecting while these migrations are taking place, etc. - as their activity alone can cause issues. Anytime we've done migrations, we do it in a fashion where nothing else is happening - no clients can connect, no incoming mail (temporarily) etc. Then you only have "one process" going on that's touching data.

My understanding is that all the issues started occurring when the domain was "deleted" then re-added/
migrated.

If I was dealing with this on one of my servers, my first test would be all DNS and client connectivity - server addresses, what IPs are actually connecting - making sure there's no VPNs or proxies in the way - Outlook has a habit of routing things through Microsoft servers and caching configurations, relying on MS as a middleman even if the client is connecting directly to do data, Microsoft is usually meddling in the autodiscover process.

After all that, move on to the data and possibly re-migrating everything:

Test source data and make sure it's still intact (the pre-migration data) - make sure clients can talk to it, use it, and so forth.

Then I would detach the destination domain, backup any of the "destination server data" for that domain to an "out of tree" location for holding, including any configuration files you find. Then I would clear all that out - to make sure that there are no "backup settings" somewhere, cached settings, etc.

Then I would attempt to "start fresh" with that domain (possibly after restarting SmarterMail just to make sure anything in memory and any connections to that domain are fully flushed). Re-try the migration, but again - make sure no clients are talking to it on the source or destination servers - hopefully migration logs would show if there are any import issues.

Then I would try to test the first user - make sure the webmail login works and the recovery stuff is set before trying clients. We've had issues in the past where if the user doesn't login to webmail at least once before anything else, their account behaves erratically.  

Then I would make sure the client devices are starting clean as well - one by one. Outlook sometimes has to be coaxed into connecting to third party servers and not O365. Additionally to that, some versions rely on Microsoft caching   Eventually, in this fashion - you'd find the gremlin that got you.

Somewhere in all this, something got cached, interrupted, migrated wrong, or whatever other random event - and that data sitting in some random file that's throwing the whole domain off.

I wish I could be better help but once you get into the weeds like this, there's not much to offer without almost being "live" and investigating.

first time I exported data from exchange, the early exported outlook users were having odd things happen. turned out it was the avast desktop av, specifically the mail scanning module.

A few thoughts, no guarantees:

- Make sure that clients can find your server, by creating both an Autodiscover A record and an Autodiscover SRV record

- Make sure that your clients should not find your old server by disabling as many exposed ports as possible.

- Test whether your clients have actually connected to your servers by sending a test message to an external account such as Gmail, then check the raw data to see if it came from your server

Office365 issues:

- I have seen an Outlook client connect to Office365 without authentication; outbound messages were accepted and the return-path was "outlook_<digitstring>@outlook.com".

- If you were using Office365 and clients are using New Outlook, I would worry that the intermediate Microsoft server might send the connection to Office365 even if the account is supposed to be closed.