Pourquoi l'e-mail que vous vous êtes renvoyé a atterri dans les spams

Configurez un renvoi automatique de votre ancien compte vers le nouveau, et une partie de ce courrier disparaîtra silencieusement dans les spams — non pas parce que votre fournisseur est défaillant, mais parce que le renvoi réécrit qui envoie le message sans réécrire la preuve cryptographique. SPF vérifie le mauvais serveur, le verdict DMARC bascule à l'échec, et un e-mail légitime que vous vous êtes envoyé est mis en quarantaine. La solution a un nom : ARC, défini dans RFC 8617 en 2019.

Pourquoi le renvoi fait-il échouer ma vérification SPF ?

Parce que SPF vérifie le dernier serveur qui a relayé le message, et le renvoi change ce serveur. SPF — Sender Policy Framework — est un enregistrement DNS qui énumère les adresses IP autorisées à envoyer des e-mails pour un domaine. Quand bank.com vous envoie un reçu, le serveur de réception vérifie : cet e-mail provient-il d'une IP autorisée par bank.com ? Oui. Validé.

Maintenant, renvoyez ce reçu de Gmail vers votre nouvelle adresse. Les serveurs Google le relaient. Le serveur de réception final exécute la vérification SPF et demande : Google est-il autorisé à envoyer pour bank.com ? Non, il ne l'est pas. SPF échoue. La documentation Workspace de Google l'explique clairement — les e-mails renvoyés échouent SPF parce que le serveur de renvoi ne figure pas dans l'enregistrement SPF du domaine d'origine. Rien n'a été usurpé. La vérification regarde simplement le mauvais saut.

Alors pourquoi cela les envoie-t-il dans les spams ?

DMARC. Un SPF échouant seul était autrefois survivable ; DMARC l'a transformé en verdict. DMARC lie SPF et DKIM ensemble et dit aux destinataires quoi faire quand les deux échouent : rien, mettre en quarantaine, ou rejeter. En 2024, les grands envoyeurs n'avaient pas le choix — Google et Yahoo ont commencé à exiger DMARC pour quiconque envoie plus de 5 000 messages par jour à leurs utilisateurs.

DKIM, l'autre pilier, est une signature intégrée au message. En théorie, elle survit au renvoi, car elle signe le contenu, pas la route. En pratique, tout ce qui touche au message la casse. Une liste de diffusion qui ajoute un pied de page « vous êtes inscrit, se désabonner ici », un serveur qui réécrit la ligne d'objet, même un changement dans la façon dont une ligne s'enroule — la signature ne correspond plus, et DKIM échoue aussi. Maintenant, les deux piliers sont tombés, DMARC dit l'échec, et votre propre reçu est dans le dossier indésirables.

Qu'est-ce qu'ARC et répare-t-il vraiment cela ?

ARC — Authenticated Received Chain, RFC 8617 — permet à un renvoyeur honnête de certifier que le courrier a passé l'authentification avant qu'il le touche. Le serveur de renvoi estampille le message avec un enregistrement scellé disant « quand cela m'a atteint, SPF et DKIM étaient valides — faites confiance à ma parole pour la partie que vous ne pouvez pas vérifier ». Le destinataire final, s'il fait confiance à ce renvoyeur, peut ignorer l'échec DMARC et livrer le message.

Le hic réside dans « s'il fait confiance ». ARC n'est pas un mot de passe ; c'est un système de réputation. Un destinataire pèse si le scelleur ARC est un opérateur connu et bien intentionné. Google tant estampille les en-têtes ARC que les honore des envoyeurs en qui il a confiance, c'est pourquoi un renvoi Gmail-vers-Gmail survit généralement tandis qu'un renvoi via un ancien relais universitaire ne survit pas.

Si vous gérez vous-même le renvoi, deux actions concrètes aident. Utilisez Server-Side Redirect / réécriture de style SRS si votre hôte l'offre, ce qui réécrit l'expéditeur d'enveloppe pour que SPF vérifie par rapport à votre renvoyeur au lieu du domaine d'origine. Et préférez le renvoi entre fournisseurs qui soutiennent tous les deux ARC. Si vous consolidez les comptes et voulez que la destination gère simplement le chaos d'authentification pour vous, c'est exactement le type de tuyauterie qu'une plateforme d'e-mail IA est construite pour absorber.

Quand devrais-je arrêter de blâmer mon fournisseur ?

Quand le schéma est « seul le courrier renvoyé échoue », le fournisseur fait correctement son travail — le protocole est le problème. Voici le signe : ouvrez les en-têtes du message manquant et cherchez la ligne Authentication-Results. Si vous voyez spf=fail accompagné d'une IP d'envoi qui appartient à un renvoyeur plutôt qu'à l'expéditeur d'origine, c'est SPF vérifiant le mauvais saut. Si dkim=fail apparaît sur un courrier qui est passé par une liste ou un relais qui édite les messages, c'est une signature altérée, pas une contrefaçon.

La vérité inconfortable est que l'authentification des e-mails a été ajoutée, couche après couche, sur deux décennies à un système qui n'a jamais supposé que quelqu'un mentirait. SPF est arrivé en 2006, DKIM en 2007, DMARC en 2015, ARC en 2019 — chacun comblant un trou que le dernier a ouvert. Le renvoi est la couture où ces quatre se frottent l'un contre l'autre, et votre boîte de réception est où vous sentez la friction.

@@END@@