Exchange Online : comment désactiver SMTP AUTH et sécuriser l’envoi d’e-mails

Dans de nombreux tenants Microsoft 365, SMTP AUTH reste activé alors que plus personne ne s'en sert, et c'est une porte d'entrée que les attaquants connaissent très bien.

Le copieur qui envoie les numérisations par e-mail, l'ERP qui expédie les factures, le script PowerShell qui notifie l'équipe IT chaque matin : ces usages s'appuient souvent sur le protocole SMTP AUTH d'Exchange Online, avec un compte de service et un mot de passe - stocké en clair - dans la configuration. Le problème, c'est que ce protocole reste ouvert pour toutes les boîtes aux lettres, même celles qui n'en ont jamais eu besoin, et qu'il est une cible de choix pour les attaques par password spraying.

Dans cet article, je vous propose de voir comment désactiver SMTP AUTH dans Exchange Online proprement, sans casser les flux légitimes. Nous commencerons par comprendre le fonctionnement des deux niveaux de configuration (organisation et boîte aux lettres), puis nous verrons comment auditer l'utilisation de SMTP AUTH dans votre tenant. Par la suite, nous désactiverons le protocole avec le centre d'administration Exchange et avec PowerShell, avant d'aller plus loin avec les stratégies d'authentification pour bloquer l'authentification basique. Enfin, nous ferons le tour des alternatives pour les applications et les imprimantes.

Qu'est-ce que SMTP AUTH ?

SMTP AUTH, aussi appelé « SMTP authentifié », permet à un client de s'authentifier auprès d'Exchange Online pour soumettre un e-mail, généralement sur le port TCP 587 avec le point de terminaison smtp.office365.com. C'est une méthode simple et adaptée pour les applications et les appareils (comme les copieurs multifonctions) qui génèrent et envoient des e-mails, sans pour autant être en mesure de supporter d'autres méthodes d'authentification.

SMTP AUTH prend en charge l'authentification basique (identifiant et mot de passe) et l'authentification moderne via OAuth 2.0. Autre point important : les clients de messagerie modernes (Outlook pour Windows, etc.) n'utilisent pas SMTP AUTH pour envoyer des e-mails. La désactivation de ce protocole n'a donc pas d'impact sur l'usage quotidien de vos utilisateurs.

Note : si vous souhaitez revoir les bases sur les protocoles de messagerie, consultez notre article Messagerie : découverte des protocoles SMTP, POP, IMAP et MAPI.

Deux niveaux de configuration : l'organisation et la boîte aux lettres

SMTP AUTH se pilote à deux niveaux sur un tenant Microsoft 365 :

  • Le paramètre de l'organisation, associé à la propriété SmtpClientAuthenticationDisabled. Il s'applique à l'ensemble du tenant.

  • Le paramètre de la boîte aux lettres, associé à la propriété du même nom sur chaque boîte aux lettres d'un utilisateur (Get-CASMailbox). Ce qu'il faut bien comprendre, c'est qu'il prend le dessus sur le paramètre de l'organisation.

Au niveau de la boîte aux lettres, la propriété SmtpClientAuthenticationDisabled peut prendre trois valeurs :

Valeur

Signification

Effet

$true

SMTP AUTH désactivé

La boîte aux lettres ne peut pas utiliser SMTP AUTH, quel que soit le paramètre de l'organisation

$false

SMTP AUTH activé

La boîte aux lettres peut utiliser SMTP AUTH, même si l'organisation l'a désactivé

$null (vide)

Hérite de l'organisation

La boîte aux lettres suit le paramètre défini dans Get-TransportConfig

En bref : désactiver SMTP AUTH au niveau de l'organisation ne suffit pas. Toutes les boîtes aux lettres dont la valeur est $false continueront d'accepter les connexions SMTP AUTH.

Désactiver SMTP AUTH ou bloquer l'authentification basique ?

Ces deux notions sont souvent confondues, alors qu'elles n'agissent pas au même endroit :

Mécanisme

Ce qu'il bloque

Effet sur SMTP AUTH avec OAuth

SmtpClientAuthenticationDisabled (organisation ou boîte aux lettres)

Le protocole SMTP AUTH lui-même

Bloqué aussi

