Google et Yahoo : exigences de désabonnement en un clic

Désabonnement en un clic, obligatoire ?

Le désabonnement en un clic est obligatoire dans le périmètre que fixe chaque fournisseur de messagerie, pas de façon universelle. C’est une exigence de fournisseur, pas une loi, et elle vise des expéditeurs et types de messages précis, pas chaque e-mail. Le tableau ci-dessous sert de test d’applicabilité ; les sections suivantes citent la formulation exacte de chaque fournisseur.

Un expéditeur sous le seuil de Google peut le franchir pendant une campagne : classez les flux avant une hausse de volume, pas après un rejet. L’expéditeur ou son ESP ajoute les en-têtes et gère l’endpoint ; le fournisseur de messagerie décide d’afficher ou non un bouton de désabonnement. Pour la différence entre loi et politique, voir la loi sur le désabonnement en un clic.

Quelles sont les exigences ?

Google exige la paire d’en-têtes RFC 8058 sur les e-mails couverts

Selon Google, les expéditeurs en masse concernés doivent offrir le clic unique via les en-têtes List-Unsubscribe et List-Unsubscribe-Post de la RFC 8058.

List-Unsubscribe: <https://unsubscribe.yourdomain.com/list/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

La RFC 2369 définit List-Unsubscribe comme un en-tête contenant une ou plusieurs URL entre chevrons pour les commandes de liste. La RFC 8058, RFC Standards Track publiée en janvier 2017, impose une URI HTTPS dans l’en-tête et ajoute la valeur fixe List-Unsubscribe-Post, qui signale au récepteur qu’il peut agir en un clic. La section 5 en fait une chaîne fixe, pas un champ libre.

L’URI HTTPS doit contenir un identifiant opaque et difficile à falsifier, pas une adresse de destinataire ou un nom de liste en clair. La RFC 8058 n’impose pas de format de jeton ; l’expéditeur doit le rendre difficile à deviner et le limiter au désabonnement voulu.

Selon la FAQ de Google, un lien mailto reste possible mais ne remplit pas l’exigence de clic unique de Google. Une entrée mailto: peut figurer comme commande de liste RFC 2369 supplémentaire, sans offrir le comportement en un clic de la RFC 8058. Pour la distinction côté protocole, voir le désabonnement en un clic et la paire d’en-têtes RFC 8058.

Une signature DKIM valide doit couvrir les deux en-têtes

La RFC 8058 exige au moins une signature DKIM valide sur le message, et les en-têtes List-Unsubscribe et List-Unsubscribe-Post DOIVENT être couverts par cette signature, listés dans la balise h= de l’en-tête DKIM-Signature.

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com;
 h=from:to:subject:list-unsubscribe:list-unsubscribe-post;
 ...

Ce n’est qu’une forme d’en-tête illustrative. Inspectez les en-têtes bruts d’un message livré pour confirmer que la signature de production couvre les deux champs. Un statut « DKIM activé » sur une plateforme ne prouve pas que sa signature inclut ces deux en-têtes, et un relais qui ajoute ou réécrit des en-têtes après signature casse la couverture.

L’endpoint doit traiter un POST HTTPS sans contexte de session

Selon la RFC 8058, un système de réception peut envoyer un POST HTTPS à l’URI de List-Unsubscribe, avec la clé et la valeur de List-Unsubscribe-Post comme corps de requête. Google publie cet exemple de requête dans ses consignes :

POST /unsubscribe/example HTTP/1.1
Host: solarmora.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-Click

Selon la RFC 8058, le récepteur DEVRAIT envoyer multipart/form-data et PEUT envoyer application/x-www-form-urlencoded. Un endpoint interopérable accepte les deux.

L’endpoint ne peut pas dépendre de l’état du navigateur. Selon la RFC 8058, le POST NE DOIT PAS inclure de cookies, d’autorisation HTTP ni d’autre contexte, et l’expéditeur NE DOIT PAS renvoyer de redirection HTTPS, car les POST redirigés ne sont pas fiables. Un centre de préférences, une connexion ou une page de confirmation peut suivre un lien du corps, mais ne peut pas conditionner la transaction RFC 8058.

Le récepteur NE DOIT PAS non plus envoyer le POST sans le consentement de l’utilisateur. Le fournisseur l’obtient via sa propre interface. La RFC 8058 n’oblige ni Gmail, ni Yahoo, ni aucun fournisseur à afficher un bouton de désabonnement sur chaque message.

Google exige aussi un lien de désabonnement visible dans le corps

Google exige, en plus du désabonnement en un clic, un lien de désabonnement bien visible dans le corps du message. L’action par en-tête et le lien visible sont deux exigences distinctes ; un en-tête List-Unsubscribe ne remplace pas le lien, et selon Google un lien vers un centre de préférences seul n’est pas conforme à la RFC 8058 sans les en-têtes.

