Vous testez votre domaine et tout passe. SPF, DKIM, DMARC, tout est au vert. Puis un client vous mentionne qu'un message que vous lui avez envoyé n'est jamais arrivé — et en creusant, vous découvrez qu'il faisait suivre ses courriels vers une autre adresse.

Ce n'est pas une coïncidence, et ce n'est pas un défaut de votre configuration. Le réacheminement automatique brise l'authentification du courriel d'une manière précise et prévisible. Une fois le mécanisme compris, ces échecs cessent de paraître aléatoires.

D'abord — de quel réacheminement parle-t-on ?

Deux choses très différentes portent ce nom, et une seule pose problème. La confusion est constante, alors prenons trente secondes.

Appuyer sur « Transférer » dans votre logiciel de courriel ne pose aucun problème. Vous cliquez, vous ajoutez peut-être une ligne, vous envoyez. Cela crée un nouveau message provenant de votre adresse, avec l'original cité en dessous ou joint. Il est authentifié comme votre domaine, avec vos SPF et DKIM. L'authentification de l'expéditeur d'origine n'est pas vérifiée du tout — rien de ce qui lui appartient n'est en jeu. Ce message arrive normalement.

C'est le réacheminement automatique qui casse. Une règle de redirection, un alias de boîte, un réglage « envoyer une copie de tout vers mon autre adresse », une liste de diffusion. Ceux-là relaient le même message, en conservant l'en-tête From: d'origine. Votre destinataire voit toujours le courriel comme venant de l'expéditeur initial — le serveur de réception vérifie donc toujours les SPF et DKIM de cet expéditeur, sauf que le message arrive maintenant d'ailleurs.

Tout le problème tient en une phrase : le message prétend toujours venir de vous, mais il ne vient plus de vous.

Tout ce qui suit concerne le second cas. Si vous transférez vos courriels à la main, rien de tout cela ne vous concerne.

SPF ne survit pas à un nouveau saut. Jamais.

SPF fonctionne en vérifiant l'adresse IP qui se connecte. Votre enregistrement SPF est une liste qui dit : « ces serveurs ont le droit d'envoyer en mon nom ». Le destinataire voit une connexion, regarde l'IP, et la compare à votre liste.

Ajoutez maintenant un intermédiaire. La boîte de votre client fait suivre tout son courrier vers une autre adresse. Cet intermédiaire se connecte au serveur suivant depuis sa propre adresse IP — qui ne figure pas dans votre enregistrement SPF, puisque vous n'en avez jamais entendu parler.

SPF échoue donc. Aucune configuration n'y échappe, et rien n'est brisé. SPF vérifie « est-ce que ça vient d'un serveur autorisé ? », et la réponse honnête est non : ça vient d'un réacheminement.

La règle mérite d'être énoncée avec précision, car « réacheminement » recouvre deux réalités différentes. Ce qui tue SPF, c'est une nouvelle connexion depuis une IP que vous n'avez jamais autorisée. Un alias sur le même serveur — du courrier redirigé à l'intérieur du même système, sans nouvelle connexion SMTP — ne déclenche aucune seconde vérification SPF, donc rien n'échoue. C'est le saut vers un serveur différent qui fait les dégâts.

L'exception qui n'en est pas une

Certains intermédiaires utilisent SRS, qui réécrit l'expéditeur d'enveloppe avec leur propre domaine. SPF passe alors — mais il passe pour le domaine de l'intermédiaire, pas pour le vôtre.

Or DMARC ne demande pas seulement si SPF a réussi. Il demande si le domaine qui a réussi correspond au domaine affiché dans l'en-tête From: que voit votre destinataire. Après SRS, ce sont deux domaines différents. La correspondance échoue, et la moitié SPF de DMARC échoue avec elle.

SRS sauve les vérifications SPF classiques. Il ne sauve pas DMARC. Cette distinction en piège beaucoup.

DKIM est la moitié qui peut survivre — à une condition

DKIM se moque des adresses IP. Il attache une signature cryptographique au message lui-même. Un intermédiaire peut faire transiter le message par autant de sauts qu'il veut, la signature reste vérifiable à l'arrivée.

À condition que rien n'ait modifié les parties du message qu'elle couvre.

Une signature DKIM couvre exactement deux choses :

• le corps du message
• une liste précise d'en-têtes, nommée à l'intérieur de la signature — généralement From, To, Subject, Date, Message-ID et quelques autres

Modifiez l'un ou l'autre, et la signature ne correspond plus. Pas « s'affaiblit » — échoue net.

Ce qui brise une signature

Ce qui ne la brise pas

Ajouter de nouveaux en-têtes est sans effet. Received:, X-N-importe-quoi, Authentication-Results: — aucun ne figurait dans la liste signée, donc la signature ne les remarque même pas.

C'est l'asymétrie décisive, et elle explique tout : un réacheminement simple ne fait qu'ajouter un en-tête Received:. Il ne touche à rien de signé. Voilà pourquoi le réacheminement simple survit à DKIM alors que les listes de diffusion, non.