Stratégie d'authentification Exchange Online (AllowBasicAuthSmtp)

L'authentification basique sur SMTP, avant même qu'elle n'atteigne Entra ID

Autorisé

Paramètres de sécurité par défaut d'Entra ID (security defaults)

L'authentification basique, et donc SMTP AUTH

Non pertinent : SMTP AUTH est désactivé

Accès conditionnel « bloquer l'authentification héritée »

Les connexions par authentification héritée, après la vérification du mot de passe

Autorisé

Dans la pratique, la bonne approche consiste à combiner les deux premiers mécanismes : SMTP AUTH désactivé partout, sauf pour quelques comptes identifiés, et l'authentification basique bloquée pour que ces comptes utilisent OAuth.

Attention : si les paramètres de sécurité par défaut sont activés dans votre tenant, SMTP AUTH est déjà désactivé dans Exchange Online. Pour utiliser SMTP AUTH, il faut alors désactiver les paramètres de sécurité par défaut, ce qui n'est pas anodin et doit s'accompagner de stratégies d'accès conditionnel équivalentes.

Pourquoi désactiver SMTP AUTH ?

Réduire la surface d'attaque de Microsoft 365

L'authentification basique ne permet pas d'appliquer l'authentification multifacteur (MFA). Un attaquant qui dispose d'une liste d'adresses e-mail peut donc tester des mots de passe courants via SMTP AUTH, sans jamais être confronté à une demande de MFA. C'est d'ailleurs une méthode documentée : quand un attaquant cible un compte, il s'appuie sur ce type de protocoles d'authentification non protégé par le MFA pour utiliser la technique d'attaque par password spraying.

Vous voulez un exemple ? En 2025, un botnet de plus de 130 000 appareils a ciblé les comptes Microsoft 365 en s'appuyant sur l'authentification basique. Plus récemment, une campagne basée sur TeamFiltration a compromis 7 comptes Microsoft 365, tous des comptes de service oubliés, protégés par un simple mot de passe et sans MFA. Ce profil de compte correspond exactement à celui que l'on retrouve derrière un usage SMTP AUTH : un compte créé pour un copieur ou une application, dont le mot de passe ne change jamais.

Le calendrier de fin de l'authentification basique pour SMTP AUTH

SMTP AUTH est le dernier protocole d'Exchange Online qui accepte encore l'authentification basique. Microsoft a annoncé son retrait en avril 2024, puis a révisé le calendrier à plusieurs reprises. Le calendrier en vigueur, publié par l'équipe Exchange le 27 janvier 2026, est le suivant :

Échéance

Ce qui change

Jusqu'à fin décembre 2026

Aucun changement : l'authentification basique fonctionne toujours avec SMTP AUTH

Fin décembre 2026

L'authentification basique pour SMTP AUTH est désactivée par défaut sur les tenants existants. Les administrateurs pourront encore la réactiver si besoin

Tenants créés après décembre 2026

L'authentification basique pour SMTP AUTH est indisponible par défaut. OAuth est la méthode prise en charge

Second semestre 2027

Microsoft annoncera la date de retrait définitif de l'authentification basique pour SMTP AUTH

À l'heure où j'écris ces lignes, Microsoft n'a pas précisé quel paramètre permettra de réactiver temporairement l'authentification basique après la bascule de fin décembre 2026. Vous pouvez retrouver l'historique de ce message sur cette page.

Autrement dit, si vous ne faites rien, vos appareils et applications qui utilisent SMTP AUTH avec un mot de passe risquent de cesser d'envoyer des e-mails dans un peu plus de deux mois. Autant prendre les devants. Pour davantage de contexte sur l'authentification basique et ses risques, vous pouvez lire l'article Microsoft 365 - Exchange Online : fin de vie pour l'authentification basique SMTP.

Prérequis

Pour suivre ce tutoriel, vous avez besoin des éléments suivants :

  • Un compte disposant du rôle Administrateur Exchange (ou Administrateur général) sur le tenant Microsoft 365.

  • Le module PowerShell ExchangeOnlineManagement installé sur votre poste. Si ce n'est pas le cas, suivez notre tutoriel PowerShell : comment installer le module Exchange Online V3 ?.

  • Pour la partie sur les journaux de connexion, un compte disposant au minimum du rôle Lecteur de rapports dans Microsoft Entra ID.