Le lien visible peut mener à une gestion d’abonnement plus large. L’endpoint RFC 8058 a un rôle plus étroit : traiter le POST sans session web ni redirection. Testez les deux chemins séparément.

Yahoo exige un en-tête list-unsubscribe fonctionnel sur les e-mails visés

Selon les bonnes pratiques de Yahoo, les expéditeurs en masse devraient « implémenter un en-tête list-unsubscribe fonctionnel, qui gère le désabonnement en un clic pour les messages marketing et d’abonnement ». La page juge le POST de la RFC 8058 « vivement recommandé ».

La FAQ expéditeurs de Yahoo est plus directe : « Vous devez mettre en place l’en-tête list-unsubscribe (de préférence selon la RFC 8058) pour remplir l’exigence de désabonnement en un clic. » La FAQ ajoute qu’un lien de désabonnement dans le corps ne suffit pas seul.

Lisez ces phrases ensemble. Yahoo exige un en-tête list-unsubscribe fonctionnel pour les types de messages couverts et désigne la RFC 8058 comme méthode en un clic préférée. Ne faites pas du « vivement recommandé » de Yahoo pour le POST RFC 8058 une obligation universelle.

Yahoo exige un traitement sous deux jours

La page de bonnes pratiques de Yahoo demande d’« honorer les désabonnements sous 2 jours ». Sa FAQ confirme : « Si le désabonnement n’est pas honoré sous 2 jours, l’exigence n’est pas remplie. »

C’est un délai propre à Yahoo. La page de consignes de Google n’en fixe aucun : les deux jours ne sont pas une exigence commune à Google et Yahoo.

Le délai porte sur une suppression durable. Une réponse HTTP de l’endpoint ne prouve pas que chaque système de campagne, ESP et chemin d’envoi de production cessera d’envoyer les e-mails couverts.

Le sort des e-mails non conformes

La FAQ de Yahoo indique : « Si vous ne remplissez pas les exigences, vos e-mails peuvent être envoyés en spam ou rejetés. En cas de rejet, nous renverrons un code d’erreur précis avec des informations sur le rejet. » « Peuvent » compte : Yahoo ne dit pas que tout message non conforme sera rejeté, et ne liste pas les chaînes.

Selon la FAQ de Google, un message qui ne remplit pas l’exigence de clic unique n’est pas rejeté ni classé en spam automatiquement pour ce seul motif. Son avis d’application indique que Gmail renforce l’application sur le trafic non conforme depuis novembre 2025, avec des perturbations possibles, dont des rejets temporaires et définitifs. Un e-mail non désiré sans désabonnement simple est aussi plus souvent signalé comme spam, ce qui nourrit le taux de plaintes que les deux fournisseurs plafonnent à 0,3 %.

Quand l’exigence entre-t-elle en vigueur ?

Selon les consignes de Google, les exigences pour les expéditeurs de près de 5 000 messages ou plus s’appliquent depuis le 1er février 2024 aux comptes Gmail personnels. La FAQ ajoute que les expéditeurs ayant déjà un lien de désabonnement avaient jusqu’au 1er juin 2024 pour mettre en place le clic unique dans tous leurs messages commerciaux et promotionnels, et que l’application sur le trafic non conforme se renforce depuis novembre 2025.

Le calendrier échelonné de Yahoo diffère. Sa FAQ indique : « L’application commencera en février 2024, et nous continuerons à la déployer progressivement en suivant les indicateurs de conformité. Remarque : l’application de la politique List-Unsubscribe commencera en juin 2024. »

La date de février 2024 chez Yahoo marque le début de l’application de ses exigences générales. Juin 2024 est la date d’application sourcée de sa politique List-Unsubscribe en particulier. Ne fusionnez pas ces dates en une échéance commune.

La RFC 8058 n’est pas une politique de 2024. C’est une RFC Standards Track finale de l’IETF depuis janvier 2017, issue de l’ancienne syntaxe de commandes de liste de la RFC 2369. La RFC 2369 seule décrit des liens de commande ; la RFC 8058 ajoute le signal d’en-tête signé et le flux POST encadré qui permettent le clic unique.

Comment mettre en œuvre l’exigence ?

1. Classez le trafic par destinataire et type de message

Mesurez le volume quotidien vers les comptes Gmail personnels, par domaine principal, à part des destinataires Google Workspace. Pour Yahoo, séparez le marketing et l’abonnement du transactionnel. Recensez chaque système de production qui envoie du promotionnel : ESP, campagnes CRM, notifications produit et services de messagerie maison.

Liez ce classement au vrai chemin d’envoi de production. L’estimation d’audience d’un outil de campagne peut différer du routage final et du volume réel, et un expéditeur au-dessus du seuil de Google ne respecte pas la règle en ajoutant les en-têtes à sa seule grosse newsletter.

2. Créez une URI de désabonnement HTTPS opaque

