terme · paramètres smtp office 365

Quels sont les paramètres SMTP d’Office 365 et quel est leur impact sur les e-mails applicatifs ?

Les détails SMTP Office 365 ne se résument pas à un hôte et un mot de passe universels. Microsoft documente plusieurs modèles pour applications et appareils, notamment la soumission client authentifiée via smtp.office365.com, le relais SMTP fondé sur un connecteur via l’endpoint MX du tenant et Direct Send vers des destinataires Microsoft 365 internes. Ils diffèrent par l’authentification, TLS, les ports, l’identité d’expéditeur, la prise en charge des destinataires externes, les licences, les limites et la configuration administrative. Choisissez le modèle selon la charge de travail et la limite de confiance, utilisez OAuth lorsque la soumission client s’applique, n’activez SMTP AUTH que de manière restreinte, testez les identités exactes d’enveloppe et From, et traitez l’acceptation par relais séparément de la livraison finale ou du placement en boîte de réception.

Les détails SMTP Office 365 décrivent plusieurs voies

La documentation de Microsoft 365 et d’Office 365 distingue la soumission SMTP client, le relais SMTP et Direct Send. La soumission client s’authentifie en tant que boîte aux lettres Exchange Online et envoie via smtp.office365.com. Le relais SMTP traite l’application ou l’appareil comme un serveur de messagerie de l’organisation et authentifie la connexion avec un connecteur entrant. Direct Send soumet de façon anonyme à l’endpoint MX Microsoft 365 du tenant, pour des destinataires de l’organisation. Ce sont des produits opérationnellement différents derrière des commandes SMTP similaires. Ne recopiez pas un nom d’hôte et un port depuis un forum sans avoir décidé quelle route vous visez. Consignez d’abord le tenant, les domaines acceptés, l’administrateur, la charge, les identités d’expéditeur, le réseau source, le périmètre des destinataires, la méthode d’authentification, la politique TLS, le volume et le responsable des échecs. Le transport SMTP n’autorise pas l’événement métier d’origine, n’établit pas le consentement du destinataire et ne rend pas durable une file d’attente applicative.

Paramètres de la soumission SMTP client

Le guide de configuration actuel de Microsoft désigne smtp.office365.com comme nom DNS de soumission client et indique de ne pas le remplacer par une adresse IP. Il recommande le port TCP 587, autorise le port 25 dans le scénario documenté, et exige TLS 1.2 ou TLS 1.3 avec STARTTLS activé. L’application s’authentifie en tant que boîte aux lettres Microsoft 365 ou Office 365 disposant d’une licence et peut envoyer à des destinataires internes et externes dans les limites documentées. Utilisez l’adresse de la boîte aux lettres comme identité explicite, et testez les autorisations Send As lorsque le From visible est différent. Conservez les identifiants ou les jetons dans un gestionnaire de secrets côté serveur. Une connexion réussie au compte ne prouve pas que le From visible est autorisé, que le destinataire est valide ni que le message atteindra une boîte de réception. La soumission client est une route liée à une boîte aux lettres : la suspension d’un utilisateur, un changement de licence, une décision d’accès conditionnel ou les paramètres SMTP AUTH peuvent interrompre une application par ailleurs inchangée.

Utilisez OAuth et n’activez SMTP AUTH que de façon ciblée

Microsoft recommande l’authentification moderne avec OAuth pour la soumission SMTP client. Sa documentation OAuth définit le scope SMTP.Send et le format SASL XOAUTH2, avec des flux délégués et des flux orientés application soumis à l’inscription dans Microsoft Entra et aux permissions Exchange. Traitez les jetons d’accès et d’actualisation comme des secrets, ne demandez que les permissions nécessaires, validez le rattachement au tenant et à la boîte aux lettres, faites la rotation des identifiants de l’application et supprimez les autorisations inutilisées. Microsoft recommande aussi de désactiver SMTP AUTH pour l’organisation Exchange Online et de ne l’activer que pour les boîtes aux lettres qui en ont encore besoin. Il existe à la fois un paramètre à l’échelle de l’organisation et une dérogation par boîte aux lettres, et le paramètre de la boîte aux lettres peut prévaloir. Les paramètres de sécurité par défaut (Security defaults) désactivent SMTP AUTH. Ne désactivez pas une base de sécurité à l’échelle du tenant uniquement pour conserver un ancien appareil. Préférez un connecteur, un client moderne pris en charge, un relais sur site ou un autre service documenté lorsque la charge ne peut pas satisfaire les exigences OAuth et TLS.

