Inventoriez le chemin réel plutôt que l'étiquette de l'application
« Utilise SMTP » n'indique pas à une équipe de messagerie comment une application est autorisée à envoyer. Une application peut être soumise via une boîte aux lettres, relayée via le connecteur d'une organisation ou livrée directement à un système destinataire. Ces itinéraires ont des identités, des autorisations et des limites de destinataires différentes. Un inventaire qui enregistre uniquement le nom du fournisseur et l'adresse de l'expéditeur peut manquer la condition qui fait fonctionner l'itinéraire.
Créez une entrée pour chaque chemin d’application sensiblement différent. Capturez le point de terminaison configuré, le port, les exigences de transport, la méthode d'authentification, expéditeur d'enveloppe, visible De l'adresse, des destinataires attendus et du propriétaire de la file d'attente. Incluez l'emplacement d'hébergement et l'adresse IP de la source publique observée par le service de réception, le cas échéant. L'adresse privée de la machine ne constitue pas une preuve de l'adresse qu'un connecteur cloud voit après la traduction réseau.
Distinguer les rôles SMTP des noms de produits des fournisseurs
Le relais SMTP est un rôle de transport général, tandis que les options documentées spécifiques aux étiquettes « Relais SMTP » et « Envoi direct » de Microsoft. Dans le guide de configuration de l'application Microsoft 365 révisé le 8 novembre 2026, la soumission du client utilise l'authentification de la boîte aux lettres, le relais utilise un connecteur entrant et l'envoi direct atteint les destinataires au sein de l'organisation cloud plutôt que de fournir un relais externe. Ces étiquettes ne doivent pas être transférées sans réserve à un autre fournisseur. Configuration de la messagerie de l'application Microsoft.
Au niveau du protocole, le client présente une transaction SMTP et reçoit des réponses pour les étapes individuelles. Une connexion réussie n'établit pas l'autorisation de relayer vers chaque destination. Enregistrez le rôle de réception destiné au point de terminaison choisi avant de dépanner un destinataire rejeté. Un MX public est une destination entrante et non une invitation à utiliser son propriétaire comme service sortant sans restriction. RFC 5321 , sections 2.3 et 3.3.
Placer les exigences d'itinéraire à côté de l'inventaire
Pour les choix Microsoft documentés, enregistrez smtp.office365.com pour la soumission du client par rapport au point de terminaison MX du locataire pour le relais ou l'envoi direct. L'éligibilité du relais dépend du certificat configuré ou du connecteur IP public éligible ; l'authentification de la boîte aux lettres appartient à la route de soumission. Préservez les contraintes du guide actuel sur l'hébergement, les domaines d'expéditeur, le transport et la portée des destinataires plutôt que de copier une recette de configuration générique. La page de configuration de Microsoft a été mise à jour le 16 septembre 2026 ; l’applicabilité du locataire doit encore être confirmée. Configuration de la messagerie de l'application Microsoft.
La cartographie du parcours vers les besoins est un cadre d'inventaire documentaire. Son objectif est de révéler les preuves manquantes et non de sélectionner automatiquement un itinéraire. Si une application a besoin de destinataires externes, un chemin réservé aux locataires constitue une inadéquation fonctionnelle même lorsque les tests internes réussissent. Si l'itinéraire dépend d'un connecteur, un nom d'hôte enregistré sans correspondance de connecteur vérifiée constitue une preuve incomplète. Si les paramètres d'authentification sont intentionnellement restreints, choisissez une conception prise en charge autorisée au lieu de désactiver les contrôles de sécurité pour faire fonctionner une ancienne recette.
Gardez l'autorisation de l'expéditeur distincte des résultats d'authentification
L'autorisation d'un service d'envoyer du courrier est distincte de l'autorisation du message. SPF, DKIM et DMARC résultats au niveau d’un récepteur en aval. Une authentification réussie de la boîte aux lettres ne prouve pas que l'adresse d'expéditeur visible est autorisée pour cette boîte aux lettres. Un connecteur correspondant à la source ne prouve pas que chaque message résultant a une authentification alignée. A l’inverse, changer de public Enregistrement SPF n'accorde pas l'autorisation de relais du service SMTP .
Enregistrez l'autorisation administrative et les preuves d'identité en aval dans des champs d'inventaire distincts. DMARC évalue le domaine d'auteur par rapport aux identifiants authentifiés ; il ne s'agit pas d'un registre indiquant quelles candidatures détiennent les informations d'identification de soumission. Le résultat d'un destinataire final doit être lié au message exact et au lieu d'évaluation. RFC 9989 , section 4.4. Les identifiants et les jetons ne doivent jamais apparaître dans l'inventaire ou dans un ticket de diagnostic ; enregistrez plutôt une référence approuvée à leur propriétaire et à leur processus de gestion.
Utilisez une application fictive pour exposer la dépendance cachée
Supposons qu'un scanner d'entrepôt fictif envoie des avis d'expédition aux employés via un point de terminaison MX locataire. Son inventaire indique « relais SMTP », mais aucune preuve de connecteur n'est jointe. Plus tard, une équipe ajoute une adresse de messagerie externe et la livraison échoue. L'échec n'établit pas que le domaine du coursier ou le SPF du scanner est défectueux. La première question est de savoir si la route a déjà été autorisée pour un relais externe ou si le courrier interne réussi utilisait un chemin de service différent.
Un deuxième changement fictif déplace le trafic du scanner via une nouvelle passerelle réseau. Les paramètres de l'application restent identiques, mais la source publique vue par le service change. Si l’itinéraire approuvé dépend de cette identité source, l’écran de candidature inchangé est trompeur. Avant toute modification de configuration, comparez les preuves du connecteur autorisé et le chemin réseau réel avec l'enregistrement de travail précédent. Aucun des deux scénarios n’est un test en direct ou un diagnostic de compte.
Planifier un test d'acceptation contrôlé
Choisissez un destinataire autorisé pour chaque catégorie de destinataire requise, un message inoffensif identifié de manière unique et une fenêtre horaire avec un opérateur responsable. Enregistrez les réponses et étapes SMTP complètes, l'identifiant de file d'attente, l'itinéraire et les résultats finaux d'authentification approuvés, le cas échéant. Une réponse d’acceptation de soumission prouve un transfert et non un placement final dans la boîte de réception. Le serveur en aval assume la responsabilité du transport après une réponse d'achèvement positive suite aux données du message. RFC 5321 , section 4.2.5.
Incluez les attentes négatives sans sonder les destinataires non liés ou les relais publics. Lorsqu’un itinéraire est délibérément réservé uniquement à l’intérieur, l’exigence est de documenter cette restriction, et non de trouver un moyen de la contourner. Gardez la propriété des nouvelles tentatives explicite afin que l'application ne crée pas de deuxième message alors que son service de messagerie a déjà le premier en file d'attente.
Gardez l'inventaire versionné
Vérifiez l'entrée après la migration du réseau, le renouvellement du certificat, la modification de la stratégie d'authentification ou l'expansion de la portée du destinataire. La documentation du fournisseur est une preuve datée, tandis que la configuration réelle du client est une preuve distincte. Une recette d'authentification obsolète ne doit pas être sauvée en partageant des mots de passe ou en affaiblissant les protections.
Une carte d'itinéraire vers les exigences avec les preuves du fournisseur actuel et un message de test contrôlé. Cette exigence exacte reste ouverte. Aucun paramètre de locataire, connecteur, identifiant, itinéraire réseau ou message contrôlé n'a été inspecté ou modifié. La carte fournie et les exemples préparent l'enquête ; ils ne certifient pas qu'une application est correctement configurée.