La règle pratique

Relisez ce tableau en pensant à votre propre flux de courrier. Si vos clients utilisent une passerelle de sécurité qui appose [EXTERNE] sur les sujets venant de l'extérieur — et un grand nombre le font — alors la copie qui se trouve dans leur boîte ne porte plus de signature valide de votre part.

Quand cela fait mal — la nuance facile à manquer

On pourrait en conclure que votre courrier échoue à la porte de votre client. Ce n'est pas le cas, et la distinction compte.

Un serveur de réception vérifie l'authentification d'abord, sur le message tel qu'il est arrivé. Ce n'est qu'ensuite qu'il étiquette le sujet ou ajoute sa bannière. Votre message a donc passé SPF, passé DKIM, passé DMARC, et a été livré normalement. Rien n'a été rejeté.

Ce que la modification brise, c'est la copie qui se trouve désormais dans la boîte — et donc le saut suivant. Quand votre destinataire fait suivre ce message à son comptable, à un collègue ou à sa propre seconde adresse, la copie réacheminée porte une signature qui ne correspond plus au contenu modifié. C'est là que ça échoue.

L'énoncé exact n'est donc pas « les passerelles rejettent votre courrier ». C'est : les passerelles rendent votre courrier non réacheminable, silencieusement, en le réécrivant après avoir terminé de l'authentifier.

Les outils qui protègent vos destinataires sont fréquemment ceux qui brisent votre signature. Non par négligence : une bannière avertissant qu'un message vient de l'extérieur est réellement utile, et on ne peut pas l'ajouter sans modifier le corps.

Y compris le nôtre — un exemple honnête

Il serait facile d'en rester à une observation générale. C'est plus utile avec un nom dessus.

La même personne écrit DMARC Guy et exploite LastSpam, un service antipourriel. LastSpam fait les trois choses énumérées plus haut. Il réécrit le Subject pour étiqueter le courrier suspect. Il réécrit le Content-Type. Il injecte une bannière HTML dans le corps pour avertir le destinataire d'un expéditeur externe ou risqué.

Chacune de ces actions invalide la signature DKIM de l'expéditeur sur la copie livrée. Pas à l'occasion — par conception, sur chaque message qu'il modifie.

Pour être précis sur l'ordre, puisque c'est le point que ce billet a failli rater : LastSpam authentifie le message d'abord, et son verdict porte sur le message tel qu'il a été reçu. La réécriture vient ensuite. Il ne rejette pas un expéditeur légitime à la porte à cause de sa propre bannière. Ce qu'il fait, c'est remettre au destinataire une copie qui ne se vérifiera plus s'il la fait suivre.

« Alors pourquoi mon propre système de courriel l'accepte-t-il ? »

Parce qu'on le lui a demandé. Lorsqu'une entreprise place un service de filtrage devant son fournisseur de boîtes, elle configure ce fournisseur pour faire confiance au courrier provenant du filtre — c'est tout l'intérêt du montage. Microsoft 365, Google Workspace et les autres disposent tous d'un mécanisme pour cela. Le filtre a déjà fait le travail d'authentification, le fournisseur ne le refait donc pas.

Voilà pourquoi un message modifié atterrit malgré tout proprement dans la boîte de réception. La signature est brisée, mais plus rien en aval du filtre ne la vérifie.

La facture arrive plus tard, et ailleurs : au moment où ce message quitte le périmètre de confiance. Un transfert vers un comptable externe, une redirection vers une adresse personnelle, une liste de diffusion — aucun n'hérite de cette confiance, et tous voient une signature qui ne correspond plus.

Ses propres en-têtes X-LastSpam-* sont inoffensifs, puisque les nouveaux en-têtes n'ont jamais été signés. Ce sont la réécriture du sujet et la bannière qui posent problème — et ce sont aussi précisément les fonctions que les clients réclament. Une bannière qui avertit qu'un message vient de l'extérieur de l'entreprise a une vraie valeur. On ne peut pas l'ajouter sans toucher au corps, et toucher au corps invalide la signature.

La position honnête n'est donc pas « les passerelles bien conçues ne font pas ça ». Presque toutes le font, la nôtre comprise, et celles qui avertissent le plus utilement les utilisateurs sont celles qui brisent le plus les signatures. C'est un véritable compromis entre deux choses souhaitables, pas un défaut que personne n'aurait corrigé.

C'est exactement le problème que DKIM2 cherche à résoudre. Non pas en demandant aux intermédiaires de cesser de modifier les messages — ils ont de bonnes raisons — mais en leur permettant de consigner ce qu'ils ont changé, de façon vérifiable, pour que le destinataire puisse l'annuler et contrôler la signature d'origine. Un intermédiaire pourrait ajouter sa bannière tout en laissant votre DKIM se vérifier à l'autre bout. Voilà pourquoi il vaut la peine de s'intéresser à une spécification encore à l'état de brouillon que presque rien n'implémente.

