Un message transféré critique pour l'entreprise peut échouer à l'authentification sans être frauduleux. Cela ne rend pas tous les messages circulant sur le même itinéraire dignes de confiance. Une exception doit identifier le flux de travail exact, la raison pour laquelle le contrôle normal échoue, les garanties restantes et la personne qui la supprimera. Traitez l’exception comme une décision temporaire à risque étayée par des preuves, et non comme une déclaration permanente selon laquelle l’expéditeur est en sécurité.
Tracez le chemin légitime
Références : RFC 7208 §4.1, RFC 6376 §3.4, RFC 9989 §5.3.5.
Commencez par un service nommé et un propriétaire d’entreprise. Enregistrez l'expéditeur d'origine, le service de transfert, le destinataire final et les destinataires prévus. Obtenez un échantillon direct autorisé et un échantillon indirect, en conservant l'enveloppe SMTP séparément du champ De visible. Comparez l'IP de connexion, SPF identité, chacun DKIM résultats du domaine de signature et du récepteur de confiance à chaque limite. Réduisez le contenu personnel dans le message conservé.
SPF évalue l'hôte qui se connecte par rapport à une identité d'enveloppe ; un transitaire ordinaire peut changer cet hôte sans changer le domaine de l'enveloppe d'origine. DKIM peut survivre au transfert lorsque le matériel signé est conservé, mais une modification du pied de page ou du sujet peut l'invalider. DMARC a besoin d’un mécanisme aligné de passage. Ces distinctions suivent RFC 7208, RFC 6376 et RFC 9989. Une exception ne modifie pas les résultats de leur protocole.
Décrivez la plus petite décision
Références : RFC 9989 §7.4.
Écrivez l'itinéraire concerné, les destinataires, l'objet du message, le volume attendu et l'échec observé. Incluez un propriétaire, une référence d’approbation, un début et une expiration, un déclencheur de révision, des contrôles de compensation, des critères de restauration et de suppression. Il s’agit de recommandations opérationnelles et non de champs mandatés par le protocole. Préférez une réparation qui préserve l'authentification alignée à une allocation qui supprime l'inspection. Une autorisation réservée au domaine de l'expéditeur est particulièrement faible, car il s'agit de l'identité qu'un attaquant peut imiter.
Si la plate-forme de réception propose des contrôles étendus, vérifiez la correspondance exacte et la priorité dans sa documentation actuelle. Ne présumez pas d'une étiquette de connecteur, d'une adresse IP source ou ARC pass identifie de manière unique l’application légitime. L'infrastructure partagée peut transporter le courrier d'autres clients. Conserver les contrôles anti-malware et de protection des comptes, sauf indication contraire dans une politique explicitement révisée ; une exception d’authentification ne doit pas devenir silencieusement un contournement de filtrage universel.
Travailler l'exemple d'exception
Références : RFC 9989 §4.4.
Le laboratoire isolé retenu a créé un message signé à partir de author.test. Son cas direct réussit le modèle SPF limité et la vérification DKIM réelle. Le transfert via forwarder.test préserve DKIM . Un changement d'enveloppe de style SRS laisse DKIM intact mais rend le domaine SPF différent du domaine From visible. L'ajout d'un pied de page interrompt ensuite DKIM , ne laissant aucun mécanisme de transmission aligné dans ce modèle de domaine exact.
L'exception proposée s'applique uniquement à ce dernier flux de travail fictif pendant que l'opérateur de liste supprime la modification ou adopte une conception d'expéditeur convenue. Le paquet de preuves contient des octets de message, du matériel de vérification publique et des résultats calculés. Il ne s’agit pas d’un incident client ou d’une livraison de production observée. Le SPF et alignement la logique est volontairement limitée ; la vérification DKIM est réelle. Des échantillons d'itinéraires de production et des tests de règles spécifiques au récepteur restent nécessaires avant d'approuver une allocation réelle.
Vérifier et supprimer
Références : RFC 9989 §7.4.
Fixez la date de révision autour du plan de réparation plutôt que de laisser l'exception ouverte indéfiniment. Comparez de nouveaux échantillons après une migration de service, un changement de transfert ou une mise à jour de fournisseur. Testez l'itinéraire réparé avec l'autorisation désactivée dans une portée contrôlée et vérifiez à la fois la livraison légitime et le rejet ou l'examen continu du trafic non lié.
Fermez l'enregistrement uniquement lorsque le propriétaire responsable confirme le flux commercial et que le propriétaire du titre accepte les preuves. Conserver le motif de la suppression et la référence de configuration finale. Si la réparation échoue, renouvelez par une décision délibérée avec une nouvelle expiration au lieu de permettre une dérive silencieuse.
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.