Les limites de la soumission client influencent la conception de l’application

Le comparatif actuel de Microsoft documente pour la soumission SMTP client une limitation de 10 000 destinataires par jour et de 30 messages par minute. Considérez-les comme des limites de service actuelles, susceptibles de changer et d’interagir avec d’autres limites d’Exchange Online. Comptez les destinataires, et pas seulement les messages, en incluant To, Cc, Bcc, les nouvelles tentatives et la diffusion multiple. Placez les contrôles de débit applicatif, d’équité entre tenants, de concurrence, de tentatives et d’ancienneté dans la file sous le plafond du service. Une route par boîte aux lettres partagée peut créer une contention entre usage humain et usage automatisé, tandis qu’un identifiant utilisé par de nombreuses applications masque la responsabilité. Surveillez la marge de débit et de destinataires, mais ne contournez jamais une limite en faisant tourner les boîtes aux lettres ou les domaines d’expéditeur. Si la charge approche régulièrement des limites de soumission par boîte aux lettres, évaluez le relais par connecteur, High Volume Email pour le trafic interne éligible, Azure Communication Services Email pour la livraison applicative, ou un autre transport dédié, en vous appuyant sur les recommandations actuelles de Microsoft.

Paramètres du relais SMTP par connecteur

Le relais SMTP de Microsoft 365 utilise l’endpoint MX du tenant plutôt que smtp.office365.com, ainsi qu’un connecteur entrant qui identifie le système d’envoi de l’organisation. Microsoft recommande d’authentifier le connecteur avec un certificat TLS, une adresse IP publique statique étant l’autre méthode d’identification documentée. L’application se connecte sur le port TCP 25 et peut envoyer depuis des adresses d’un domaine accepté sans nécessiter de boîte aux lettres sous licence pour chaque expéditeur. Ce schéma convient aux serveurs de messagerie, appliances ou passerelles maîtrisés, dont le certificat et le réseau ont un propriétaire stable. Il exige davantage d’administration : portée du connecteur, cycle de vie des certificats, changements d’IP publique, DNS inverse, politique des domaines acceptés, prévention des abus et surveillance des blocklists. Ne créez jamais de relais ouvert. Limitez les systèmes internes, tenants, expéditeurs, destinataires et catégories de messages que la passerelle accepte. Un connecteur reconnaît la connexion comme appartenant à l’organisation ; il ne vérifie pas que des entrées applicatives arbitraires sont légitimes.

Direct Send permet la livraison à des destinataires internes, pas le relais général

Direct Send soumet à l’endpoint MX du tenant en tant que serveur SMTP externe, sans s’authentifier en tant que boîte aux lettres ni en tant que connecteur. Microsoft le documente pour la livraison à des destinataires de l’organisation Microsoft 365 ou Office 365, et non comme une route vers des adresses externes arbitraires. L’appareil ou l’application a besoin d’un accès au port TCP 25 et doit utiliser un expéditeur d’un domaine accepté. Comme cette route est anonyme du point de vue du service exposé sur Internet, la réputation de l’expéditeur, le DNS, l’IP source et les décisions anti-usurpation sont déterminants. N’exposez pas une passerelle Direct Send à des réseaux non fiables et ne l’utilisez pas pour contourner l’authentification par boîte aux lettres. Modélisez les rapports de non-remise et la responsabilité du support, car une imprimante ou une application peut ne pas recevoir les messages de bounce de manière sûre. Si la livraison externe est nécessaire, choisissez la soumission client, le relais par connecteur, Azure Communication Services Email ou une autre méthode prise en charge, après avoir évalué l’identité et le volume.