Pourquoi cette combinaison est dangereuse en p=reject

Prenez les deux moitiés ensemble.

Pour le courrier livré directement, tout va bien. SPF passe, DKIM passe, DMARC passe.

Pour le courrier réacheminé, SPF a déjà échoué — c'est garanti. DKIM devient alors la seule chose qui sépare votre message de votre propre politique DMARC. Si quelque chose dans la chaîne a modifié le message, DKIM échoue aussi, les deux moitiés sont à terre, et DMARC fait ce que vous lui avez demandé. En p=reject, cela signifie généralement que le message est refusé net plutôt que classé dans les indésirables — mais c'est l'intention de la politique, pas une garantie. Les destinataires appliquent leur propre jugement, et certains grands fournisseurs mettent encore en quarantaine du courrier en p=reject au lieu de le refuser, selon la réputation de l'expéditeur.

Et voici ce qui rend la chose vraiment sournoise : rien de tout cela n'est visible de votre côté. Vos outils de test passent. Votre propre courrier arrive. L'échec ne survient que sur les chemins réacheminés, seulement pour certains destinataires, et reste invisible jusqu'à ce que quelqu'un vous le dise — ce que les gens font rarement, puisque de leur point de vue vous n'avez tout simplement jamais répondu.

Comment savoir quelle moitié a échoué

Quand vous pouvez mettre la main sur un message arrivé à destination, regardez son en-tête Authentication-Results. Il est ajouté par le serveur destinataire et il dit précisément ce qui s'est passé :

• dkim=fail (body hash did not verify) — le corps a été modifié. Un pied de page, une bannière, un réencodage.
• dkim=fail avec une signature qui ne correspond pas mais un corps intact — un en-tête signé a été changé. Presque toujours l'étiquetage du sujet.
• spf=fail sur un message réacheminé — attendu. Ce n'est pas à vous de le corriger.

Cette seule distinction — corps modifié ou en-tête modifié — vous dit à quel type d'intermédiaire vous avez affaire, et se lit en dix secondes.

Ce que vous pouvez réellement faire

Assurez-vous que DKIM signe, et signe correctement. Pour le courrier réacheminé, ce n'est pas un accessoire : c'est la seule moitié qui a une chance de survivre. Un domaine qui ne repose que sur SPF n'a aucune résilience au réacheminement.

Gardez une signature tolérante. DKIM possède un réglage de « canonicalisation » qui détermine sa sensibilité aux changements insignifiants. Le mode indulgent, relaxed/relaxed, tolère les différences d'espacement et de casse d'en-têtes qui casseraient autrement la signature. C'est le choix raisonnable et la plupart des expéditeurs devraient l'utiliser.

Ne prenez pas un échec en réacheminement pour une configuration brisée. Si votre courrier direct s'authentifie et que votre courrier réacheminé échoue, votre configuration est très probablement correcte. Ce que vous observez, c'est le mécanisme, pas une erreur.

Soyez délibéré avant de passer à p=reject. L'application stricte est la bonne destination. Mais allez-y après avoir examiné vos rapports DMARC, en sachant lesquels de vos destinataires font suivre leur courrier et ce que leurs intermédiaires font subir à vos messages — et non en supposant qu'un test au vert couvre tous les chemins.

L'industrie le sait, et tente de le régler

Le problème est assez ancien pour avoir engendré son propre contournement. ARC permet à un intermédiaire qui brise sciemment DKIM d'attacher une note disant « ceci était authentifié quand je l'ai reçu ». Ça fonctionne — mais uniquement si le destinataire final fait confiance à la parole de cet intermédiaire, ce qui transforme une garantie cryptographique en question de réputation.

L'effort plus récent, DKIM2, s'attaque à la cause plutôt qu'au symptôme : il permet à un intermédiaire de consigner ce qu'il a modifié de façon vérifiable, pour que le destinataire puisse annuler la modification et contrôler la signature d'origine. C'est une véritable amélioration et non un changement de nom, parce qu'elle supprime le besoin de croire l'intermédiaire sur parole : vous vérifiez vous-même la signature d'origine après avoir annulé la modification, au lieu de vous fier à une affirmation. Ce n'est pas pour autant sans confiance : le saut qui a rédigé la recette l'a tout de même signée. Mais cela ramène la question de la réputation vers la cryptographie.

DKIM2 n'est encore qu'un brouillon et pratiquement rien ne le vérifie aujourd'hui. Mais le fait que des gens sérieux y travaillent devrait vous dire quelque chose : le réacheminement qui brise l'authentification n'est pas un cas marginal sur lequel vous seriez tombé. C'est l'un des problèmes réellement non résolus du courriel.

Vous voulez d'abord savoir si votre domaine est correctement authentifié ? DMARC Guy vérifie SPF, DKIM et DMARC et vous explique en langage clair ce qu'il faut corriger.