OAuth support for smtp authentication

Feature requests
1

Q1. End of support of smtp basic auth for Exchange Online
In the second half of 2025, Exchange Online will no longer support basic smtp authentication for sending emails.

Q2 - Who is impacted?
Every users of Exchange Online to send emails notifications.

Q3 - Why is it important and/or urgent?
End of support in the second half of 2025.

Solution
It will be necessary to use another protocol like OAuth to authenticate to Exchange Online.

2

Hello @hansolo57,
Thanks for bringing this to our attention!

We created an internal ticket for the development team (ref. PB-37583) for this request.

Best regards

3

Here is the official announcement to that effect:

Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) | Microsoft Community Hub

4

Hello @antony,

I just wanted to ask how far you are with that issue. Microsoft changed the timeline, but starting on 1st of March they will discontinue SMTP Basic Auth.

Thanks a lot!

5

Thanks for the heads up @Astriel07. Currently there was no movement on PB-37583, now that there is a deadline, we’ll have to move :slight_smile: .

1 Like
6

Hi @remy,

as we are also affected by this change and the updates for our other systems are happening right now, I wanted to check in real quick if theres any progress you can share on this topic.

Best,
Devrim

7

Hello @Dave,

We’re currently a bit stuck figuring out how to test this as we are not a Microsoft shop, we do not have a test environment. In your experience what is the minimal setup required to test using microsoft tools? Do we need to purchase microsoft360 with Exchange as well? Any advice welcome.

You can find our work on the specifications side here:
https://docs.google.com/document/d/10B3tJ7Ot9uWjH8hu1OwQGXwRBzL_Hs9-_7Lsdn2uF00/edit?usp=sharing

Cheers,

8

@remy as far as I am aware Microsoft offers M365 Demo Tenants with a 90-day temporary E5 developer subscription > https://developer.microsoft.com/en-us/microsoft-365/dev-program

We ourselfs created a second tenant that only holds a single E3 license to keep the price down.
As you already figured out the only thing the tenant really needs to do is provide an Entra application for the applicationId and clientSecret, as well as the mailbox for the email that is supposed to send.

So the minimum setup would be:

  • a microsoft tenant
  • an entra application with either delegated Office 365 Exchange Online Mail.Send permissions or application Mail.Send permissions and an ApplicationAccessPolicy to restrict which mailboxes the access applies to
  • a mailbox to send those mails

best regards

3 Likes
9

Timeline was updated:

  • Now to December 2026: SMTP AUTH Basic Authentication behavior remains unchanged.
  • End of December 2026: SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed.
  • New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method.
  • Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication.

https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835

10

:waving_hand: Hey Community members, we want to hear from you to help us design best solution for Exchange Online SMTP OAuth authentication support:

We noticed Microsoft provides multiple token grant flows, but these 2 are most relevant for the Passbolt:

  1. authorization code flow: With this flow one needs to perform an authorization via a consent screen. Paired with the offline_access scope it can return “refresh token” which can be stored and used to send emails. But it can get expired in various scenarios (example password is changed the user) then an administrators needs to give consent again without it the email sending can stop working.

  2. client credentials flow: This fits just fine with existing passbolt email settings flow where there’s no need to perform a consent. No need for manual user interaction also when token gets expired. But an added step here is to Register service principals in Exchange via Powershell. We are not sure if it’s generally people using Microsoft are already familiar with and doing frequently.

For detailed explanation and our thought process please refer to specification.

Feel free to provide your thoughts and comments so we better understand your requirements and provide the efficient solution accordingly.

Thank you for your attention.

11

@hansolo57, @DFLiddle, @Astriel07, @Dave
Any preferences before the project enters the development phase?

12

Thank you for asking! In October or November, I switched the email account in the installation I manage(d) to use one configured in Azure ACS, which works well for system and machine accounts and does not require OAuth. It allowed me to prepare systems well in advance for the scheduled deprecation of SMTP AUTH in M365.

1 Like
13

thanks for the reminder. In my experience the client credentials flow is pretty much always better as the authorization code flow requires a user that can interactively login while the client credentials flow does not. e.g. for shared mailboxes, we’ve had that case multiple times.

there could be a third solution to send through the graph api instead of smtp and give the entra application graph api permissions, that way you could avoid creating a service principal, though you might need an application access policy instead.

2 Likes