Séparez identité d’enveloppe, From visible et authentification

Chaque route transporte un expéditeur d’enveloppe SMTP et des commandes de destinataires, ainsi que des en-têtes visibles définis par la RFC 5322. L’expéditeur d’enveloppe détermine les bounces de transport et souvent l’identité SPF ; le From visible détermine ce que voient les lecteurs et constitue l’identité centrale de DMARC. L’authentification OAuth d’une boîte aux lettres, l’identité d’un connecteur ou l’acceptation d’une IP source ne créent pas automatiquement l’alignement SPF, DKIM ou DMARC pour chaque domaine From personnalisé. Inventoriez les valeurs exactes de MAIL FROM, From, Reply-To, le domaine d= et le sélecteur DKIM, ainsi que l’IP de connexion, sur des échantillons reçus contrôlés. Publiez une seule politique SPF valide pour le domaine concerné, configurez la signature DKIM lorsqu’elle est prise en charge et évaluez l’alignement DMARC. N’ajoutez pas un second enregistrement SPF et n’assouplissez pas la politique DMARC de l’organisation pour réparer un seul appareil. Dans vos modèles de statut, séparez l’acceptation par Microsoft, l’acceptation par le serveur de destination, un bounce ultérieur, le filtrage de la boîte aux lettres, le placement en boîte de réception et l’action humaine.

Mettez en place une frontière applicative durable

Placez le SMTP de Microsoft 365 derrière un worker serveur autorisé ou un relais maîtrisé. Persistez un événement métier avant de vous connecter, avec une clé d’idempotence stable, le tenant, la catégorie de message, la révision du modèle, l’expéditeur et les destinataires approuvés, la base de consentement ou de nécessité, l’état de suppression et l’historique des tentatives. Appliquez les règles d’expéditeur et de destinataires propres à chaque tenant avant de générer les commandes SMTP. Bornez la taille des messages, la diffusion multiple, les pièces jointes et les valeurs d’en-têtes. Stockez les jetons, les mots de passe, les clés privées des certificats et l’administration des connecteurs en dehors du code source, des logs, des outils d’analyse, des tickets et des prompts. Définissez des timeouts finis et classez les réponses 4xx comme candidates à une nouvelle tentative bornée et les réponses 5xx comme permanentes pour cette tentative, en vous appuyant sur le diagnostic étendu complet et les recommandations de Microsoft. Une déconnexion après DATA mais avant la réponse finale est ambiguë ; conservez la tentative et rapprochez-la avant tout renvoi. SMTP n’offre aucune garantie exactly-once au niveau du produit.

Testez la configuration et les modes de défaillance avant le déploiement

Utilisez des destinataires contrôlés dédiés et un réseau source configuré comme en production. Vérifiez la résolution DNS, l’accessibilité du port, la négociation STARTTLS, le nom d’hôte et la chaîne du certificat, l’obtention et le scope du jeton OAuth, les paramètres SMTP AUTH de l’organisation et de la boîte aux lettres, l’autorisation Send As, la correspondance du connecteur, les domaines acceptés et le choix de l’endpoint MX. Envoyez des échantillons en texte brut, en HTML, avec pièce jointe, en Unicode, en bounce et au volume attendu. Consignez les en-têtes bruts, les Authentication-Results de confiance, les réponses SMTP, les identifiants de trace et les preuves de suivi des messages (message trace), sans conserver le contenu des clients. Les tests négatifs doivent couvrir les jetons révoqués, les certificats de connecteur expirés, une IP publique modifiée, SMTP AUTH désactivé sur la boîte aux lettres, les Security defaults, un From invalide, un destinataire externe via Direct Send, les limites par minute et par destinataire, un report temporaire, un rejet permanent et une perte de connexion autour de DATA. Répétez la mise en pause de la charge et le déplacement des tâches durables sans contourner les échecs permanents liés à une politique ou à un destinataire.