Toutes les commandes PowerShell de cet article sont à exécuter dans une session Exchange Online, donc autant vous y connecter dès maintenant (sauf si vous souhaitez tout faire via le Web).

# Installer le module Exchange Online (si nécessaire)
Install-Module -Name ExchangeOnlineManagement -Force

# Se connecter à Exchange Online
Connect-ExchangeOnline -UserPrincipalName [email protected]

Auditer l'utilisation de SMTP AUTH dans votre tenant

Avant de désactiver quoi que ce soit, il faut savoir qui utilise SMTP AUTH aujourd'hui. Désactiver le protocole à l'aveugle, c'est prendre le risque de bloquer l'envoi d'e-mails, et comme il peut s'agir de factures ou de numérisations des utilisateurs, autant éviter les problèmes.

Le rapport SMTP AUTH clients du centre d'administration Exchange

Microsoft propose un rapport dédié dans le centre d'administration Exchange. Pour y accéder, connectez-vous au centre d'administration Exchange, puis naviguez dans Rapports > Flux de courrier > Rapport sur les clients utilisant l'authentification SMTP (SMTP AUTH clients report).

Par défaut, le rapport affiche les 7 derniers jours, mais il y a surtout un délai pour qu'il soit alimenté. Élargissez la plage de dates jusqu'à 90 jours pour capter les usages ponctuels, comme un script mensuel ou un traitement de fin de trimestre. Vous avez la liste des messages envoyés via cette méthode, et surtout, vous pouvez savoir si l'authentification basique a été utilisée ou non.

Si vous souhaitez avoir des informations "en direct", consultez les flux de courrier directement. Voici un exemple en PowerShell :

Get-MessageTraceV2 -SenderAddress [email protected]

Received            Sender Address             Recipient Address            Subject        Status
--------            --------------             -----------------            -------        ------
22/10/2026 19:09:53 [email protected] [email protected] Test SMTP AUTH Delivered

Les journaux de connexion Microsoft Entra ID

Les connexions SMTP AUTH en authentification basique apparaissent aussi dans les journaux de connexion de Microsoft Entra ID. C'est une source intéressante, car elle montre également les tentatives échouées, et donc les éventuelles attaques en cours.

