Une livraison directe réussie ne constitue pas une preuve suffisante pour une DMARC politique. Un service de transfert modifie le chemin d'envoi et une liste de diffusion peut modifier le contenu signé. Créez un petit ensemble de tests qui représente les itinéraires dont l'entreprise a réellement besoin. Évaluez l'authentification séparément de la livraison afin qu'une exception au niveau d'un destinataire ne ressemble pas à une compatibilité universelle.
Établir la ligne de base
Références : RFC 9989 §4.4, RFC 9989 §5.3.5.
Choisissez des comptes d’expéditeur et de destinataire autorisés et un contenu inoffensif. Enregistrez le domaine From, expéditeur d'enveloppe, envoi d'IP, Sélecteur DKIM et domaine de signature. Conservez une copie de livraison directe et les résultats d’authentification du destinataire fiable. Capturez la politique DMARC applicable et alignement mode au moment du test. Si la ligne de base est déjà mal alignée, réparez cet expéditeur avant de diagnostiquer le transfert.
Sous RFC 9989, un passage aligné SPF ou DKIM Le mécanisme peut satisfaire DMARC . Le pass SPF sous le domaine d'un transitaire n'est pas automatiquement aligné sur le domaine de l'auteur. RFC 6376 explique pourquoi la préservation du contenu signé est importante pour DKIM . Enregistrez quel mécanisme survit plutôt que de considérer un résultat global vert comme une explication.
Exercer des variantes significatives
Références : RFC 6376 §3.4, RFC 8617 §7.2.1.
Incluez le transfert inchangé, la réécriture d'enveloppe, l'insertion de pied de page de liste, la modification de sujet et toute transformation MIME effectuée par le service réel. Testez plusieurs types de messages légitimes, en particulier ceux contenant des pièces jointes ou des chemins d'envoi tiers. La question pertinente est de savoir si la transformation modifie le matériel couvert par la signature réelle et canonisation, pas si le message semble identique chez un client.
Conserver un contrôle négatif dont la signature alignée est volontairement invalide dans un laboratoire isolé. Un récepteur qui accepte à la fois les cas valides et non valides peut appliquer la politique locale. Cette observation est utile, mais elle ne prouve pas que les deux messages sont authentifiés. Si ARC est présent, enregistrez séparément la validation de la chaîne, le scellant et la décision de confiance du destinataire. RFC 8617 ne fait pas de chaque chaîne valide une commande de livraison. Comme vérifié le 8 novembre 2026, la RFC reste expérimentale et un projet actif propose un statut historique ; considérez cette proposition avant de créer une nouvelle dépendance ARC .
Lire le montage reproductible
Références : RFC 6376 §6.
Le laboratoire retenu signe un message author.test inoffensif avec une clé RSA temporaire et le vérifie avec dkimpy. Le cas direct passe. Une copie transmise inchangée est toujours vérifiée. Un changement d'enveloppe de style SRS laisse également DKIM valide, même si l'identité SPF simplifiée est désormais forwarder.test et ne s'aligne pas. Un pied de page ajouté au corps signé échoue à la vérification et au modèle DMARC de domaine exact.
Chaque cas conserve le résumé du message, l'adresse IP de la route, l'identité de l'enveloppe, le domaine de signature et le verdict. La clé de vérification est publique ; aucune clé privée n'est conservée. Réexécuter le dispositif de génération de clé d'origine créerait de nouvelles clés et donc de nouveaux hachages de messages ; il n'a pas été rediffusé ici. Les verdicts attendus restent stables. Il s'agit d'un test local reproductible, et non d'un résolveur SPF complet, d'une implémentation DMARC , d'un validateur ARC ou d'un test d'un fournisseur de boîte aux lettres commercial.
Décidez si vous souhaitez continuer
Références : RFC 9989 §8.
Créez une matrice de routage montrant l'expéditeur, l'intermédiaire, le destinataire testés, la variante du message, le résultat de l'authentification et la disposition finale. Marquez les combinaisons non testées comme inconnues. L'exemple de matrice doit inclure un contrôle direct et une modification défaillante, et pas seulement des messages réussis sélectionnés après coup. L'échec du pied de page du laboratoire est une raison pour retenir cet itinéraire pour réparation ou une exception approuvée séparément.
Utilisez un déploiement contrôlé avec une autorité de restauration nommée et une surveillance adaptée au délai de reporting du fournisseur. Ne présumez pas que les recettes historiques de politique de pourcentage s’appliquent toujours à la spécification DMARC actuelle. Confirmez le comportement actuel du récepteur et de la plate-forme, puis conservez les preuves de politique et de message avant et après. Un changement de politique réussit lorsque les routes critiques légitimes continuent de fonctionner et que l'organisation comprend les échecs restants, et pas seulement lorsqu'un vérificateur DNS détecte une valeur plus stricte.
Itinéraire de transfert contrôlé conservé
Références : RFC 7208 §4, RFC 6376 §6, RFC 8601 §5.
La capture conservée du 7 novembre 2026 à 21:32:53 UTC enregistre un appareil distinct envoyant le message signé via de véritables connexions SMTP de bouclage. Ces sessions réseau ont été inspectées et non réexécutées pour cet examen. L'origine se lie à 127.0.0.2 , le transitaire envoie à partir de 127.0.0.3 et le destinataire final stocke chaque message. Ces adresses sont limitées à la machine locale. Les cas directs, inchangés, avec enveloppe réécrite et pied de page ont chacun une trace de transaction réelle avec des horodatages, des identités d'enveloppe et une acceptation finale. La réécriture est une substitution de domaine de type SRS pour cet atelier, et non une SRS mise en œuvre.
Chaque limite de réception calcule SPF à l'aide de pyspf 2.0.14 avec des réponses TXT locales explicitement injectées, et DKIM à l'aide de dkimpy avec la clé publique conservée. Le récepteur ajoute son propre Authentication-Results et Champs reçus après évaluation. Ces résultats ne sont fiables que dans cet appareil contrôlé, où le code d'insertion et les limites sont connus. Il n’accepte pas le texte de passe intégré arbitrairement comme son propre verdict. La politique DNS est une entrée locale statique et non une revendication concernant DNS public.
Au niveau du récepteur final, les résultats SPF sont respectivement réussite, échec, réussite et réussite. Les résultats DKIM sont réussite, réussite, réussite et échec. Le modèle d'alignement de domaine exact préserve donc l'authentification DMARC pour les trois premiers cas et échoue dans le cas du pied de page. Il ne s’agit pas d’une découverte complète de la politique DMARC . Le laboratoire stocke délibérément même le message défaillant pour inspection, de sorte que sa réponse 250 ne constitue pas une preuve qu'un fournisseur de production chargé de l'application du message le délivrerait.
L'exemple d'exception et le maintien du déploiement sont liés à cet itinéraire de pied de page historique : l'itinéraire inchangé préserve la signature, tandis que le pied de page de l'intermédiaire contrôlé la brise. Gardez toute allocation non approuvée jusqu'à ce que sa portée réelle, son propriétaire, son expiration et le comportement du destinataire soient examinés. Ces transactions contrôlées historiques documentent la comparaison des itinéraires locaux ; la compatibilité des fournisseurs de boîtes aux lettres de production, l'autorisation réelle des flux commerciaux et toute approbation d'exception opérationnelle restent non exécutées.