SMTP Office 365 : réglages et authentification
ChatGPT
Claude
Gemini
Perplexity
GrokL’essentiel
Réglages SMTP Office 365 actuels : choisissez OAuth et la politique de boîte avec soin, puis validez SPF, DKIM, DMARC, limites d’envoi et livraison.
Le SMTP Office 365 offre trois méthodes d’envoi. Préférez la soumission SMTP client compatible OAuth sur smtp.office365.com, port 587, si une application envoie comme une boîte. L’envoi direct sert aux appareils qui n’écrivent qu’à votre organisation Microsoft 365. Le relais SMTP sert quand un connecteur peut identifier l’expéditeur et que l’application doit joindre l’extérieur. Microsoft documente les trois méthodes et leurs exigences.
En bref
Points clés
- La soumission SMTP client se connecte comme une boîte ; l’envoi direct et le relais SMTP, non.
- L’envoi direct se limite aux destinataires de votre organisation Microsoft 365 ; le relais SMTP joint l’extérieur via un connecteur approuvé.
- La sécurité du tenant et le réglage Authenticated SMTP de la boîte peuvent bloquer des valeurs correctes.
- Préférez OAuth. Toute exception d’authentification de base pour Client Submission (SMTP AUTH) doit expirer : Microsoft retire cette voie.
- Exchange Online documente
30messages par minute et10,000destinataires par jour pour une boîte. - L’acceptation SMTP ne prouve ni alignement DMARC ni placement en boîte.
Que vérifier avant de configurer le SMTP Office 365 ?
Vérifiez si l’application doit envoyer hors de l’organisation, si elle peut s’authentifier comme une boîte Exchange Online, et si son réseau a une identité stable pour un connecteur. Pour la soumission client, confirmez que l’application gère STARTTLS et une méthode d’authentification approuvée. Notez l’adresse From visible, le volume de destinataires, le type de message et tout besoin Envoyer en tant que (Send As).
Les consignes actuelles de Microsoft pour la soumission client indiquent smtp.office365.com, le port 587 recommandé ou le port 25, TLS/STARTTLS activé et les identifiants de la boîte. L’application doit envoyer depuis l’adresse utilisée pour s’authentifier, sauf si le compte a l’autorisation Send As (Microsoft : soumission SMTP client).
Vérifiez la politique avant de toucher à l’application. Selon Microsoft, SMTP AUTH prend en charge OAuth, peut être désactivé pour l’organisation et activé pour les boîtes qui en ont encore besoin. Les paramètres de sécurité par défaut peuvent désactiver SMTP AUTH, et les stratégies d’authentification bloquer l’authentification de base (Microsoft : activer ou désactiver SMTP AUTH). Ne désactivez pas un contrôle de sécurité du tenant juste pour connecter un ancien client.
Quelle méthode choisir ?
Les trois méthodes ne sont pas interchangeables :
- Soumission SMTP client (SMTP AUTH) : l’application se connecte comme une boîte sous licence et soumet via
smtp.office365.com, en général en STARTTLS sur le port587. Choisissez-la pour un expéditeur lié à une boîte, compatible OAuth et dans les limites documentées. - Envoi direct : l’appareil ou l’application envoie au point de terminaison MX Microsoft 365 du tenant sur le port
25, sans connexion de boîte. Il joint les destinataires de la même organisation Microsoft 365, mais ne relaie pas vers l’extérieur. Choisissez-le pour des avis internes d’un appareil incapable de SMTP AUTH. - Relais SMTP : l’appareil ou l’application envoie au point de terminaison MX Microsoft 365 du tenant sur le port
25, sans connexion de boîte. Un connecteur entrant identifie la source par IP publique statique ou certificat TLS et autorise le relais vers l’interne ou l’externe. Choisissez-le pour un expéditeur applicatif qui doit joindre l’extérieur et remplit les exigences du connecteur.
Le tableau actuel de Microsoft fixe le point de terminaison et le transport.
Confirmez que la soumission client est la bonne méthode avant de toucher à SMTP AUTH. Un test réussi à faible volume ne rend ni une boîte, ni l’envoi direct, ni un connecteur apte au marketing.
Comment configurer le SMTP Office 365 ?
1. Définir un expéditeur contrôlé
Exemple : alerts@example.com est une boîte Exchange Online. L’application enverra 240 alertes transactionnelles par jour, avec le From visible alerts@example.com, et un test vers Microsoft 365 plus une boîte hors du tenant. L’identifiant d’exécution o365-smtp-630184 ne contient aucune donnée client.
2. Saisir l’hôte et le transport
Indiquez le serveur smtp.office365.com, le port 587 et STARTTLS. Exigez la validation du certificat. Ne prenez pas le SSL implicite parce qu’un autre fournisseur utilise le port 465 : le tableau de Microsoft impose TLS/STARTTLS ici.
3. Configurer OAuth ou un identifiant approuvé
Utilisez le flux OAuth Microsoft documenté de l’application s’il existe. ID de tenant, inscription d’application, identifiants client, scopes, secrets, certificats et jetons sont propres au compte. Ne copiez jamais l’inscription d’un autre tenant et ne stockez pas de secret client dans le code source.
L’authentification de base n’est pas une conception durable pour Client Submission. Le calendrier actuel de Microsoft, publié en janvier 2026, est précis : rien ne change avant décembre 2026, et fin décembre 2026, l’authentification de base SMTP AUTH est désactivée par défaut pour les tenants existants. Les tenants créés après décembre 2026 ne l’ont pas du tout. Microsoft annoncera la date de retrait final au second semestre 2027 (Microsoft : calendrier révisé du retrait de l’authentification de base SMTP AUTH).
Lisez « désactivée par défaut » au mot près : cette nuance fixe le temps réel dont dispose une application. Ce n’est pas un retrait. Un tenant peut réactiver SMTP AUTH après décembre 2026, et SMTP AUTH avec OAuth n’est jamais touché (Microsoft : fin de l’authentification de base dans Exchange Online). Ce qui disparaît à cette date, c’est l’idée qu’un client en authentification de base continue de marcher sans que personne ne décide de le maintenir. Donnez donc à toute exception un responsable, une cible de migration OAuth et une expiration au plus tard en décembre 2026 : la date où le défaut bascule, pas celle de la fin du support, car c’est là qu’une exception sans suivi commence à échouer en silence après un changement du tenant.
4. Limiter SMTP AUTH à la boîte requise
Si SMTP AUTH est désactivé pour l’organisation mais que l’application approuvée l’exige, un administrateur autorisé peut activer SMTP authentifié pour cette boîte. Le chemin du centre d’administration Microsoft 365 : Utilisateurs, Utilisateurs actifs, l’utilisateur, Courrier, Gérer les applications de messagerie, puis SMTP authentifié (contrôles SMTP AUTH de Microsoft). Les paramètres de sécurité par défaut ou la stratégie d’authentification peuvent primer.
La capture officielle du centre d’administration montre ce contrôle sur une boîte exemple.
N’appliquez l’autorisation propre au compte qu’à la boîte requise.
5. Confirmer l’identité From et Send As
Gardez From égal à alerts@example.com pour le premier test. Si l’application s’authentifie comme service@example.com mais envoie comme alerts@example.com, accordez l’autorisation Send As restreinte via le processus Exchange autorisé. Selon Microsoft, le service renvoie 5.7.60 si le compte authentifié n’a pas cette autorisation dans ce scénario (soumission client Microsoft).
6. Envoyer un test traçable
Utilisez l’objet SMTP validation 2026-08-25 14:30 UTC et mettez o365-smtp-630184 dans une ligne de diagnostic non secrète. Notez l’heure, la réponse du serveur, la boîte authentifiée, From, le destinataire et la version de l’application. Ne notez jamais mot de passe, jeton d’accès, secret client ou corps de message privé.
Quel effet sur DMARC ?
SMTP AUTH contrôle l’accès de l’application à Exchange Online. DMARC vérifie si l’authentification SPF ou DKIM est alignée sur le domaine From visible. L’un peut réussir et l’autre échouer.
Selon Microsoft, la plupart des organisations qui n’envoient que via Microsoft 365 utilisent une politique SPF avec include:spf.protection.outlook.com. La valeur complète d’exemple est v=spf1 include:spf.protection.outlook.com -all, mais un domaine avec d’autres expéditeurs doit regrouper toutes les sources dans un seul enregistrement SPF et rester sous la limite de 10 requêtes (configuration SPF de Microsoft). Ne publiez pas de second SPF et ne copiez pas une politique qui omet de vrais expéditeurs.
Le DKIM de Microsoft 365 utilise deux CNAME de sélecteur : l’un signe, l’autre sert à la rotation. La documentation actuelle demande de récupérer les cibles CNAME du tenant dans Defender ou Exchange Online PowerShell, et déconseille de copier les exemples, car les domaines récents peuvent avoir un autre format de cible (configuration DKIM de Microsoft). N’utilisez jamais les cibles d’un autre tenant.
La section 4.4 de la RFC 9989 définit l’alignement et la réussite DMARC : au moins un mécanisme pris en charge doit s’authentifier et s’aligner sur le domaine From RFC5322 (RFC 9989). Un message accepté de alerts@example.com peut échouer à DMARC si les identifiants SPF et DKIM observés ne s’alignent pas sur example.com.
Valider la configuration
Vérifier le DNS
Interrogez l’unique enregistrement SPF, les deux CNAME de sélecteur DKIM Microsoft et _dmarc.example.com sur des résolveurs publics. Comparez exactement les cibles du tenant. Leur présence ne prouve ni le chemin utilisé ni la signature par Microsoft.
Vérifier le fournisseur et la boîte
Confirmez que la boîte approuvée existe, que l’état SMTP AUTH suit l’exception documentée, que la politique du tenant autorise la méthode et que Send As n’existe que là où il faut. Pour toute exception d’authentification de base, notez qui l’a approuvée, quel remplaçant OAuth prendra le relais et l’expiration tirée du calendrier vérifié de Microsoft.
Vérifier les en-têtes du message livré
Ouvrez la source brute et lisez l’en-tête Authentication-Results ajouté par le destinataire. La section 1.2 de la RFC 8601 explique le périmètre de confiance du destinataire : un champ présent ne fait pas foi pour autant (RFC 8601, section 1.2). Confirmez smtp.mailfrom, le header.d DKIM, le header.from visible et le résultat DMARC. L’analyseur d’en-têtes de Palisade lit les en-têtes fournis ; il ne voit ni identifiants Entra ni politique du tenant.
Rapports DMARC et livraison
Confirmez que la source Microsoft autorisée apparaît dans les données DMARC agrégées du domaine From visible. Envoyez le même test à une boîte externe et examinez acceptation, authentification, dossier et tout code d’état étendu. Le guide DMARC pour Office 365 couvre le déploiement de la politique, et DKIM pour Office 365 la signature en détail.
Si le test réussit mais que le tenant ne voit pas toutes les sources, l’agent DMARC de Palisade peut organiser les preuves DMARC agrégées du domaine. Smart DNS Deployment n’écrit que les enregistrements DNS approuvés par un humain. Il ne modifie ni Exchange, ni Entra, ni boîte, ni SMTP AUTH, et ne garantit pas le placement. Commencez avec Palisade quand le test montre que le suivi est le manque suivant.
Dépannage
Le serveur refuse l’authentification
Vérifiez le serveur et STARTTLS, puis voyez si les paramètres par défaut, SMTP AUTH au niveau organisation, l’état de la boîte ou la stratégie d’authentification bloque la méthode. Ne réessayez pas un secret en boucle et n’affaiblissez pas le tenant sans exception approuvée.
Send As renvoie 5.7.60
Gardez From égal à la boîte authentifiée ou accordez l’autorisation Send As restreinte à l’identité requise. N’accordez pas de larges droits d’emprunt d’identité pour un seul écart d’expéditeur.
Le client est limité
Microsoft documente 30 messages par minute, 10,000 destinataires par jour et jusqu’à 3 connexions SMTP simultanées en soumission client. Sa page sur SMTP montre 432 4.3.2 Concurrent connections limit exceeded en cas d’excès et une SubmissionQuotaExceededException après la limite de destinataires (limites de soumission SMTP de Microsoft). Mettez en file et cadencez au lieu d’ouvrir plus de connexions.
Le message part mais DMARC échoue
Comparez le domaine From avec header.d et smtp.mailfrom. Vérifiez les sélecteurs DKIM Microsoft et le vrai return path. N’assouplissez pas DMARC au lieu de réparer un expéditeur non aligné.
Le message est accepté mais n’arrive pas comme prévu
Vérifiez le sort exact chez le destinataire, les réponses, l’authentification, la réputation, le consentement et l’objet du message. L’acceptation par Exchange ne garantit pas la boîte, et changer de port ne répare ni réputation ni ciblage.
Limites de cette configuration
La procédure couvre la soumission SMTP client. Un relais SMTP en production exige un connecteur Exchange Online bien délimité, et l’envoi direct un test contrôlé vers l’interne. Ce guide ne couvre ni connecteurs Exchange sur site, ni architecture à fort volume, ni comptes Outlook.com grand public, ni logiciel incapable de suivre la politique de transport et d’autorisation du tenant.
Preuve
Sources et pour aller plus loin
Questions des lecteurs
Questions fréquentes
smtp.office365.com : le serveur SMTP Office 365 ?
Oui. Microsoft documente smtp.office365.com pour la soumission SMTP client authentifiée vers Exchange Online. Les autres méthodes Microsoft ont d’autres points de terminaison et modèles d’autorisation.
Faut-il le port 587 en SMTP Office 365 ?
Oui. Microsoft recommande le port 587 avec STARTTLS pour la soumission client et cite aussi le port 25. Suivez la méthode et le transport documentés au lieu de reprendre le port 465 d’un autre fournisseur.
SMTP Office 365 : OAuth possible ?
Oui. Microsoft documente OAuth pour SMTP AUTH. Inscription du tenant, autorisations et flux de jetons sont propres au compte : suivez les instructions Microsoft actuelles de l’application.
Authenticated SMTP prime-t-il sur la sécurité par défaut ?
Non. Selon Microsoft, la sécurité par défaut peut désactiver SMTP AUTH, et les stratégies d’authentification bloquer l’authentification de base. Une case de boîte n’annule pas tous les contrôles du tenant.
Quelles sont les trois méthodes SMTP d’Office 365 ?
Microsoft documente la soumission SMTP client, l’envoi direct et le relais SMTP. La soumission client s’authentifie comme une boîte. L’envoi direct n’a pas de connexion de boîte et se limite aux destinataires de l’organisation. Le relais SMTP utilise un connecteur approuvé au lieu d’une connexion de boîte et peut écrire à l’extérieur.
Puis-je envoyer comme boîte partagée, connecté en utilisateur ?
Oui, si le compte authentifié a l’autorisation Send As requise et que la méthode le permet. Validez From, SPF, DKIM et DMARC du message livré au lieu de supposer que l’autorisation crée l’alignement.
Rédigé par
Samuel ChenardCEO et cofondateur, Palisade
Samuel Chenard est CEO et cofondateur de Palisade, logiciel DMARC agentique pour équipes IT et MSP, d’un domaine à des milliers.
Lire Samuel →
