Beaucoup d’entreprises ont encore des flux email silencieux dans Microsoft 365.
Une imprimante qui envoie un scan. Un ERP qui transmet une facture. Un outil de supervision qui alerte l’astreinte. Un NAS, un outil de ticketing, une application métier ancienne.
Ces flux ont souvent un point commun : ils utilisent smtp.office365.com avec un identifiant et un mot de passe.
Le sujet n’est donc pas théorique. Quand Microsoft retire progressivement l’authentification Basic pour SMTP AUTH dans Exchange Online, ce sont ces envois discrets qui peuvent casser en premier.
Mise à jour importante sur la chronologie
Microsoft avait annoncé une suppression progressive entre le 1er mars 2026 et le 30 avril 2026.
Mais l’éditeur a publié une mise à jour de calendrier le 27 janvier 2026, puis une mise à jour de version le 29 janvier 2026.
La nouvelle trajectoire est la suivante :
- jusqu’à décembre 2026, le comportement de SMTP AUTH Basic reste inchangé ;
- fin décembre 2026, SMTP AUTH Basic sera désactivé par défaut pour les tenants existants, avec possibilité d’activation par les administrateurs si nécessaire ;
- pour les nouveaux tenants créés après décembre 2026, SMTP AUTH Basic sera indisponible par défaut ;
- au second semestre 2027, Microsoft doit annoncer la date de retrait final.
Source officielle : Exchange Team Blog, Microsoft Community Hub.
Ce report ne doit pas être lu comme une annulation.
C’est du temps en plus pour inventorier, tester et migrer proprement.
Ce qui disparaît vraiment
Le point clé est simple : SMTP ne disparaît pas.
Ce qui est visé, c’est l’authentification legacy par login et mot de passe pour SMTP AUTH dans Exchange Online.
Autrement dit, le problème n’est pas d’envoyer un email en SMTP. Le problème est d’utiliser une méthode d’authentification ancienne, difficile à protéger correctement et très exposée au vol de mots de passe.
Microsoft rappelle d’ailleurs que SMTP AUTH peut utiliser l’authentification moderne avec OAuth, en plus de l’authentification Basic.
Source officielle : Enable or disable SMTP AUTH in Exchange Online.
Pourquoi les imprimantes et applis métier sont exposées
Les postes modernes utilisent rarement SMTP AUTH directement.
Le risque vient plutôt des équipements et applications qui ont été configurés une fois, puis oubliés :
- imprimantes multifonctions ;
- scanners scan-to-mail ;
- ERP ;
- logiciels de facturation ;
- supervision ;
- ticketing ;
- NAS ;
- applications internes ;
- scripts PowerShell ou tâches planifiées ;
- anciens connecteurs SMTP.
Ces flux sont souvent critiques, mais peu visibles.
Le jour où l’authentification échoue, l’entreprise découvre que les factures ne partent plus, que les scans n’arrivent plus, ou que les alertes ne sont plus envoyées.
Première question : l’application supporte-t-elle OAuth2 ?
Si l’application ou l’équipement supporte OAuth2 pour SMTP AUTH, c’est généralement la voie la plus propre.
Vous conservez SMTP AUTH, mais vous remplacez le couple login/mot de passe par une authentification moderne basée sur des tokens.
C’est particulièrement intéressant quand :
- l’éditeur supporte officiellement OAuth2 ;
- l’application est maintenue ;
- les permissions peuvent être documentées ;
- les comptes utilisés peuvent être isolés ;
- les logs d’authentification sont exploitables.
Dans ce cas, l’objectif n’est pas de contourner la fin de Basic. L’objectif est de moderniser l’authentification tout en gardant un transport SMTP compatible.
Si OAuth2 n’est pas possible : regarder le SMTP relay
Beaucoup d’imprimantes et scanners anciens ne savent pas faire OAuth.
Dans ce cas, une option robuste consiste à utiliser un SMTP relay via connecteur.
L’idée est différente : au lieu d’authentifier l’équipement avec le mot de passe d’une boîte aux lettres, on maîtrise le flux par un connecteur, une IP fixe ou un certificat selon l’architecture.
Ce choix peut être pertinent pour :
- des imprimantes sur un site avec IP fixe ;
- des équipements réseau qui n’évolueront pas ;
- des flux internes simples ;
- des environnements où l’on veut éviter un mot de passe de boîte aux lettres dans un appareil.
Le relay demande en revanche de bien cadrer les sources autorisées.
Un relais trop large devient vite une faiblesse de sécurité.
HVE : pour les flux applicatifs internes à volume
Microsoft propose aussi High Volume Email for Microsoft 365.
HVE vise les flux applicatifs et line-of-business qui envoient beaucoup d’emails, surtout dans le tenant.
La documentation Microsoft indique un point d’entrée SMTP dédié, smtp.hve.mx.microsoft, sur le port 587, avec TLS/StartTLS et authentification par identifiants HVE ou OAuth token.
Source officielle : Manage High Volume Email for Microsoft 365.
HVE peut être intéressant si :
- les envois sont majoritairement internes ;
- le volume est significatif ;
- le flux est applicatif ;
- l’entreprise veut séparer ces envois des boîtes utilisateurs classiques ;
- les équipes veulent un service mieux adapté aux envois automatisés.
Ce n’est pas forcément la réponse à tous les besoins externes ou transactionnels.
Il faut donc classer les flux avant de choisir.
Azure Communication Services Email pour l’applicatif
Pour les envois transactionnels applicatifs, internes et externes, Azure Communication Services Email peut être plus adapté.
L’approche change : on sort de la logique “une boîte Microsoft 365 envoie les emails” pour aller vers un service email applicatif.
ACS Email peut être utilisé via API, SDK, et Microsoft documente aussi un mode SMTP.
Sources officielles : Overview of Azure Communication Services email et Send email with SMTP.
Ce choix peut être pertinent pour :
- notifications applicatives ;
- emails transactionnels ;
- volumes plus importants ;
- applications qui doivent être découplées des boîtes utilisateurs ;
- projets où l’API est préférable au SMTP historique.
Il faut toutefois traiter le sujet comme un vrai service email : domaine d’envoi, authentification, réputation, suivi des erreurs, supervision et gouvernance.
Choisir selon le flux, pas selon l’urgence
Le mauvais réflexe serait de chercher une seule solution pour tout.
Une entreprise peut très bien avoir besoin de plusieurs réponses :
- OAuth2 pour une application moderne ;
- SMTP relay pour des scanners anciens ;
- HVE pour des flux internes à volume ;
- Azure Communication Services pour une application transactionnelle ;
- arrêt pur et simple pour des flux inutiles découverts pendant l’inventaire.
La bonne question n’est donc pas seulement : “Comment remplacer Basic ?”
La vraie question est : quel canal d’envoi correspond au risque, au volume et à la criticité du flux ?
Action immédiate : lister tout ce qui envoie
Avant de migrer, il faut savoir ce qui existe.
La méthode la plus utile :
- rechercher tout ce qui utilise
smtp.office365.com; - identifier les comptes SMTP AUTH encore actifs ;
- vérifier si les équipements savent faire OAuth2 ;
- classer les flux : interne, externe, volume, criticité ;
- séparer les imprimantes, les applications, la supervision et les emails transactionnels ;
- définir une cible pour chaque famille : OAuth, relay, HVE, ACS ou arrêt ;
- tester les flux critiques avant toute bascule ;
- documenter les propriétaires et les dépendances.
C’est souvent à cette étape que les bombes à retardement apparaissent.
Un équipement oublié dans une agence. Un compte partagé utilisé par trois applications. Un vieux logiciel de gestion qui envoie encore toutes les alertes depuis une boîte personnelle.
Conclusion
La fin de SMTP AUTH Basic dans Exchange Online ne signifie pas la fin de SMTP.
Elle signifie la fin progressive d’une méthode d’authentification legacy qui ne doit plus porter des flux critiques sans contrôle.
Le report annoncé par Microsoft donne du temps, mais pas une raison d’attendre.
Les entreprises doivent inventorier leurs envois via smtp.office365.com, identifier ce qui ne supporte pas OAuth2, puis choisir l’alternative adaptée : OAuth2, SMTP relay, High Volume Email ou Azure Communication Services Email.
Le bon objectif n’est pas seulement d’éviter une panne.
C’est de reprendre le contrôle sur les flux applicatifs qui envoient des emails au nom de l’entreprise.