Fin du Basic Auth SMTP chez Microsoft Exchange Online : calendrier, erreur 550 5.7.30 et guide de migration

Depuis 2019, Microsoft élimine progressivement l'authentification Basic (nom d'utilisateur + mot de passe) de ses protocoles Exchange Online. EAS, POP, IMAP, EWS, PowerShell : tous ont été migrés vers Modern Auth fin 2022. Le dernier bastion restait SMTP AUTH Client Submission, le protocole utilisé par les imprimantes multifonctions, les scripts d'envoi et les applications métier pour soumettre des emails via smtp.office365.com sur le port 587.

En avril 2024, Microsoft a annoncé la fin de ce dernier bastion. Après plusieurs reports (septembre 2025, puis mars 2026), la timeline révisée de janvier 2026 donne un sursis supplémentaire mais le message reste clair : Basic Auth SMTP est condamné, et chaque organisation doit planifier sa migration.

Cet article détaille le calendrier exact, les systèmes impactés, les cinq alternatives disponibles et une check-list concrète de migration.

Qu'est-ce que Basic Auth SMTP et pourquoi est-ce un problème ?

L'authentification Basic pour SMTP fonctionne de manière simple : le client encode le nom d'utilisateur et le mot de passe en Base64 et les transmet au serveur dans la commande AUTH LOGIN ou AUTH PLAIN. Même si la connexion est chiffrée par TLS (STARTTLS sur le port 587), les credentials sont réutilisables, sans expiration et sans second facteur.

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: dXNlckBjYXB0YWluZG5zLmNvbQ==
S: 334 UGFzc3dvcmQ6
C: bW90ZGVwYXNzZQ==
S: 235 2.7.0 Authentication successful

Ce mécanisme pose trois problèmes majeurs :

OAuth 2.0 résout ces trois problèmes : les tokens sont temporaires (60 min par défaut), révocables, liés à un scope précis (SMTP.Send) et compatibles avec le MFA et l'accès conditionnel.

SMTP AUTH Client Submission vs SMTP Relay

Il est important de distinguer deux mécanismes d'envoi via Exchange Online :

Le retrait de Basic Auth ne concerne que Client Submission. Les relais SMTP basés sur l'adresse IP (option 2 de la documentation Microsoft) ne sont pas affectés.

Calendrier complet du retrait

Le calendrier a été révisé plusieurs fois. Voici la timeline consolidée au 19 février 2026 :

L'erreur 550 5.7.30

Après la désactivation, tout client tentant une authentification Basic recevra :

550 5.7.30 Basic authentication is not supported for Client Submission.

Cette erreur est un rejet permanent (code 5xx). Le serveur expéditeur ne réessaiera pas. Les emails ne sont pas mis en file d'attente : ils sont perdus immédiatement.

Qui est impacté ?

Toute application ou appareil qui envoie des emails via smtp.office365.com ou smtp-legacy.office365.com avec un nom d'utilisateur et un mot de passe est concerné.

Systèmes typiquement impactés

Comment identifier les expéditeurs en Basic Auth ?

Microsoft a mis à jour le rapport SMTP AUTH dans l'Exchange Admin Center (EAC) en octobre 2024 pour distinguer les connexions Basic Auth des connexions OAuth.

1. Connectez-vous à admin.exchange.microsoft.com
2. Allez dans Rapports > Flux de messagerie > Rapport clients SMTP Auth
3. Filtrez par type d'authentification pour isoler les expéditeurs en Basic Auth

Chaque ligne indique l'adresse de l'expéditeur, le nombre de messages et le type d'authentification utilisé.

Alternative 1 : OAuth 2.0 pour SMTP AUTH

C'est la solution recommandée par Microsoft pour les clients et applications capables de gérer des tokens OAuth.

Prérequis

1. Enregistrer une application dans Microsoft Entra (Azure AD)
2. Ajouter la permission SMTP.Send (flux interactif) ou SMTP.SendAsApp (flux applicatif)
3. Obtenir le consentement admin du tenant

Deux flux possibles

Session SMTP avec OAuth

Le client utilise le mécanisme SASL XOAUTH2 :

C: AUTH XOAUTH2 dXNlcj1hbGVydHNAY2FwdGFpbmRucy5jb20BYXV0aD1CZWFyZXIgZXl
KMGVYQUlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUo5Li4uAQE=
S: 235 2.7.0 Authentication successful

Le token Base64 encode user=alerts@captaindns.com suivi du Bearer token OAuth. Le token expire après 60 minutes ; le client doit gérer le renouvellement via le refresh token.

Limites

• Les imprimantes MFP et appareils IoT ne supportent généralement pas OAuth
• Nécessite un enregistrement d'application dans Entra ID
• Le flux Client Credentials requiert l'enregistrement d'un Service Principal dans Exchange Online via PowerShell

Alternative 2 : High Volume Email (HVE)

Le service HVE est conçu pour les envois internes à gros volume depuis des applications et appareils.

Quand utiliser HVE ?

HVE est adapté quand :

• L'appareil ne supporte pas OAuth (MFP, IoT)
• Les emails sont exclusivement internes (alertes, notifications, scan-to-email vers des boîtes du tenant)
• Le volume est élevé (pas de rate-limit sur les destinataires)