Connectez-vous au centre d'administration Microsoft Entra, puis accédez à Entra ID > Surveillance et intégrité > Journaux de connexion. Ajoutez la colonne Application cliente si elle n'est pas affichée (via Gérer l'affichage puis Modifier les colonnes). Ensuite, ajoutez un filtre sur Application cliente afin de sélectionner SMTP (cela va afficher uniquement ce qui nous intéresse ici). Pensez à effectuer la même opération sur l'onglet Connexions utilisateur (non interactives).

Journaux de connexion Microsoft Entra ID filtrés sur l'authentification héritée SMTP

En regardant les détails de l'authentification, vous pourrez voir qu'il s'agit de SMTP AUTH :

Note : si vous voyez des dizaines d'échecs de connexion SMTP sur des comptes qui n'ont aucune raison d'utiliser ce protocole, vous pouvez donc estimer que SMTP AUTH est utilisé contre vous.

L'état de la configuration avec PowerShell

Le rapport montre l'usage, mais pas la configuration. Pour savoir quelles boîtes aux lettres peuvent utiliser SMTP AUTH, il faut croiser le paramètre de l'organisation avec celui de chaque boîte aux lettres. Commençons par le paramètre de l'organisation :

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Si la valeur est True, SMTP AUTH est désactivé pour l'organisation. Si elle est False, il est activé.

Le script ci-dessous calcule ensuite l'état effectif de chaque boîte aux lettres, en tenant compte de l'héritage (une boîte aux lettres à la valeur $null).

# Récupérer le paramètre de l'organisation
$OrgSmtpAuthDisabled = (Get-TransportConfig).SmtpClientAuthenticationDisabled

# Calculer l'état effectif de SMTP AUTH pour chaque boîte aux lettres
$SmtpAuthReport = Get-CASMailbox -ResultSize Unlimited | ForEach-Object {

    if ($null -eq $_.SmtpClientAuthenticationDisabled) {
        # La boîte aux lettres hérite du paramètre de l'organisation
        $Source = "Organisation"
        $Disabled = $OrgSmtpAuthDisabled
    }
    else {
        # La boîte aux lettres a une valeur explicite qui prend le dessus
        $Source = "Boîte aux lettres"
        $Disabled = $_.SmtpClientAuthenticationDisabled
    }

    [PSCustomObject]@{
        DisplayName        = $_.DisplayName
        PrimarySmtpAddress = "$($_.PrimarySmtpAddress)"
        ValeurBoite        = $_.SmtpClientAuthenticationDisabled
        Source             = $Source
        SmtpAuthAutorise   = -not $Disabled
    }
}

# Afficher les boîtes aux lettres autorisées à utiliser SMTP AUTH
$SmtpAuthReport | Where-Object { $_.SmtpAuthAutorise } | Format-Table -AutoSize

# Exporter le résultat complet au format CSV
$SmtpAuthReport | Export-Csv -Path "C:\Scripts\Audit-SmtpAuth.csv" -NoTypeInformation -Encoding UTF8 -Delimiter ";"

Quelques explications sur ce script :

  • Get-CASMailbox -ResultSize Unlimited : récupère les paramètres d'accès client de toutes les boîtes aux lettres (utilisateurs, partagées, ressources).

  • Source : indique si l'état provient de l'organisation (héritage) ou d'une valeur explicite sur la boîte aux lettres.

  • SmtpAuthAutorise : est égal à True si la boîte aux lettres peut effectivement utiliser SMTP AUTH.

  • Export-Csv : le délimiteur ; facilite l'ouverture du fichier dans Excel.

En croisant ce fichier avec l'export du rapport SMTP AUTH clients, vous obtenez la liste des comptes qui ont un réel besoin (ils apparaissent dans le rapport) et celle des comptes autorisés sans raison (ils n'apparaissent que dans l'audit PowerShell).

Le script PowerShell précédent a permis de mettre en évidence que SMTP AUTH était autorisé sur le compte d'un utilisateur.

Désactiver SMTP AUTH pour toute l'organisation

Une fois les usages légitimes identifiés et documentés, vous pouvez désactiver SMTP AUTH au niveau de l'organisation. Les comptes qui en ont encore besoin feront l'objet d'une exception au niveau de leur boîte aux lettres (voir la section suivante).

Attention : si des comptes légitimes utilisent SMTP AUTH en héritant du paramètre de l'organisation (valeur $null), configurez d'abord leur exception avec $false, puis désactivez SMTP AUTH pour l'organisation. Dans le cas contraire, ces comptes seront bloqués.

Depuis le centre d'administration Exchange

La procédure est la suivante :

  1. Connectez-vous au centre d'administration Exchange.

  2. Accédez à Paramètres > Flux de courrier.

  3. Dans la section Sécurité, cochez l'option Désactiver le protocole SMTP AUTH pour votre organisation (Turn off SMTP AUTH protocol for your organization).

  4. Cliquez sur Enregistrer.

Option Désactiver le protocole SMTP AUTH pour votre organisation dans les paramètres de flux de courrier d'Exchange Online

Avec PowerShell

La même opération s'effectue avec une seule commande accompagnée d'une autre commande pour la vérification :

Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Vous devez obtenir la sortie suivante :

SmtpClientAuthenticationDisabled : True

Pour revenir en arrière, il suffit de passer la valeur $false.

Gérer SMTP AUTH au niveau des boîtes aux lettres

Faire le ménage dans les valeurs explicites

Commencez par lister les boîtes aux lettres qui ont une valeur explicite à $false, car elles contournent le paramètre de l'organisation :

Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
    Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled

Pour chaque boîte aux lettres qui ne fait pas partie de vos exceptions documentées, deux approches sont possibles :

  • Remettre la valeur à $null : la boîte aux lettres suit le paramètre de l'organisation. C'est l'approche que je vous recommande, car elle garde une configuration lisible : l'organisation définit la règle, et seules les exceptions ont une valeur explicite.

  • Forcer la valeur à $true : la boîte aux lettres reste bloquée même si quelqu'un réactive un jour SMTP AUTH au niveau de l'organisation. Cette approche apporte une protection supplémentaire, mais elle multiplie les valeurs explicites, ce qui complique les audits. Elle peut avoir du sens pour des comptes sensibles (administrateurs, direction).

La commande précédente a bien mis en évidence le compte identifié lors de l'audit :

DisplayName PrimarySmtpAddress         SmtpClientAuthenticationDisabled
----------- ------------------         --------------------------------
Chris Tal   [email protected]                            False

Le script suivant remet à $null toutes les valeurs $false, sauf pour les comptes listés dans $Exceptions :

# Comptes autorisés à utiliser SMTP AUTH (vos exceptions documentées)
$Exceptions = @(
    "[email protected]",
    "[email protected]"
)

# Identifier les boîtes aux lettres avec SMTP AUTH explicitement activé, hors exceptions
$MailboxesToReset = Get-CASMailbox -ResultSize Unlimited | Where-Object {
    $_.SmtpClientAuthenticationDisabled -eq $false -and
    "$($_.PrimarySmtpAddress)" -notin $Exceptions
}

# Remettre la valeur à $null pour suivre le paramètre de l'organisation
# MODE SIMULATION : retirez -WhatIf après avoir vérifié la liste des boîtes aux lettres concernées
foreach ($Mailbox in $MailboxesToReset) {
    Set-CASMailbox -Identity $Mailbox.Identity -SmtpClientAuthenticationDisabled $null -WhatIf
}

Le paramètre -WhatIf affiche les modifications sans les appliquer. Exécutez le script une première fois avec ce paramètre, contrôlez la liste, puis relancez-le sans -WhatIf.

Autoriser SMTP AUTH pour un compte précis

Pour les comptes qui ont réellement besoin de SMTP AUTH (en attendant une migration vers une autre méthode), activez le protocole au niveau de leur boîte aux lettres uniquement :

# Autoriser SMTP AUTH pour une boîte aux lettres précise
Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

# Vérifier la valeur appliquée
Get-CASMailbox -Identity [email protected]| Format-List SmtpClientAuthenticationDisabled

Bien entendu, vous profiterez de ces travaux pour documenter cette configuration et les éventuelles exceptions mises en place. Dans tous les cas, je vous recommande d'utiliser un compte dédié par usage, avec un mot de passe robuste et unique.

Depuis le centre d'administration Microsoft 365

Pour une modification ponctuelle, l'interface graphique fait aussi l'affaire :

  1. Ouvrez le centre d'administration Microsoft 365 et accédez à Utilisateurs > Utilisateurs actifs.

  2. Sélectionnez l'utilisateur, puis l'onglet Courrier.

  3. Dans la section Applications de messagerie, cliquez sur Gérer les applications de messagerie.

  1. Cochez ou décochez SMTP authentifié (coché = activé, décoché = désactivé), puis cliquez sur Enregistrer les modifications.

Bloquer l'authentification basique sur SMTP avec une stratégie d'authentification

Désactiver SMTP AUTH règle le cas des comptes qui n'en ont pas besoin. Mais pour les comptes que vous avez laissés en exception (le copieur, l'ERP, etc.), posez-vous la question suivante : comment s'authentifient-ils ? SMTP AUTH accepte deux méthodes :

  • L'authentification basique : le client envoie un identifiant et un mot de passe (commande AUTH LOGIN, qui apparaît sous la valeur TlsAuthLogin dans le rapport SMTP AUTH clients). C'est cette méthode que les attaquants exploitent, et c'est elle que Microsoft va désactiver par défaut à la fin décembre 2026.

  • L'authentification moderne (OAuth 2.0) : le client présente un jeton délivré par Microsoft Entra ID (commande AUTH XOAUTH2). Aucun mot de passe ne transite.

