Une passerelle de messagerie sécurisée et DMARC résoudre des problèmes opérationnels qui se chevauchent mais ne sont pas interchangeables. Une passerelle peut inspecter, acheminer, mettre en quarantaine ou modifier les messages. DMARC évalue l'authentification alignée et fournit des informations sur la politique de domaine aux récepteurs. La question importante est de savoir comment se comporte votre itinéraire complet, y compris les transformations après la création d'une signature.
Dessinez le chemin réel du message
Enregistrez la soumission, la signature, le traitement de la passerelle et la réception finale dans l'ordre. Identifiez les composants que vous contrôlez et les identités que chacun est autorisé à signer. Un diagramme indiquant que seule la passerelle est activée ne peut pas établir si un récepteur en aval obtient une signature alignée intacte. Obtenez des messages bruts originaux et finaux à partir d’un itinéraire de test autorisé, en conservant les identifiants et les heures des messages.
DKIM couvre les en-têtes sélectionnés et un corps canonisé. Une réécriture du corps peut invalider une signature existante même si le lien modifié fait partie d'une fonctionnalité de sécurité légitime. RFC 6376 définit le comportement de signature et de vérification. Spécification DKIM. Conserver la liste des en-têtes signés, canonisation choix et tout paramètre de longueur du corps pour expliquer un échec spécifique.
Placez la vérification et la signature délibérément
Une passerelle entrante peut vérifier un message avant sa modification, mais ce résultat interne n'est pas automatiquement digne de confiance pour tous les destinataires en aval. Définissez comment le prochain système reconnaît les résultats fiables et ce qu'il fait avec les assertions d'en-tête non fiables. RFC 8601. Un vérificateur ultérieur vérifiant les octets modifiés peut obtenir un résultat différent pour une raison légitime.
Pour un itinéraire sortant que vous administrez, la signature après les transformations approuvées peut éviter de rompre la signature finale. Le signataire doit être autorisé pour son domaine, et alignement a encore besoin d’être évalué. L'ajout d'une signature valide à partir d'un domaine de passerelle non lié ne produit pas nécessairement un résultat DMARC aligné. Ne supprimez pas l’inspection de sécurité simplement pour conserver une signature sans revoir la conception plus large du contrôle.
Tracez une réécriture hypothétique
Supposons qu'un signataire brand.test autorisé signe un corps de message contenant une URL. Une passerelle modifie ensuite l'URL couverte sans ajouter ensuite de signature alignée autorisée. Si les octets signés canonisés changent, la signature antérieure ne sera pas validée par rapport au corps modifié. Une transformation qui laisse inchangés les octets signés canonisés pertinents n’a pas besoin de rompre la signature. Inspectez la canonisation, les en-têtes sélectionnés et toute limite l= au lieu de supposer que chaque réécriture a le même effet.
Si un signataire autorisé distinct signe le message final transformé, cette nouvelle signature peut être vérifiée même si l'ancienne signature échoue. Cela ne répare pas l’ancienne signature et ne prouve pas que le nouveau signataire avait une autorité commerciale. Évaluez l’alignement du nouveau domaine d= et le résultat du récepteur final de confiance. Il s'agit de résultats hypothétiques basés sur un protocole, et non d'échantillons de messages bruts, de clés générées, de sorties dkimpy ou d'une expérience de passerelle exécutée.
Traduire le résultat en un test d'itinéraire
En production, reproduisez la transformation autorisée pertinente à l'aide de destinataires contrôlés et de la configuration prise en charge par le fournisseur. Capturez les résultats fiables du destinataire final plutôt que de déduire le succès à partir de la console de passerelle. Comparez la même révision de contenu tout au long du parcours et notez les autres modifications telles que les préfixes de sujet ou les clauses de non-responsabilité. L'adoption d'une nouvelle signature ne prouve pas que l'authentification antérieure a survécu.
Testez également la gestion des échecs. Si une étape de signature n'est pas disponible, déterminez si le courrier est mis en file d'attente, échoue ou part sans la signature attendue. Gardez les instructions de récupération liées au service réel. Évitez un contournement d'urgence qui transforme un problème d'authentification contenu en un relais sans restriction ou une livraison non inspectée.
L'enregistrement d'acceptation doit nommer l'itinéraire testé, la transformation, le placement du signataire, les identités finales et le résultat du destinataire. Maintenir des contrôles séparés pour le filtrage des logiciels malveillants, hameçonnage détection et authentification de domaine. La réussite d'un test est une preuve utile de cette capacité, et non un certificat attestant que l'ensemble du message ou de la passerelle est sécurisé.
Limite source et exécution
RFC 9989 sections 4.4, 5.3.5 et 5.4 distinguer l'authentification, l'alignement et la manipulation ; un laissez-passer n'approuve pas le contenu du message. Les décisions opérationnelles ici sont des recommandations ciblées et des exemples explicitement hypothétiques, et non de nouveaux tests d'un client, d'un fournisseur ou d'un élément historique. Tout changement réel nécessite sa propre portée autorisée, des preuves conservées et une décision responsable.