La désinscription en un clic et List-Unsubscribe

Ce que font les deux en-têtes, quand ils sont obligatoires, et pourquoi un lien en pied de page ne suffit pas.

Les deux en-têtes

List-Unsubscribe (RFC 2369) existe depuis des décennies. Il indique au client de messagerie où envoyer une demande de désinscription, sous forme d’adresse mailto, d’URL https, ou des deux :

List-Unsubscribe: <mailto:unsub-abc123@unsub.example.com>, <https://example.com/u/abc123>

List-Unsubscribe-Post (RFC 8058) est la moitié plus récente, celle qui rend la désinscription possible en un seul clic :

List-Unsubscribe-Post: List-Unsubscribe=One-Click

Il indique au client qu’il peut envoyer une requête HTTP POST directement à l’URL https, sans autre interaction que le clic. C’est ce qui permet à Gmail d’afficher son propre bouton « Se désabonner » à côté du nom de l’expéditeur, au lieu d’obliger le destinataire à chercher dans votre pied de page.

Les deux en-têtes ensemble constituent la « désinscription en un clic ». List-Unsubscribe seul ne suffit pas, car sans la déclaration POST un client doit ouvrir l’URL dans un navigateur et espérer.

Pourquoi cela vous protège

L’alternative à une désinscription facile n’est pas un abonné conservé. C’est une plainte pour spam, le signal le plus dommageable qu’un destinataire puisse émettre à votre sujet. Quelqu’un qui ne trouve pas votre lien de désinscription utilisera le bouton « signaler comme spam », parce qu’il est juste là et qu’il fonctionne.

Une désinscription retire un destinataire. Une plainte dégrade la livraison pour tous.

C’est pourquoi Gmail et Yahoo en ont fait une exigence pour les expéditeurs en masse plutôt qu’une politesse : voir les exigences Gmail et Yahoo.

Les règles qui piègent

• Deux jours maximum pour arrêter les envois après une demande. Pas « à la prochaine campagne ».
• Aucune authentification. Exiger une connexion pour se désinscrire ne satisfait pas l’exigence.
• Aucune étape de confirmation. « Êtes-vous sûr ? » n’est pas un clic unique.
• Pas de centre de préférences comme seule option. Proposer des choix fins est acceptable en seconde étape, après que la désinscription a déjà pris effet.
• Gardez aussi le lien dans le corps. Les en-têtes servent les clients qui les prennent en charge ; le lien de pied de page sert tout le monde.
• Supprimez sur tous les flux, pas par liste. Quelqu’un qui se désinscrit de votre newsletter ne devrait pas recevoir votre autre campagne la semaine suivante.

Avec Mailverick

Mailverick pose les deux en-têtes sur chaque message envoyé, sans configuration :

List-Unsubscribe: <mailto:unsub-<token>@...>, <https://.../<token>>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Le token est signé et identifie le tenant, le job et le destinataire : une désinscription est donc attribuée correctement et ne peut pas être forgée. Les deux voies, mailto et https, sont actives, car certains clients utilisent l’une et d’autres l’autre.

Quand quelqu’un se désinscrit, vous recevez un événement unsubscribed et l’adresse est supprimée à partir de là. Les envois suivants reviennent en dropped avec la raison recipient_unsubscribed au lieu d’être livrés : la fenêtre de deux jours est donc respectée immédiatement et définitivement.

Les plaintes fonctionnent de la même manière via spam_reported, et chaque message porte un en-tête Feedback-ID pour que les fournisseurs puissent les remonter. Le vocabulaire d’événements est documenté dans Événements email.

Erreurs fréquentes

Seulement un lien en pied de page. Invisible pour les commandes de désinscription intégrées aux clients, là où la plupart des gens se désinscrivent désormais.

List-Unsubscribe sans List-Unsubscribe-Post. La moitié du mécanisme. Cela satisfait la RFC 2369 et pas l’exigence actuelle.

Une URL de désinscription qui exige une session. Fréquent quand le lien pointe vers une application authentifiée. Le clic arrive sous forme de POST anonyme depuis le fournisseur de messagerie, pas depuis un navigateur connecté.

Traiter le POST comme une vue de page. L’endpoint reçoit un POST sans navigateur, sans cookies et sans JavaScript. Il doit agir sur la requête elle-même, pas servir une page contenant un bouton.

Traiter la demande trop lentement. Un traitement nocturne des désinscriptions convient. Un traitement hebdomadaire, non.

Retirer l’en-tête du courrier que vous jugez critique. Si un message est vraiment critique, le destinataire ne s’en désinscrira pas. S’il le fait, il vous disait quelque chose.

Questions fréquentes

Le courrier transactionnel a-t-il besoin d’une désinscription ?

Non obligatoire, et pour du courrier de sécurité c’est même discutable. Mailverick inclut l’en-tête sur tout ce qu’il envoie, ce qui couvre l’exigence partout où elle s’applique sans vous demander de classer chaque message. Voir transactionnel et marketing.

Que se passe-t-il après une désinscription ?

Dans Mailverick, l’adresse est supprimée et les envois suivants sont arrêtés avant livraison, avec la raison visible dans le flux d’événements. Il n’y a rien à implémenter de votre côté.

Puis-je demander pourquoi la personne part ?

Après que la désinscription a pris effet, oui. Comme condition de celle-ci, non.

Une désinscription nuit-elle à ma réputation ?

Non. C’est le résultat souhaitable quand quelqu’un a perdu l’intérêt. C’est la plainte que vous avez évitée qui aurait fait mal.

Un destinataire peut-il être réinscrit ?

Seulement par lui-même, par une action explicite de sa part. Réintégrer une adresse désinscrite parce qu’un collègue l’a demandé est précisément le comportement que l’exigence vise à empêcher.

Dernière mise à jour : juillet 2026