Le paramètre SmtpClientAuthenticationDisabled ne fait pas la différence entre les deux : il autorise ou interdit le protocole dans son ensemble. C'est là qu'interviennent les stratégies d'authentification d'Exchange Online. Elles agissent uniquement sur l'authentification basique, protocole par protocole. Avec le paramètre AllowBasicAuthSmtp à False, un compte autorisé à utiliser SMTP AUTH ne peut plus se connecter avec un identifiant et un mot de passe : il ne lui reste qu'OAuth.

En combinant les deux mécanismes, vous obtenez trois situations possibles pour un compte :

SMTP AUTH sur la boîte aux lettres

Stratégie d'authentification

Résultat

Désactivé

Peu importe

Aucun envoi SMTP AUTH possible, même en OAuth

Activé

Bloque l'authentification basique sur SMTP

Envoi possible uniquement en OAuth

Activé

Autorise l'authentification basique sur SMTP

Envoi possible avec un identifiant et un mot de passe (état le plus à risque)

Les stratégies d'authentification ont un autre avantage par rapport à l'accès conditionnel : le blocage intervient à la toute première étape, quand le client envoie ses identifiants à Exchange Online, avant que la demande n'atteigne Microsoft Entra ID. Les attaques par brute force ou par pulvérisation de mots de passe sont coupées rapidement, sans atteindre le fournisseur d'identité.

