List-Unsubscribe : l’en-tête qui protège la délivrabilité depuis les règles Gmail et Yahoo

L’en-tête List-Unsubscribe existe depuis les années 2000, mais il est devenu un prérequis technique incontournable depuis que Gmail et Yahoo ont commencé à l’exiger, en 2024, pour tout expéditeur massif. Sans lui, un domaine d’envoi commercial peut voir ses messages routés vers le dossier spam indépendamment de la qualité de son authentification SPF, DKIM et DMARC.

#Pourquoi cet en-tête est devenu obligatoire

Un expéditeur devient « bulk sender » aux yeux de Gmail dès qu’il envoie environ 5 000 messages ou plus vers des comptes Gmail personnels sur une période de 24 heures. Ce statut, une fois atteint, ne disparaît pas si le volume redescend ensuite. Yahoo applique un seuil comparable. Les deux fournisseurs exigent alors, pour les messages promotionnels et marketing, un mécanisme de désabonnement qui fonctionne réellement en un clic, sans page de confirmation intermédiaire, sans formulaire, sans connexion préalable.

Ce mécanisme est distinct de l’authentification décrite dans le guide sur SPF, DKIM et DMARC : une adresse parfaitement authentifiée mais dépourvue de désabonnement conforme reste exposée à un taux de plainte élevé, l’une des causes documentées de mise en spam.

#Le fonctionnement de la RFC 8058

La RFC 8058 définit deux en-têtes complémentaires. List-Unsubscribe porte l’URI de désabonnement, idéalement en HTTPS. List-Unsubscribe-Post signale au client de messagerie qu’il peut déclencher l’action par une simple requête POST, sans ouvrir de page :

List-Unsubscribe: <https://exemple.fr/desabonnement?token=abc123>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Quand le client de messagerie voit ces deux en-têtes ensemble, il affiche un bouton natif « Se désabonner » à côté de l’expéditeur et envoie, au clic, une requête POST directement au serveur, sans jamais charger de page dans un navigateur. C’est cette automatisation qui distingue le « one-click » d’un simple lien de désabonnement placé dans le pied de l’email.

#Implémenter l’en-tête côté serveur

La plupart des bibliothèques d’envoi transactionnel exposent une méthode dédiée pour ajouter des en-têtes personnalisés. Voici un exemple avec Symfony Mailer, courant chez les équipes qui gèrent elles-mêmes leur infrastructure d’envoi plutôt que de tout déléguer à un fournisseur tiers :

use Symfony\Component\Mime\Email;

$email = (new Email())
    ->from('[email protected]')
    ->to($destinataire)
    ->subject('La lettre du mois')
    ->html($corpsHtml);

$headers = $email->getHeaders();
$headers->addTextHeader(
    'List-Unsubscribe',
    ', '
);
$headers->addTextHeader('List-Unsubscribe-Post', 'List-Unsubscribe=One-Click');

$mailer->send($email);

Le point technique le plus souvent raté : l’URL référencée par List-Unsubscribe doit traiter la requête POST comme une désinscription immédiate et définitive, sans redirection vers une page de confirmation. Une route qui affiche « Êtes-vous sûr de vouloir vous désabonner ? » casse la conformité one-click, même si l’en-tête est présent et syntaxiquement correct.

#Ce que proposent les plateformes d’envoi

#Les seuils à connaître par fournisseur

Depuis 2024, Gmail et Yahoo exigent un désabonnement en un clic pour tout expéditeur dépassant 5 000 messages par jour vers leurs domaines, avec un délai de traitement plafonné à 48 heures.

#Erreurs fréquentes qui invalident la conformité one-click

La spécification tient en quelques lignes, mais son implémentation concentre un nombre disproportionné d’erreurs récurrentes, souvent invisibles tant qu’aucun fournisseur ne les sanctionne explicitement.

La première tient à la route elle-même : certains frameworks appliquent par défaut une protection CSRF à tous les endpoints POST, y compris celui de désabonnement. Le client de messagerie n’a ni cookie de session ni jeton CSRF à présenter, si bien que la requête échoue silencieusement et l’utilisateur reste inscrit sans que personne ne s’en aperçoive côté expéditeur. La route de désabonnement doit donc être explicitement exclue de ce contrôle, en s’appuyant plutôt sur le jeton propre à l’URL pour authentifier la demande.

La deuxième erreur consiste à répondre avec un code de statut inattendu. Certains clients de messagerie considèrent qu’un code différent de 200 ou 202 signale un échec et retentent l’opération, ou l’abandonnent purement. Une route qui redirige en 302 vers une page de remerciement, aussi anodine paraisse-t-elle pour un visiteur humain, sort du comportement attendu par la RFC.

La troisième, plus subtile, touche au délai de propagation interne : l’en-tête peut pointer vers une route parfaitement fonctionnelle, mais si la désinscription n’est répercutée dans la base d’envoi qu’après un traitement différé de plusieurs heures, un nouvel envoi programmé entre-temps repart vers une adresse qui se croyait désinscrite. Les 48 heures accordées par Gmail et Yahoo pour honorer la demande couvrent le traitement, pas une file d’attente parallèle qui l’ignore.

Enfin, l’adresse figurant dans l’en-tête From doit rester cohérente avec le domaine d’authentification et avec le domaine de la route de désabonnement. Un envoi effectué depuis une plateforme tierce avec un domaine de tracking différent de celui utilisé pour l’alignement DMARC peut, dans certains cas, fragiliser la lecture de l’en-tête par le client de messagerie, en particulier lorsque plusieurs sous-domaines cohabitent sans cohérence de configuration.

#Vérifier son implémentation avant l’envoi en masse

Un envoi de test suffit à confirmer la présence syntaxique des en-têtes : la plupart des webmails affichent l’option de désabonnement native dès qu’ils la détectent correctement formée. Les outils d’analyse de délivrabilité gratuits, comme mail-tester, affichent également un contrôle spécifique sur la présence et la validité de List-Unsubscribe. Il reste ensuite nécessaire de tester la route de désinscription elle-même : une requête POST envoyée manuellement vers l’URL déclarée doit désinscrire l’adresse sans redirection ni page intermédiaire, exactement comme le ferait un client de messagerie.

Ce contrôle technique complète utilement les vérifications de rendu déjà couvertes dans le guide sur le comportement du HTML dans les clients de messagerie, où l’incohérence entre expéditeurs de test explique une bonne partie des mauvaises surprises en production.

#Ce qu’il faut retenir

L’en-tête List-Unsubscribe n’est plus une option de confort mais une condition d’entrée dans la boîte de réception dès qu’un volume d’envoi dépasse quelques milliers de messages par jour. Son implémentation technique est simple, deux lignes d’en-tête et une route serveur, mais l’erreur la plus fréquente reste de la faire passer par un formulaire de confirmation qui invalide la promesse du one-click.

#Pour aller plus loin

Source : Google, « Email sender guidelines FAQ », documentation officielle Gmail pour les expéditeurs.