Modélisez une chaîne de règles plutôt qu’une paire de fournisseurs
Un problème de transfert entre fournisseurs mixtes est souvent décrit comme « le courrier fonctionne dans un système mais pas dans l’autre ». Cette description cache l'itinéraire. La même adresse peut recevoir du courrier via un alias, une règle de boîte aux lettres, une passerelle de sécurité et une autre règle de transfert avant que la boîte aux lettres finale ne le voie. Chaque étape peut introduire une identité d’enveloppe, une transformation de message ou une décision locale différente.
Créez un inventaire d'itinéraires versionné avant de comparer les résultats d'authentification. Nommer l'expéditeur initial, chaque intermédiaire et le destinataire final ; distinguer la redirection automatique d'une personne composant un nouveau transfert. Enregistrez à qui appartient chaque règle et quelles preuves peuvent être obtenues. Les noms de fournisseurs sont des étiquettes utiles, mais le type de règle réel, la configuration du compte et la séquence de traitement déterminent le comportement qui doit être vérifié.
Établir un contrat de comparaison pour chaque saut
Pour chaque transfert, proposez les mêmes champs de preuves : heure d'observation, source de connexion, expéditeur d'enveloppe le cas échéant, domaine de l'auteur, signatures présentes, modifications du contenu couvertes et résultats du système de réception. Incluez un identifiant de route afin qu'un échantillon direct ne soit pas confondu avec une branche différente du chemin indirect. Préservez à la fois la configuration prévue et le comportement observé, car ils peuvent être en désaccord.
Une exportation de fournisseur ou une capture d'écran du panneau de commande décrit la configuration, pas nécessairement la transaction qui a produit un message reçu. Si un service ne peut pas exposer l'enveloppe intermédiaire, marquez ce champ comme inconnu et conservez l'observation du récepteur final. Ne comblez pas les lacunes en supposant que toutes les règles appelées transfert utilisent la même méthode SMTP .
Utilisez un petit ensemble de comparaison autorisé avec des formats représentatifs et des destinataires connus. Modifiez une seule variable planifiée à la fois lorsque cela est possible. Le texte brut, le courrier en plusieurs parties et les messages avec pièces jointes peuvent suivre différents chemins de traitement. Le but est d’isoler une dépendance, et non de fabriquer un pourcentage global de délivrabilité à partir d’une poignée d’exemples.
Évaluez à nouveau les identités après chaque limite de transfert
Le serveur de connexion final peut différer du serveur de l'expéditeur d'origine. RFC 7208 section 10.3 explique pourquoi c'est important pour SPF. Un intermédiaire peut conserver l'enveloppe ou la remplacer ; ce comportement a besoin de preuves. Une réécriture ultérieure peut remplacer un domaine de réécriture antérieur, donc la version finale Return-Path à lui seul, il ne constitue pas une histoire complète de toutes les identités antérieures.
Sous RFC 9989 section 4.4, l'identifiant de passage doit également s'aligner sur le domaine de l'auteur pour les DMARC succès. Mettre l'adresse d'origine dans une partie locale réécrite ne crée pas cette relation de domaine. La signature de chaque intermédiaire n’aide pas non plus nécessairement alignement: chaque domaine signataire doit être évalué pour sa relation avec l'auteur.
Traiter l'original survivant DKIM comme un chemin séparé. Selon RFC 6376 sections 3.4 et 5.4, la vérification dépend des champs signés et du contenu canonique couvert. Un fournisseur peut ajouter un en-tête de trace non signé sans nécessairement invalider une signature, alors qu'un sujet signé modifié ou un corps couvert peut avoir de l'importance. Comparez le matériel réel au lieu de blâmer le dernier fournisseur de la chaîne.
Conserver les conseils du fournisseur localement par rapport au produit documenté
Google recommandations de transmission et celui de Microsoft Description du SRS aborder les problèmes connexes sous différents angles de produit. La documentation de Microsoft inclut des exceptions dépendantes de l'itinéraire. Lisez chacun par rapport au produit exact et à la direction du flux, puis vérifiez l'enveloppe résultante plutôt que de la prédire à partir du logo du fournisseur.
La même prudence s’applique aux évaluations des récepteurs. de Microsoft explication de l'authentification composite décrit un résultat supplémentaire distinct des résultats du protocole ordinaire. Ne créez pas de colonne de passage universel qui traite cette valeur, un ARC résultat de la chaîne et DMARC comme équivalent. Conservez les étiquettes originales et documentez leur signification là où elles ont été produites.
ARC peut réaliser des évaluations antérieures, mais RFC 8617 laisse la confiance et la gestion à la politique du destinataire. À cette date de révision, il reste expérimental ; le Proposition de reclassement d'octobre 2026 est un projet actif, pas un remplacement adopté. La planification inter-fournisseurs ne doit pas dépendre d’une promesse non vérifiée selon laquelle chaque destinataire fait confiance à chaque intermédiaire.
Exemple fictif avec deux échecs indépendants
Considérons un itinéraire fictif depuis example.com via une boîte aux lettres organisationnelle sur example.net , puis un service d'archives, puis une boîte aux lettres personnelle. La comparaison prévue comprend un contrôle direct et un échantillon de chaque étape observable. Dans le scénario inventé, le premier transfert préserve le message signé tandis que le service d'archives ajoute une étiquette de ticket à un champ Objet signé.
Supposons que l'enveloppe finale appartienne au service d'archives et que son évaluation SPF réussisse. Ce résultat ne correspond pas en soi à example.com . Le changement de sujet peut expliquer la perte du chemin DKIM aligné d'origine, mais l'examinateur aurait besoin de véritables éléments avant et après pour l'établir. La modification proposée appartient à la transformation de l'archive, et non automatiquement au DNS de la première boîte aux lettres.
Par ailleurs, l'inventaire révèle une ancienne règle qui pourrait renvoyer les réponses vers une adresse antérieure. Il s’agit d’un risque de routage à examiner en soi ; une passe d'authentification ne prouverait pas la prévention des boucles. Aucune boucle de message, changement d’en-tête ou verdict du fournisseur n’a été observé pour cet exemple.
Préserver la propriété opérationnelle lorsque les règles changent
Enregistrez la différence exacte entre les règles, le propriétaire du service, la destination prévue et les preuves nécessaires pour accepter le changement. Examinez les copies en double, les destinations obsolètes, les attentes en matière de confidentialité et les notifications d'échec ainsi que l'authentification. Une route qui authentifie mais expose les messages à une boîte aux lettres involontaire ne constitue pas une migration réussie.
Après exécution approuvée, répétez les comparaisons et préservez les inconnues résiduelles. Le catalogue nécessite des échantillons de livraison directe et indirecte avec comparaison de l'itinéraire, de l'enveloppe, des signatures et des résultats fiables. Cette porte reste ouverte. Cet article fournit un cadre de diagnostic original et un exercice d'itinéraire fictif, et non des tests de fournisseur en direct, des modifications de règles approuvées ou une preuve de comportement équivalent entre les services.