Créer une stratégie par défaut qui bloque l'authentification basique

Vérifiez d'abord si une stratégie existe déjà dans votre tenant. Les paramètres de la page Paramètres > Paramètres de l'organisation > Authentification moderne du centre d'administration Microsoft 365 s'appuient sur des stratégies d'authentification. Si vous les avez déjà modifiés, une stratégie par défaut existe peut-être. Si c'est activé comme sur l'image ci-dessous, les deux méthodes sont possibles : login/mot de passe / OAuth.

Si aucune stratégie n'existe, créez-en une. Sans paramètre supplémentaire, une nouvelle stratégie bloque l'authentification basique pour tous les protocoles, y compris SMTP (toutes les options AllowBasicAuth* sont à False par défaut) :

# Créer une stratégie qui bloque l'authentification basique pour tous les protocoles
New-AuthenticationPolicy -Name "Block Basic Auth" -AllowBasicAuthSmtp:$false

# Définir cette stratégie comme stratégie par défaut de l'organisation
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"

# Vérifier la configuration
Get-AuthenticationPolicy -Identity "Block Basic Auth" | Format-List AllowBasicAuthSmtp
Get-OrganizationConfig | Format-Table DefaultAuthenticationPolicy

Si une stratégie par défaut existe déjà, modifiez-la plutôt que d'en créer une nouvelle :

# Bloquer l'authentification basique pour SMTP dans une stratégie existante
Set-AuthenticationPolicy -Identity "<Nom-De-La-Strategie>" -AllowBasicAuthSmtp:$false

La stratégie par défaut s'applique à tous les utilisateurs qui n'ont pas de stratégie assignée directement.

Note : l'authentification basique a déjà été retirée par Microsoft pour les autres protocoles d'Exchange Online (EWS, ActiveSync, POP, IMAP, PowerShell à distance, etc.). Bloquer tous les protocoles dans la stratégie n'a donc pas d'effet de bord sur ces derniers.

Prévoir une exception temporaire

Si un appareil ne sait pas encore faire autrement que l'authentification basique, il est toujours possible de créer une stratégie dédiée et de l'assigner uniquement au compte concerné :

# Créer une stratégie qui autorise l'authentification basique uniquement pour SMTP
New-AuthenticationPolicy -Name "Allow Basic Auth SMTP" -AllowBasicAuthSmtp

# Assigner cette stratégie au compte du copieur
Set-User -Identity [email protected] -AuthenticationPolicy "Allow Basic Auth SMTP"

# Appliquer la stratégie sous 30 minutes au lieu de 24 heures
Set-User -Identity [email protected] -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

Quelques précisions sur ces commandes :

  • -AllowBasicAuthSmtp : le commutateur sans valeur autorise l'authentification basique pour SMTP. Tous les autres protocoles restent bloqués.

  • Set-User -AuthenticationPolicy : une stratégie assignée directement à un utilisateur prend le dessus sur la stratégie par défaut.

  • -STSRefreshTokensValidFrom : force la prise en compte de la stratégie dans un délai de 30 minutes.

Gardez en tête que cette exception a une durée de vie limitée : elle ne survivra pas au retrait définitif de l'authentification basique, dont la date sera annoncée en 2027.

Tester et valider la configuration

