Le transfert ne s'interrompt pas automatiquement DKIM. Un transitaire qui préserve le contenu du message couvert peut laisser la signature originale valide. Un redirecteur qui réécrit les en-têtes ou le contenu du corps couverts peut les invalider. Diagnostiquez ce que fait réellement le service de transfert plutôt que de traiter toutes les livraisons indirectes comme un seul mode de défaillance.
Tracer les identités et les transformations séparément
Au récepteur final, SPF évalue le système de connexion et l’identité SMTP pertinente. Le transfert peut modifier l’adresse IP de connexion même lorsque le corps du message n’est pas modifié. DKIM vérifie à la place le contenu du message couvert par rapport à la clé du domaine signataire. Ces mécanismes peuvent donc diverger sur un même message transmis.
Enregistrez le domaine From visible, chaque domaine de signature DKIM , sélecteur et résultat, l'identité de l'enveloppe et le saut de transfert. DMARC nécessite un chemin d'authentification de réussite aligné sur le domaine de l'auteur. Un alignement intact Signature DKIM peut fournir ce chemin dans le cadre d'une politique applicable lorsque le transfert est perturbé SPF, comme spécifié dans RFC 9989 §4.4.1. Une signature nouvellement ajoutée sous un domaine de transfert non lié ne s’aligne pas automatiquement.
Comparez les échantillons directs et transférés
Envoyez un message contrôlé vers une boîte de réception de test directe et via la route de transfert vers une autre boîte de réception de test. Conservez les messages bruts et les résultats des destinataires fiables. Utilisez un marqueur de test unique afin que les échantillons puissent être associés sans vous fier uniquement au sujet. Ne déduisez pas l’égalité du corps rendu.
Inspectez les modifications apportées au corps, au sujet et aux autres champs sélectionnés en h. Vérifiez c et toute balise l avant d’interpréter les différences. Standard canonisation peut tolérer certains changements de formatage, tandis qu'une réécriture substantielle peut modifier la représentation signée. Les en-têtes de transport ajoutés n'invalident pas en soi une signature qui ne couvrait pas ces nouvelles occurrences ; la sélection d'en-têtes répétés et la sursignature peuvent avoir de l'importance sous RFC 6376 §5.4.2.
Travailler à travers deux chemins
Le chemin illustratif A transmet le message sans modifier le contenu couvert. La signature originale peut rester valable. Le chemin B ajoute une bannière d'avertissement au corps signé, provoquant l'échec de la signature originale du corps complet. La connexion peut être identique sur les deux chemins, donc les observations SPF ne peuvent pas à elles seules expliquer la différence DKIM .
Un transitaire pourrait également réécrire le expéditeur d'enveloppe pour améliorer sa propre autorisation SPF . Cela ne restaure pas une signature DKIM brisée et ne crée pas nécessairement SPF alignement avec le domaine original visible depuis. Gardez les trois questions séparées : quelle identité a réussi SPF , quelle signature a réussi DKIM et si l'un ou l'autre des chemins est aligné.
Sélectionnez un remède limité
Si la préservation du contenu est compatible avec les obligations de sécurité du service, vérifiez les paramètres pris en charge pour éviter toute modification inutile. Si une modification est nécessaire, évaluez la signature documentée et la gestion du courrier indirect du service. N'accordez pas à des transitaires arbitraires vos clés de signature et ne les autorisez pas largement dans SPF pour faire disparaître un symptôme.
Un destinataire administratif peut utiliser des preuves fiables supplémentaires ou une politique locale pour le courrier indirect, mais il s'agit d'une décision d'acceptation distincte. Ne signalez pas cette acceptation comme une restauration de la signature originale. Conservez les exigences commerciales et tout propriétaire d’exception avec le résultat technique.
Fermer avec une preuve spécifique à l'itinéraire
Répétez les tests directs ou transférés pour le texte brut, le HTML et les pièces jointes après une modification. Enregistrez quelles signatures originales survivent, si une nouvelle signature apparaît, ainsi que les résultats finaux DMARC et de la livraison. Conservez l'itinéraire de transfert dans les tests de régression, car une modification ultérieure de la bannière ou de l'analyse peut modifier le résultat sans aucune modification DNS chez l'expéditeur.
Lire deux résultats hypothétiques au niveau du message
Supposons une politique DMARC applicable et un domaine d'auteur example.com :
- Chemin conservé : SPF échoue après le transfert, mais la signature d=example.com d'origine est toujours vérifiée. Cette identité DKIM exactement alignée fournit un laissez-passer DMARC .
- Chemin modifié : la signature DKIM d'origine échoue ; la seule nouvelle signature de passage et l'identité SPF appartiennent à forwarder.example.net . En supposant que ce domaine n'est pas lié à example.com , ni l'un ni l'autre ne fournit l'alignement, donc DMARC échoue. Le destinataire peut toujours prendre une décision de traitement local distincte.
Ne fusionnez pas le pass de la nouvelle signature avec le domaine de l'ancienne signature. Ces cas illustrent les conditions dans RFC 9989 §5.3.5; il ne s'agit pas de résultats capturés par le récepteur ni de garanties concernant chaque service de transfert.