Lire le refus de relais comme une question d'autorisation
Une réponse de refus de relais signifie que le service récepteur n'a pas autorisé la tentative d'opération dans les conditions observées. Il n'identifie pas, en soi, un mauvais mot de passe, un SPF défaut ou une boîte aux lettres manquante. Avant de modifier quoi que ce soit, déterminez quel service a rejeté quelle étape SMTP pour quel destinataire. Le point de terminaison et la réponse exacts sont plus utiles que la notification abrégée « échec du courrier » d'une application.
Conservez la réponse SMTP de base complète, le code d'état amélioré le cas échéant, le texte de diagnostic, l'hôte répondant, l'horodatage et l'étape de commande. Enregistrez si le rejet s'est produit lors de l'authentification, COURRIER DE, RCPT TO ou après les données du message. Conservez les identifiants de demande du fournisseur qui peuvent prendre en charge une enquête autorisée, mais supprimez les secrets et le contenu des messages inutiles des tickets partagés.
Séparer la classe de nouvelle tentative du diagnostic
Le premier chiffre de réponse SMTP fournit une sémantique d'action large. Une réponse 4xx est un achèvement négatif transitoire ; une réponse 5xx est un achèvement négatif permanent pour la tentative de demande. Aucune des deux classes n'identifie l'autorisation rejetée. Les codes améliorés ajoutent de la classe, du sujet et des détails, mais leur signification nécessite toujours le contexte complet du diagnostic et du fournisseur. RFC 5321 , section 4.2.1 et RFC 3463 , section 2.
Ne soumettez pas à plusieurs reprises une transaction inchangée et définitivement rejetée. Une réponse passagère ne justifie pas non plus des tentatives répétées immédiates ; utilisez la stratégie de nouvelle tentative limitée du système de messagerie responsable lors de l'enquête. Une condition 4xx peut concerner le routage, les ressources ou un autre problème temporaire plutôt que l'authentification. Garder le cap et la réponse complète évite de transformer chaque échec en demande de réinitialisation de mot de passe.
Faire correspondre le point de terminaison à son rôle prévu
Une candidature utilisant un service de soumission de boîte aux lettres doit répondre aux exigences de soumission de ce service. Un relais basé sur un connecteur doit correspondre aux conditions de connecteur autorisées par l'organisation. Une route entrante directe peut accepter des destinataires locaux sans accorder l’autorisation de les relayer ailleurs. Le guide de messagerie d'application actuel de Microsoft distingue ces itinéraires ; son option Direct Send ne permet pas la livraison à des destinataires externes via le locataire. Configuration de la messagerie de l'application Microsoft.
Construisez un court enregistrement d'itinéraire avant de modifier un paramètre : hôte configuré, hôte répondant réel, port, réseau source, mode d'authentification, identités de l'expéditeur et catégorie du destinataire. Comparez-le avec la conception prévue. N'essayez pas de serveurs SMTP publics arbitraires pour voir lequel accepte le message. Un serveur accessible n’est pas un relais autorisé, et une acceptation réussie ne légitimerait pas son utilisation.
Utiliser les diagnostics du fournisseur de manière étroite
La page de dépannage de Microsoft identifie le code amélioré 5.7.64 avec TenantAttribution et Relay Access Denied, et traite également du code 4.4.62 pour le courrier envoyé à la mauvaise région. Dans ce contexte documenté, une adresse IP publique ou un certificat modifié peut empêcher l’attribution du locataire. La même page associe 5.7.60 à l’autorisation Envoyer en tant que. Ces exemples aident à sélectionner une branche d'enquête ; cela ne signifie pas que chaque réponse 5.7.x a la même cause. Dépannage des appareils et des applications Microsoft.
Cette page de dépannage est datée de juin 2025 et contient des solutions de contournement d'authentification plus anciennes. Ne suivez pas les suggestions pour désactiver MFA ou les paramètres de sécurité par défaut en tant que réparation générale. Conciliez la configuration avec les instructions de configuration les plus récentes et la politique de sécurité de l'organisation. Ce projet ne prescrit pas de date de retrait de l'authentification de base, ne suppose pas qu'une fonctionnalité est activée ou ne prétend pas qu'un locataire actuel accepte une méthode héritée.
Retracez l'autorité rejetée avec un incident fictif
Imaginez une application fictive dont les notifications externes s'arrêtent après un basculement du réseau. Sa conception prévue utilise un connecteur basé sur IP. Le paquet d’enquête contient un diagnostic d’attribution de relais, mais aucune nouvelle observation de source publique. Une étape suivante utile consiste à demander au propriétaire du réseau et à l'administrateur de messagerie de comparer l'identité de sortie réelle avec le connecteur autorisé, à l'aide de preuves approuvées en lecture seule. L'exemple n'établit pas que toute modification d'adresse ou que la modification d'un connecteur est autorisée.
Changeons maintenant les faits fictifs : les destinataires internes fonctionnent, l'application n'a jamais eu de connecteur et seuls les destinataires externes échouent. Cela pointe vers une question de portée d’itinéraire plutôt que vers le même diagnostic de changement de réseau. Un troisième cas pourrait avoir une authentification de soumission réussie mais une erreur d'autorisation de l'expéditeur pour une identité d'expéditeur différente. Les branches de diagnostic doivent rester séparées afin qu'une solution pratique dans un cas n'étende pas les autorisations dans un autre.
Séparez l’autorisation et la délivrabilité
La publication SPF décrit l'infrastructure d'envoi autorisée pour une identité SPF ; il ne demande pas à un service SMTP arbitraire de relayer. De la même manière, DKIM signer et DMARC alignement n’accordez pas l’autorisation Envoyer en tant que à la boîte aux lettres. Corriger le mauvais calque peut laisser le rejet d'origine inchangé tout en créant une nouvelle exposition. Utilisez la carte d'itinéraire vers l'exigence pour identifier le propriétaire de l'autorisation rejetée avant de proposer une correction de portée restreinte. RFC 7208 , sections 2.4 et 4.1.
La correction peut impliquer un point de terminaison approuvé, une identité d’expéditeur autorisé ou une correspondance de connecteur examinée par l’administrateur. Il ne faut jamais « autoriser tout le monde », publier des informations d’identification, désactiver une politique de protection sans examen ou renvoyer via un relais public non lié. Enregistrez l’ancien état, l’autorisation prévue et la portée du destinataire attendu avant toute modification autorisée.
Retester une transaction limitée
Utilisez un destinataire de test approuvé et un message non sensible reconnaissable une fois que le changement concerné a été autorisé. Conservez les réponses complètes et la disposition en aval. Si le serveur donne une réponse positive après les données du message, il accepte la responsabilité du transport ; c'est différent de la preuve de livraison dans la boîte de réception. Si la connexion se ferme avant une réponse finale concluante, établissez le résultat avant de générer un autre message d'application, car la livraison peut être incertaine. RFC 5321 , sections 4.2.5 et 6.1.
Une carte d'itinéraire vers les exigences avec les preuves du fournisseur actuel et un message de test contrôlé. Cette exigence exacte du catalogue reste ouverte. Aucune autorisation, connecteur ou identifiant n'a été inspecté ou modifié, et aucune sonde de relais ou message de test n'a été envoyé. Les branches de diagnostic sont des contrôles proposés et non un résultat spécifique au compte.