Utilisez les instructions Microsoft actuelles et testez votre tenant

La configuration SMTP Microsoft 365 dépend des politiques, identités, connecteurs et de l’environnement réseau du tenant. Utilisez la documentation Microsoft Learn actuelle et testez la voie sélectionnée dans votre tenant avant de vous y fier pour les e-mails de production.

Questions fréquentes

Quel est le nom d’hôte SMTP client de Microsoft 365 ?

Microsoft documente actuellement smtp.office365.com pour la soumission client authentifiée et indique d’utiliser le nom DNS plutôt qu’une adresse IP de service fixe.

Quel port utiliser pour la soumission SMTP client ?

Microsoft recommande le port TCP 587 et documente le port 25 pour le scénario de soumission client pris en charge, avec STARTTLS et TLS 1.2 ou TLS 1.3 obligatoires.

La soumission client de Microsoft 365 prend-elle en charge OAuth ?

Oui. Microsoft recommande OAuth et documente le scope SMTP.Send ainsi que SASL XOAUTH2. L’inscription dans le tenant, les permissions, la garde des jetons et le rattachement à la boîte aux lettres exigent tout de même une configuration soignée.

Quelle est la différence entre le relais SMTP et Direct Send ?

Le relais par connecteur authentifie un système de messagerie de l’organisation et peut prendre en charge des destinataires externes. Direct Send utilise l’endpoint MX du tenant sans ce connecteur et est destiné aux destinataires internes.

Faut-il activer SMTP AUTH pour chaque boîte aux lettres ?

Non. Microsoft recommande de le désactiver à l’échelle de l’organisation et de ne l’activer que pour les boîtes aux lettres qui en ont encore besoin, en privilégiant l’authentification moderne et les alternatives prises en charge.

L’acceptation SMTP par Office 365 signifie-t-elle une livraison en boîte de réception ?

Non. L’acceptation est un résultat de transport de portée limitée. La livraison ultérieure, la non-remise, le filtrage par le destinataire, le placement dans un dossier de la boîte aux lettres et l’engagement humain restent des preuves distinctes.

Une application peut-elle utiliser le port 465 pour la soumission client Microsoft ?

Le guide actuel de Microsoft indique qu’un appareil utilisant par défaut le port 465 ne prend pas en charge les versions de TLS requises pour la soumission client sur cette route Microsoft 365.

Où dois-je vérifier une configuration SMTP Microsoft 365 ?

Utilisez la documentation Microsoft Learn actuelle et testez la voie sélectionnée dans votre tenant avant de vous y fier pour les e-mails de production.

Sources

Continuer à apprendre

Comment évaluer un service de relais SMTPÉvaluez les services de relais SMTP selon la sécurité de la soumission, l’authentification, les files d’attente, le comportement des nouvelles tentatives, les limites, les événements de livraison, la suppression, l’isolation et l’adéquation à une migration.Guide d’évaluation du service de relais SMTP de GoogleÉvaluez le relais SMTP de Google Workspace selon le modèle d’autorisation, TLS, l’identité de l’expéditeur, les quotas, la gestion des erreurs, l’authentification, l’observabilité et le risque de migration.Protocole SMTP : comment circulent les e-mails applicatifsDécouvrez comment la soumission SMTP, le relais, les enveloppes, les codes de réponse, TLS, les nouvelles tentatives et le contenu des messages façonnent un workflow d’e-mail applicatif.Ports SMTP 25, 465 et 587 : guide pratiqueChoisissez le bon port SMTP selon le rôle et le mode TLS, puis diagnostiquez les échecs de connexion, de négociation, d’authentification et d’acceptation des messages.Comment évaluer un service de délivrabilité e-mailÉvaluez les services de délivrabilité e-mail selon leur périmètre, leurs preuves, l’authentification, les boucles de rétroaction, les suppressions, la confidentialité, la portabilité et l’adéquation opérationnelle.