Une fois la configuration en place, vérifiez l'état global avec le script d'audit présenté plus haut : seules vos exceptions documentées doivent apparaître avec SmtpAuthAutorise à True.

Côté client, une application qui tente de s'authentifier via SMTP AUTH sur une boîte aux lettres pour laquelle le protocole est désactivé reçoit une erreur de ce type :

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. Visit https://aka.ms/smtp_auth_disabled for more information.

Le message se termine par for the Tenant lorsque le blocage vient du paramètre de l'organisation, et par for the Mailbox lorsqu'il vient du paramètre de la boîte aux lettres. C'est un bon indice pour savoir où regarder lors d'un dépannage !

Lorsque l'authentification basique sera définitivement retirée pour SMTP AUTH, les clients qui l'utilisent encore recevront le message suivant :

550 5.7.30 Basic authentication is not supported for Client Submission.

Quelles alternatives pour les applications et les imprimantes ?

Désactiver SMTP AUTH, sur le papier, c'est bien joli, mais ce n'est pas sans contrainte. Surtout, cela implique de proposer une autre solution aux usages légitimes. Voici les options disponibles :

Solution

Principe

Destinataires

Points d'attention

SMTP AUTH avec OAuth 2.0

Même protocole, mais avec un jeton à la place du mot de passe (application Entra ID avec la permission SMTP.SendAsApp)

Internes et externes

SMTP AUTH doit rester activé sur la boîte aux lettres concernée. L'appareil ou l'application doit prendre en charge OAuth

High Volume Email (HVE)

Comptes HVE dédiés, sans licence, sur le point de terminaison smtp.hve.mx.microsoft (port 587)

Internes uniquement

Facturé à l'usage (paiement à l'utilisation Microsoft 365). Fonctionne même si SMTP AUTH est désactivé pour l'organisation

Relais SMTP avec connecteur

Connecteur entrant authentifié par adresse IP publique fixe ou certificat, envoi vers l'enregistrement MX du domaine (port 25)

Internes et externes

Nécessite une IP publique fixe. Pas de copie dans les éléments envoyés

Microsoft Graph

L'application envoie les e-mails via l'API sendMail plutôt qu'en SMTP

Internes et externes

Nécessite de modifier le code de l'application

Serveur Exchange local (hybride)

Relais via un connecteur de réception sur un serveur Exchange Server

Internes et externes

Uniquement si une infrastructure hybride existe déjà

Service d'envoi tiers

Service SMTP externe (transactionnel)

Internes et externes

Penser à mettre à jour SPF, DKIM et DMARC

Pour le relais par connecteur, suivez notre tutoriel Configurer Office 365 comme SMTP Relay. Et si vous envoyez des e-mails depuis des scripts PowerShell, sachez que Send-MailMessage est obsolète : vous pouvez envoyer des e-mails avec PowerShell grâce à MailKit, qui prend en charge OAuth.

Attention : ne remplacez pas SMTP AUTH par Direct Send (envoi anonyme vers votre enregistrement MX depuis n'importe quelle source). Cette méthode n'exige aucune authentification et elle est exploitée pour usurper des adresses internes. Il est d'ailleurs recommandé de la bloquer avec la commande Set-OrganizationConfig -RejectDirectSend $true.

Conclusion

Désactiver SMTP AUTH dans Exchange Online tient en une commande, mais le faire correctement demande un peu plus de méthode : comprendre la priorité du paramètre de la boîte aux lettres sur celui de l'organisation, auditer les usages réels, puis traiter les exceptions une par une. En combinant la désactivation du protocole avec une stratégie d'authentification qui bloque l'authentification basique, vous réduisez nettement la surface d'attaque de votre tenant Microsoft 365, tout en gardant la main sur le calendrier, plutôt que de subir la bascule prévue par Microsoft à la fin de l'année.

Si vous ne savez pas trop où vous en êtes, commencez par regarder vos journaux et faites l'audit dès maintenant. Il ne serait pas étonnant de constater que tout soit en ordre, ou à l'inverse, que la liste des comptes qui ont réellement besoin de SMTP AUTH est beaucoup plus courte que celle des comptes qui y ont accès.

N'hésitez pas à partager votre retour en commentaire.

Ajouter IT-Connect à mes
sources préférées

author avatar

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.

readers loved this