Configurez la plateforme d’envoi ou l’outil de liste pour créer une URI HTTPS difficile à falsifier, propre au destinataire. L’endpoint doit pouvoir identifier l’abonnement visé sans demander au récepteur de se connecter, d’accepter des cookies ou de remplir un autre formulaire.

N’utilisez ni adresse de destinataire brute ni identifiant de compte réutilisable dans l’URI. Traitez l’URI comme une donnée sensible et n’exposez pas sa valeur complète dans les journaux ou tickets courants. Ne copiez pas les URL ou identifiants de désabonnement d’un autre client.

3. Ajoutez les deux en-têtes avant DKIM

Ajoutez List-Unsubscribe avec l’URI HTTPS et List-Unsubscribe-Post: List-Unsubscribe=One-Click à chaque message couvert avant de générer sa signature DKIM. Inspectez l’en-tête DKIM-Signature généré pour confirmer que sa liste h= inclut les deux noms.

Si un autre relais modifie ou ajoute des en-têtes après la signature, testez le message après le dernier saut de production. Une bonne configuration en amont peut échouer si un saut ultérieur change les en-têtes signés.

4. Acceptez le POST en un clic tel quel

Configurez l’endpoint pour accepter le corps exact List-Unsubscribe=One-Click dans l’un ou l’autre encodage autorisé. Traitez une requête valide sans redirection, cookie, demande d’autorisation ni JavaScript.

Ne redirigez pas l’endpoint vers une page de connexion, de confirmation, de consentement ou de préférences. La RFC 8058 exclut toute redirection HTTPS de la transaction en un clic.

Gérez sans risque les requêtes valides répétées. Un destinataire déjà retiré doit le rester après une seconde requête, sans doublon de retrait ni erreur qui masque le résultat.

5. Gardez un lien visible dans le modèle, relié à la suppression

Placez un lien de désabonnement bien visible dans le corps de chaque message marketing et d’abonnement concerné. Vérifiez le message rendu, pas seulement l’éditeur de modèle : la mise en page ou des conditions de contenu peuvent masquer le lien dans une campagne.

Quand l’un des chemins reçoit une requête valide, retirez le destinataire de la liste concernée et faites parvenir la suppression à chaque expéditeur de production qui envoie le trafic de cette liste. Pour les e-mails couverts par Yahoo, vérifiez la suppression sous deux jours. L’endpoint ne remplace pas les preuves de consentement ni la gouvernance des listes entre marques et systèmes.

Pour des modèles propres à une plateforme, voir Mailchimp, SendGrid ou Braze et le désabonnement en un clic si l’une d’elles fait partie du chemin d’envoi.

Comment valider la conformité ?

Validez la conformité du désabonnement en un clic sur quatre couches, dans l’ordre : les enregistrements DNS publiés, la configuration de la plateforme d’envoi, un message de production livré, et l’endpoint avec la liste de suppression qu’il met à jour. Chaque couche prouve ce que les autres ne peuvent pas, et un résultat vert à une couche ne prouve rien pour la suivante. Les couches message et endpoint décident si Google et Yahoo jugent l’e-mail conforme.

• DNS : vérifiez que les enregistrements DMARC et DKIM du domaine se résolvent via le DNS faisant autorité et un résolveur public. Cela valide le DNS publié, pas le comportement d’un message livré.
• Fournisseur : vérifiez la configuration actuelle d’authentification et de désabonnement de la plateforme. Un statut vert ne prouve pas que le chemin de production ajoute les en-têtes.
• Message : envoyez un vrai message de test par le chemin de production exact et inspectez ses en-têtes bruts. Vérifiez que List-Unsubscribe contient une URI HTTPS, que List-Unsubscribe-Post porte la valeur fixe exacte et qu’une signature DKIM valide inclut les deux champs dans sa liste h=. Vérifiez le lien visible dans le corps rendu.
• Endpoint et suppression : avec un destinataire de test sûr, envoyez le POST fixe en multipart/form-data puis en application/x-www-form-urlencoded. Vérifiez que l’endpoint aboutit sans cookie, connexion, en-tête d’autorisation, redirection ni dépendance au navigateur, puis contrôlez la suppression dans la liste de référence et que le prochain envoi concerné exclut ce destinataire.

Un test de désabonnement réussi prouve le chemin testé. Il ne prouve pas que chaque message futur, système de réception ou interface de messagerie se comportera de même.

Vérifiez la posture d’expéditeur autour du désabonnement

Le désabonnement en un clic n’est qu’une attente de fournisseur parmi d’autres. Le même flux couvert exige aussi authentification, alignement, sécurité du transport et maîtrise du taux de spam. Utilisez le score de sécurité e-mail pour voir l’authentification publique du domaine, et le guide des exigences Gmail pour suivre le reste de la politique de Google.

Le score ne peut pas vérifier un en-tête list-unsubscribe, tester un endpoint de désabonnement, suivre les changements futurs d’expéditeurs ni prouver où Gmail ou Yahoo placera un message.