Classer l'itinéraire avant de décider ce qui a échoué
Un destinataire peut voir le courrier directement depuis un service d'origine, après un saut de transfert ou après qu'une liste de diffusion l'a modifié. Une adresse IP source et un échec d’authentification ne distinguent pas, en eux-mêmes, ces chemins de l’usurpation d’identité. L'enquêteur doit relier le résultat rapporté à un itinéraire particulier et préserver l'incertitude là où l'itinéraire est manquant. Dans le cas contraire, une réparation destinée à un expéditeur légitime peut autoriser une infrastructure sans rapport.
Ce guide utilise RFC 9989 et RFC 9990 à partir de mai 2026, SPF RFC 7208 et la version expérimentale ARC spécification RFC 8617 . Les directives du fournisseur ont été révisées le 8 novembre 2026. Tous les exemples d'itinéraires sont des cas papier fictifs. Aucun message n'a été envoyé, importé ou vérifié, aucune requête DNS n'a été exécutée et aucun paramètre de transfert ou de confiance du destinataire n'a été modifié.
Définir l'envoi direct par rapport à la limite de réception
Pour cette enquête, l'envoi direct signifie que le service sortant prévu livre jusqu'à la frontière de réception sans l'intervention d'un service de réexpédition sur l'itinéraire examiné. Cela ne signifie pas que l’organisation d’origine utilise un seul serveur interne. Les relais internes et les passerelles sortantes peuvent précéder la connexion observée, enregistrez donc la limite utilisée lors de l'application de l'étiquette.
RFC 7208 évalue un hôte de connexion par rapport à une identité SMTP définie. En route directe, un échec peut indiquer un problème de configuration, un chemin inattendu ou une utilisation non autorisée. Il ne suffit pas de nommer la cause à partir du seul résultat. Préserver le domaine évalué, le contexte de connexion et l'état d'erreur avant de proposer toute modification de son autorisation.
Expliquez pourquoi le transfert peut modifier la preuve SPF
Lorsqu'un transitaire transmet un message original, le destinataire suivant voit l'adresse de connexion du transitaire. Si l'identité de l'enveloppe d'origine est conservée, cette adresse peut ne pas être autorisée par la politique SPF du domaine d'origine. Si l'enveloppe est réécrite, SPF peut authentifier l'identité du transitaire. Aucune des deux circonstances ne fournit automatiquement un chemin SPF aligné pour le domaine From original visible sous RFC 9989.
C'est pourquoi l'ajout de chaque redirecteur observé au SPF du domaine d'origine n'est pas une bonne réponse par défaut. Il peut élargir l'autorisation sans aborder l'itinéraire réel ou l'autre chemin d'authentification. Déterminez d’abord si le transfert a eu lieu, si le destinataire s’y attendait et quelles identités ont changé. Un modèle de type transfert est une hypothèse jusqu'à ce que des preuves d'itinéraire représentatives le soutiennent.
Vérifiez si la signature DKIM originale a survécu
Un message peut conserver un alignement valide Signature DKIM par transmission si le matériel signé reste compatible avec la vérification. RFC 6376 définit ce que couvre la signature et comment elle est vérifiée. Les modifications apportées aux en-têtes signés ou au contenu du corps peuvent briser cette signature ; le simple fait de déplacer le message via un autre serveur ne le fait pas nécessairement. Ne généralisez pas un produit de transfert à tous les itinéraires.
Une liste de diffusion peut modifier le contenu, ajouter un pied de page ou autrement transformer le message avant sa redistribution. Une nouvelle signature valide de la liste peut authentifier le domaine de la liste tout en restant non alignée avec le domaine From d'origine. Un rapport DKIM le pass a donc besoin de son identité de signature et alignement contexte. Cela ne peut pas être lu comme une preuve que le domaine de l'auteur original est passé DMARC.
Utilisez ARC comme preuve dont la confiance nécessite encore une décision
RFC 8617 est un protocole expérimental permettant de réaliser des évaluations d'authentification à travers les étapes de traitement des messages. La validation de la chaîne ARC et la confiance dans les parties au scellement sont des questions distinctes. Une chaîne cryptographiquement valide ne garantit pas la sécurité du message ni n’établit que chaque scelleur est digne de confiance. Une chaîne manquante ou cassée ne prouve pas non plus que le message a été faux.
Les destinataires peuvent utiliser les informations ARC dans les décisions de disposition locales. Ne réécrivez pas cela en une règle universelle selon laquelle ARC transforme un échec d'alignement SPF ou DKIM sous-jacent en une réussite de protocole. Conservez séparément les résultats d’authentification observés et tout remplacement de stratégie signalé. RFC 9990 distingue les champs évalués par DMARC des résultats d'authentification bruts et fournit un contexte pour les rapports de remplacement de stratégie. L'acceptation du récepteur et le résultat de l'authentification restent des faits différents.
Comparez quatre chemins fictifs sans surclasser
L'exercice sur papier retenu oppose quatre possibilités : un service direct prévu ; un transitaire inchangé préservant DKIM aligné ; une liste modificatrice dont la signature originale ne vérifie plus ; et un expéditeur se faisant passer pour le domaine From sans itinéraire autorisé connu. Il s’agit d’alternatives explicatives et non de quatre messages testés. Aucun véritable hôte, compte ou propriétaire d’entreprise ne leur a été attribué.
Les trois premières possibilités nécessitent une configuration et une preuve de message spécifiques à un itinéraire avant de pouvoir être traitées comme un trafic observé légitime. Le quatrième reste suspect usurpation d'identité jusqu'à ce que les preuves disponibles et l'examen de sécurité soutiennent cette classification. L’échec de l’authentification ne peut à lui seul distinguer le cas de la liste de modification de l’usurpation d’identité. À l’inverse, l’authentification réussie ne peut pas établir un contenu inoffensif ou un objectif commercial actuellement approuvé.
Respecter la configuration de confiance réelle du destinataire
de Microsoft conseils fiables pour les scellants ARC est un exemple spécifique au fournisseur : il décrit la sélection des intermédiaires légitimes et requis pour le comportement de réception Microsoft 365 . Il n'établit pas de liste verte universelle, de politique d'un autre fournisseur ou de configuration d'un locataire client. Ce projet n'ajoute pas de scellant et ne recommande pas de faire confiance à un intermédiaire simplement parce que son nom est familier.
Pour une enquête future, conservez le message représentatif, la trace de réception approuvée, la configuration du service pertinente et l'itinéraire attendu du destinataire. Authentication-Results les champs doivent être interprétés dans une limite de confiance de réception établie, comme RFC 8601 explique. Un en-tête copié non fiable peut affirmer n'importe quoi. Conservez la divulgation des messages, les modifications de sécurité du récepteur et les actions DNS de production soumises à leurs propres approbations humaines.
Exiger un itinéraire observé avant de qualifier le remède de prouvé
La porte d'entrée exacte reste ouverte : validez les spécifications principales actuelles et conservez un exemple concret avant de rédiger. Les sources primaires et les comparaisons fictives ont été conservées, mais les preuves originales commandées sont toujours absentes : une carte d'itinéraire vers les exigences avec les preuves actuelles du fournisseur et un message de test contrôlé.
Un éventuel test contrôlé doit utiliser un destinataire et un itinéraire approuvés, conserver les diagnostics pertinents et distinguer la livraison, l'authentification et la gestion de la politique locale. Il devrait répondre à l’incertitude spécifique plutôt que promettre une compatibilité de transmission universelle. Jusqu'à ce que ces preuves existent, conservez la classification du candidat et la prochaine étape de l'enquête. Ne revendiquez pas une correction réussie, une usurpation d'identité confirmée ou un expéditeur approuvé à partir des seuls exemples documentaires.