Un message transféré peut être légitime et échouer quand même DMARC. Le dernier serveur de réception évalue la connexion et le message qu'il reçoit réellement, et non l'intention de l'expéditeur ou le résultat d'une livraison antérieure. La question utile est de savoir quelle identité authentifiée s’aligne toujours sur le domaine From visible après le saut de transfert. Préservez cette distinction avant d’envisager une exception politique.
Reconstruire l'itinéraire
Références : RFC 8601 §1.2, RFC 8601 §5.
Collectez le message brut d'origine, le message brut transféré, les horodatages, la configuration de transfert et les résultats d'authentification générés par le destinataire. Conservez l'enveloppe SMTP séparément des en-têtes visibles : un message enregistré ne préserve pas nécessairement l'enveloppe utilisée à chaque saut. Obtenez des traces des systèmes responsables de ces sauts. Ne traitez pas un message inséré par l'expéditeur Authentication-Results champ comme observation de récepteur fiable. RFC 8601 explique cette limite.
Étiquetez l’expéditeur d’origine, l’intermédiaire et le destinataire final. Enregistrez ensuite l'adresse IP de connexion, le domaine de l'enveloppe, le domaine visible depuis et chaque DKIM domaine de signature à chaque point d’évaluation applicable. Un diagramme d'itinéraire n'est utile que s'il reflète les transferts observés. Un saut inconnu reste inconnu plutôt que de se voir attribuer un résultat d'authentification supposé.
Identifier le chemin survivant
Références : RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF évalue le système de connexion par rapport à une identité d'enveloppe. Chez le destinataire final, un serveur de transfert peut se trouver en dehors de l'autorisation du domaine d'enveloppe d'origine. Un préservé Signature DKIM peut toujours fournir une passe alignée car la vérification est liée au message signé et au domaine de signature. La réécriture de contenu peut supprimer ce chemin restant. DMARC a besoin d'un résultat authentifié aligné, pas simplement d'un pass SPF ou DKIM . RFC 9989, RFC 7208 et RFC 6376 définir ces contrôles distincts.
Une enveloppe réécrite par SRS peut transmettre SPF pour le domaine du transitaire sans s'aligner sur le domaine From de l'auteur d'origine. Une nouvelle signature de ce même transitaire présente la limitation analogue. Aucune de ces observations ne signifie que le message est nécessairement malveillant, et aucune ne répare automatiquement l'authentification alignée de l'auteur.
Exécutez l'exemple limité
Références : RFC 9989 §4.4, RFC 9989 §5.3.5.
Le modèle d'alignement strict retenu peut être inspecté séparément de la capture SMTP . Le cas direct fournit des passes SPF et DKIM alignées. Le cas de transfert préservé entraîne un échec SPF et un succès DKIM aligné, de sorte que le modèle d'alignement strict passe toujours. Le cas du pied de page fournit des échecs pour les deux chemins et des échecs. Le SRS les cas isolent comment une identité SPF réussie mais non alignée ne change rien à ce raisonnement.
Ces booléens sont des entrées délibérées, et non des résultats de requêtes DNS en direct ou de vérification de signature cryptographique. Les messages bruts générés sont synthétiques et n'ont jamais été reçus. Ils illustrent un changement corporel contrôlé mais ne satisfont pas à l’exigence de véritables messages originaux et transmis avec des résultats fiables. La section de laboratoire SMTP retenue ci-dessous fournit des preuves historiques reçues localement ; les preuves de production externes restent ouvertes.
Réparer la cause étroite
Références : RFC 9989 §7.4.
Demandez à l'intermédiaire de conserver le contenu signé dans la mesure du possible et vérifiez l'emplacement de la signature dans le service d'origine. Testez une route autorisée représentative avant de modifier la politique de domaine générale. Si un destinataire applique une exception locale, conservez sa portée, son propriétaire, son expiration et ses exigences de filtrage indépendantes. La livraison sous exception n’est pas un pass DMARC .
Clôturez l'enquête uniquement lorsque le chemin perdu, le changement effectué et la décision observée du récepteur sont documentés séparément. Testez à nouveau les flux de travail périodiques et à faible volume ainsi que le cheminement quotidien évident. Une transition à l'échelle de l'organisation vers une surveillance visant simplement à masquer un défaut de transfert peut réduire la protection du courrier non lié sans réparer l'intermédiaire.
Preuves de laboratoire SMTP conservées
Références : RFC 7208 §4, RFC 6376 §6.
La capture conservée datée du 7 novembre 2026 à 21:29:16 UTC enregistre que le récepteur de bouclage a capturé des messages directs, à transfert préservé et modifiés en pied de page via SMTP réel. Il a observé l'homologue 127.0.0.2 pour la connexion d'origine et 127.0.0.3 pour la connexion de transfert. pyspf a évalué ces adresses IP par rapport DNS des appareils isolés ; dkimpy a vérifié les signatures RSA réelles. Le cas direct a réussi les deux vérifications, la copie transférée préservée a échoué SPF mais a réussi DKIM aligné, et la copie de pied de page a échoué dans les deux cas. Authentication-Results générés par le récepteur et les messages bruts complets sont conservés avec les enveloppes et les valeurs SHA-256.
Le coureur historique et les messages conservés ont été inspectés pour cette révision ; l'expérience réseau n'a pas été réexécutée. Son exécution originale utilisait uniquement le bouclage et n'envoyait aucun courrier Internet. Son destinataire crée Authentication-Results à partir de ses propres contrôles, indiquant à ces champs la provenance connue du laboratoire. Le résultat et la disposition de l'authentification restent séparés : les six échantillons SMTP reçoivent 250 dans le cadre d'une politique de capture explicite, y compris les échantillons défaillants. La limite de confiance est ce laboratoire contrôlé, et non un fournisseur de boîtes aux lettres de production. L'adaptateur DNS fournit des réponses de luminaire conservées plutôt que d'interroger DNS public, et l'évaluateur DMARC utilise uniquement l'égalité de domaine stricte. La découverte complète du domaine organisationnel, l’analyse des politiques de production et les résultats du déploiement en direct n’ont pas encore été testés.