Création d'un compte HVE

Via l'EAC : Flux de messagerie > High Volume Email (Preview) > Ajouter un compte HVE.

Ou via PowerShell :

New-MailUser -HVEAccount -Name "Scanner Alerts" -PrimarySmtpAddress "scanner-alerts@captaindns.com"

Attention : HVE est en preview publique. Microsoft se réserve le droit de suspendre le service. Ne pas attribuer de licence aux comptes HVE.

Alternative 3 : Azure Communication Services Email

Azure Communication Services (ACS) Email permet l'envoi interne et externe via une API REST ou des SDK (.NET, Python, JavaScript, Java).

ACS est pertinent pour les applications cloud-native qui peuvent intégrer un SDK. Il n'est pas adapté aux appareils physiques (imprimantes, scanners) qui ne parlent que SMTP.

Alternative 4 : relais SMTP on-premises

Pour les organisations en configuration hybride (Exchange Online + Exchange Server on-premises), le relais SMTP local reste une option.

Fonctionnement

1. Les appareils (MFP, IoT, scripts) envoient vers le serveur Exchange local via le port 25 (anonymous relay)
2. Le connecteur Receive est configuré pour accepter les connexions depuis un réseau IP interne
3. Le serveur Exchange local relaye vers Exchange Online via le connecteur Send

Configuration du connecteur Receive

New-ReceiveConnector -Name "Anonymous Relay" `
  -TransportRole FrontendTransport `
  -Usage Custom `
  -Bindings 0.0.0.0:25 `
  -RemoteIPRanges 192.168.1.0/24 `
  -PermissionGroups AnonymousUsers

Avantages et inconvénients

Alternative 5 : Microsoft Graph API

Pour les scripts et applications, l'API Graph offre l'endpoint /users/{id}/sendMail qui remplace avantageusement SMTP.

curl -X POST "https://graph.microsoft.com/v1.0/users/alerts@captaindns.com/sendMail" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "subject": "Alerte monitoring",
      "body": {"contentType": "Text", "content": "Le serveur DNS est indisponible."},
      "toRecipients": [{"emailAddress": {"address": "ops@captaindns.com"}}]
    }
  }'

Graph API est idéal pour remplacer les scripts PowerShell (Send-MailMessage est déprécié) et les applications serveur. Il n'est pas adapté aux appareils hardware qui ne peuvent exécuter que du SMTP.

Tableau comparatif des alternatives

Check-list de migration

Impact sur la délivrabilité et la sécurité

Le retrait de Basic Auth n'affecte ni SPF, ni DKIM, ni DMARC. Ces protocoles d'authentification email fonctionnent au niveau DNS et restent indépendants de la méthode d'authentification SMTP.

En revanche, la migration offre une opportunité de renforcer votre posture de sécurité :

• MFA partout : OAuth permet d'imposer l'authentification multifacteur sur les comptes d'envoi interactifs
• Tokens révocables : contrairement à un mot de passe compromis qui reste valide jusqu'au changement, un token OAuth expire automatiquement
• Accès conditionnel : vous pouvez restreindre l'envoi SMTP à des plages IP, des appareils conformes ou des horaires spécifiques
• Audit granulaire : les connexions OAuth sont traçables dans les logs Entra ID avec le détail de l'application et du scope utilisé

Ce mouvement de Microsoft s'inscrit dans une tendance plus large. Google et Yahoo ont imposé des exigences d'authentification renforcées pour les expéditeurs en volume dès 2024. La sécurisation du canal d'envoi SMTP est la suite logique.

📖 Glossaire

• Basic Auth : méthode d'authentification transmettant le nom d'utilisateur et le mot de passe encodés en Base64. Aucune protection intrinsèque contre le rejeu.
• OAuth 2.0 : protocole d'autorisation basé sur des tokens temporaires. Supporte MFA et accès conditionnel.
• SASL XOAUTH2 : mécanisme SASL utilisé pour transmettre un token OAuth 2.0 dans une session SMTP, IMAP ou POP.
• Client Submission : méthode d'envoi SMTP authentifié via smtp.office365.com (port 587). L'expéditeur s'authentifie avec des credentials.
• SMTP Relay : méthode d'envoi SMTP basée sur l'adresse IP source, sans credentials. Utilise un connecteur entrant Exchange Online.
• HVE (High Volume Email) : service Microsoft 365 permettant l'envoi interne à gros volume via smtp-hve.office365.com. Preview publique.
• Microsoft Entra : nouveau nom de Azure Active Directory. Gère les enregistrements d'applications, les permissions et les tokens OAuth.
• Service Principal : identité d'application dans Exchange Online, nécessaire pour le flux Client Credentials OAuth.
• MFA : authentification multifacteur. Impossible avec Basic Auth, native avec OAuth 2.0.

Sources

• Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) - Exchange Team Blog, avril 2024
• Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline - Exchange Team Blog, janvier 2026
• Deprecation of Basic authentication in Exchange Online - Microsoft Learn
• Authenticate an IMAP, POP or SMTP connection using OAuth - Microsoft Learn
• Manage High Volume Email for Microsoft 365 - Microsoft Learn