Microsoft 365 EEA tenants: IMAP OAuth reliability issues

[macistda]

Hello EspoCRM Team,

we are experiencing a critical issue with Microsoft 365 email integration after Microsoft enforced the migration of our tenant to EEA (European Economic Area) / EU Data Boundary licenses.
Based on our analysis and Microsoft’s official documentation, this appears to be a structural compatibility issue, not a configuration problem.

---

Environment

• EspoCRM (self-hosted, on-premises)
• Microsoft 365 Exchange Online (EEA tenant)
• Inbound email: IMAP + OAuth 2.0 (XOAUTH2)
• Outbound email: SMTP / OAuth
• Security Defaults disabled
• Conditional Access explicitly allows the sign-in

---

Observed behavior


We consistently observe the following pattern:

• IMAP + OAuth may stop working after the EEA migration
• In some cases, the connection starts working again after a new OAuth token is issued
• However, the timing of token renewal or re-authorization cannot be controlled
• This makes the behavior inconsistent and unpredictable
• EspoCRM reports a generic connection error without a specific error code
• Azure Entra ID sign-in logs show successful authentication
• Exchange Online appears to silently reject the OAuth token during IMAP authentication

This leads to a situation where:

• Some users or tenants work temporarily
• Others fail
• Functionality may return after a token renewal, but cannot be relied on as a permanent solution

---

Microsoft documentation confirming the underlying risk

1) IMAP is a legacy protocol


Microsoft explicitly classifies IMAP (as well as POP and SMTP AUTH) as legacy protocols and recommends Microsoft Graph instead:

“IMAP, POP, and SMTP AUTH are legacy protocols.”
“Microsoft recommends using Microsoft Graph.”
Microsoft Learn:
https://learn.microsoft.com/exchange...by-using-oauth

---

2) OAuth over IMAP has strict limitations


According to Microsoft documentation:

• IMAP supports delegated permissions only
• Application permissions and client-credentials flow are not supported
• OAuth token validation is strict and sensitive to tenant, region, and token lifecycle changes

“IMAP, POP, and SMTP AUTH support delegated permissions only.”
Microsoft Learn (same article)

---

3) Microsoft Graph is the long-term supported approach


Microsoft clearly states:

“Use Microsoft Graph to access mailbox data instead of Exchange Online legacy protocols.”
Microsoft Learn – Outlook mail in Microsoft Graph:
https://learn.microsoft.com/graph/ou...ncept-overview

IMAP OAuth is tolerated, but not a future-proof or reliable integration model.

---

Impact on EspoCRM


EspoCRM currently:

• Requires IMAP for inbound email
• Supports Microsoft Graph only for outbound email
• Depends on OAuth over a legacy protocol for inbound mail

As a result:

• Mail retrieval reliability depends on OAuth token lifecycle events
• Temporary recovery after token renewal is possible, but not deterministic
• Administrators have no control over when token renewal occurs
• This does not represent a stable or supportable long-term solution

---

Why this must be addressed long-term


Because IMAP OAuth is:

• a legacy protocol
• increasingly restricted by Microsoft
• sensitive to token lifecycle changes

similar issues are expected to:

• reoccur after future Microsoft platform changes
• affect additional tenants over time

EEA tenants are impacted earlier, but this is not limited to EEA.

---

Request / questions


We would like to ask:

1. Is Microsoft Graph API support for inbound email on EspoCRM’s roadmap?
2. Has EspoCRM validated IMAP OAuth specifically with Microsoft 365 EEA / EU Data Boundary tenants?
3. Does EspoCRM consider the current IMAP-based approach sustainable given Microsoft’s direction?

From an operational perspective, this already represents a blocking issue for some Microsoft 365 customers.

We would appreciate clarification on EspoCRM’s long-term strategy regarding Microsoft 365 inbound email integration.

Kind regards

[yuri]

Hi,

Is there some reliable confirmation that OAuth over IMAP won't work after access token renewal or will work but not reliably?

Microsoft has been calling IMAP as a legacy protocol for long. It's quite weird and unfair for their side. I believe IMAP will be there for more 50-100 years. If Microsoft really decides to shut it down (what I don't believe will happen soon), we would need to implement mail fetching over their API. It'd be a big overhaul that we would like not to hurry up with.

[macistda]

Hi Yuri,

