Comment le transfert d'e-mails casse l'authentification — et ce que vous pouvez y faire
· DMARC Analyzer Pro
Le transfert d'e-mails est l'un des plus grands défis pour SPF et DMARC. Découvrez pourquoi il casse l'authentification et comment ARC et DKIM peuvent aider.
Vous avez tout fait correctement — SPF est configuré, DKIM signe, DMARC est appliqué — et pourtant certains de vos e-mails légitimes échouent encore à l'authentification. Le coupable est presque toujours le transfert d'e-mails.
Pourquoi le transfert casse SPF
Lorsqu'un message est transféré d'un serveur à un autre, l'adresse IP du serveur de transfert remplace celle du serveur original dans l'enveloppe SMTP. Puisque SPF valide l'IP du serveur connecté par rapport à l'enregistrement SPF de l'expéditeur, le message transféré échouera au SPF car le serveur de transfert n'est pas autorisé à envoyer en votre nom.
C'est une limitation fondamentale du SPF par conception. Il authentifie le serveur, pas le message — et le transfert change le serveur.
Les listes de diffusion aggravent le problème
Les listes de diffusion réécrivent typiquement l'expéditeur de l'enveloppe, modifient les lignes d'objet et ajoutent des pieds de page. Chacune de ces modifications peut casser à la fois SPF et DKIM. La modification de la ligne d'objet seule suffit à invalider une signature DKIM si l'en-tête Subject était inclus dans les en-têtes signés.
ARC — Authenticated Received Chain
ARC (RFC 8617) a été développé spécifiquement pour résoudre le problème du transfert. Lorsqu'un serveur intermédiaire (comme un service de transfert ou une liste de diffusion) reçoit un message, il peut enregistrer les résultats d'authentification originaux dans un ensemble d'en-têtes ARC avant toute modification.
Les destinataires en aval peuvent alors consulter ces en-têtes ARC pour voir quel était le statut d'authentification avant le transfert. S'ils font confiance à l'intermédiaire, ils peuvent utiliser les résultats ARC pour prendre une décision de livraison plus éclairée, même lorsque SPF et DKIM ont techniquement échoué.
L'adoption d'ARC croît régulièrement. Google, Microsoft et d'autres grands fournisseurs valident déjà les en-têtes ARC, et de nombreux intermédiaires ajoutent la signature ARC à leur infrastructure de transfert.
Recommandations pratiques
Assurez-vous que DKIM est toujours en place — c'est votre meilleure défense contre les échecs liés au transfert. Configurez vos signatures DKIM pour inclure des en-têtes qui ont peu de chances d'être modifiés par des intermédiaires.
Surveillez vos rapports DMARC pour détecter des patterns d'échecs liés au transfert. Les indicateurs courants incluent des échecs provenant de services de transfert bien connus, de systèmes de messagerie universitaires et de processeurs de listes de diffusion. Ceux-ci sont généralement bénins et ne devraient pas vous alarmer, mais ils valent la peine d'être suivis.
Si vous exploitez vous-même un service de transfert, implémentez la signature ARC pour préserver l'authentification des messages que vous transférez. Cela profite à l'ensemble de l'écosystème e-mail et améliore la délivrabilité des messages passant par vos systèmes.