thanks a lot for your quick response – much appreciated.
I put together the following summary with some help from ChatGPT, as it took roughly one and a half days to diagnose and stabilize the situation 🙂

As a side note: I also noticed that we need to re-order the extensions; I will apply that change shortly.

---

Current behavior

• At the moment, IMAP + OAuth works for some users and does not work for others
• There are no configuration differences between those users
• In our environment, it appears that it may start working again after a new OAuth token is issued
• It may also start working automatically after some time; I will continue to monitor this

---

Reliability concerns

• The token renewal process cannot be controlled
• Therefore, this behavior is not reliable and not suitable as a permanent solution
• From an operational perspective, the behavior is inconsistent and unpredictable

---

Azure / Entra ID prerequisites (EEA tenants)

To make IMAP OAuth work at all in Microsoft 365 EEA tenants, the Azure / Entra ID configuration must be relaxed:

• Security Defaults disabled
• Conditional Access explicitly allowing this flow
• Most likely an Entra ID license is required, otherwise these settings cannot be configured

Even with this reduced-security setup, results still differ between users.

---

Summary

The concern is not that IMAP as a protocol will disappear soon,
but that OAuth over IMAP in Microsoft 365 is already fragile today and strongly dependent on token lifecycle behavior — especially in EEA tenants.

---

Actions taken after EEA migration

• Created a new Azure App Registration (deleted the old one) — this appeared to be mandatory
• Updated EspoCRM settings:
  • Tenant: Organizations
  • Authorization Prompt: select_account
    Without these settings, OAuth authentication did not work
• For Group Folders, the affected user had to log in and request an OAuth token explicitly
  (temporarily granting EspoCRM admin rights and reverting them afterwards)
• Disabled the Microsoft security setting “Legacy authentication not allowed”
  (not directly configurable, but implicitly disabled after switching to Conditional Access in Entra ID)

---

Suggestion

As a possible workaround, it might help to provide a function to delete stored OAuth/API tokens per user, forcing EspoCRM to request a new token cleanly.

Best regards

[yuri]

What do you mean by "The token renewal process cannot be controlled"? A user signing in again will receive a new token. If this information is from ChatGPT, I'd ask to avoid conclusions that are ChatGPT output. LLMs are very inaccurate.

The previous access and refresh token are not reused when the user (in Espo) signs in to Microsoft via the OAuth flow. After disconnecting and connecting a new access token and refresh tokens are issued. The access token is renewed every 1-2 hours, refresh token is reused until the next sign in, or its expiration due to long inactivity.

I believe if they had already started to introduce measures like random request failing or limiting token lifetime, they would have informed about it (like they did before I believe). It would have been quite a bad move from them otherwise.

Killing IMAP would mean that almost all email clients out there will stop working with MS accounts. All still use IMAP only as far as I know.

[macistda]

Hi Yuri,

no, it is not relied on ChatGPT. I only used it for summary.
What I know is that max. lifetime for MFA reduced from 360 to 90 days with EEA Licence.

I guess that it is MS Plan to kill other clients using IMAP in perspective.

They can't kill random requests, that is not the point.

[yuri]

We'd need to investigate more. If the token lifetime is short it would affect both IMAP XOauth and Graph API. They use the same authentication.

[yuri]

Even with 90 days refresh token lifetime, if there was any activity, it's supposed to be updated with the new one that MS sends upon access token update if the previous refresh token expires (this behavior is not required by the standard though I belive).

[macistda]

What i am sure about that all was broken after migrating the O365 licence to EEA within same day. And that I had to create the Azure / Entra API new. With the old one there was no chance to get connected correctly.

Afterwards (after creation of new API) all users had to reauthenticate again. I wrote E-Mail to my collegues that they have to do that. Some where okay after reauthenticate and some where not.
I will look at that and monitor, because not all of them have done reauthentication yet.

[yuri]

The same actions would have been needed for Graph API use. So far we don't have any confirmation that there are issues specifically with IMAP.

[macistda]

We'll see, because this year we're redesigning our own interface between Espo and Exchange Online (via EWS).

We're using this custom interface for automated appointment syncing, contact syncing, task syncing with multiple calendars, O365 invitations, recurring appointments, and status updates (I think via webhooks). (Not for E-Mail send and receive). The Espo Extension is a requirement for that.

Currently, and also during the EEA change, this own developed interface via Azure API continued to work without interruption.