Ce que les règles bulk sender de Gmail et Yahoo de février 2024 ont changé

Le 1er février 2024, Google et Yahoo ont simultanément imposé de nouvelles exigences à tout expéditeur dépassant 5 000 messages par jour vers leurs bases d'utilisateurs respectives. Les deux annonces restent les références canoniques — les « Email sender guidelines » de Google et les « Sender best practices » de Yahoo — et demeurent quasi identiques sur le fond. Les trois exigences :

1. Authentification. SPF et DKIM sont obligatoires ; DMARC au minimum en p=none est obligatoire. Le courrier non aligné part en spam ou est rejeté.
2. Désabonnement en un clic. L'en-tête List-Unsubscribe (RFC 2369, 1998) existait depuis longtemps ; ce que 2024 a ajouté, c'est l'exigence du un seul clic — l'URL de désabonnement doit accepter une unique requête POST et la traiter sans étape de confirmation (RFC 8058, 2017). L'utilisateur clique une fois dans son client de messagerie et il est désabonné.
3. Plafond de plaintes. Les expéditeurs bulk doivent maintenir leur taux de plaintes spam sous 0,3 % en permanence. Des taux durablement supérieurs déclenchent un déclassement automatique vers le dossier spam.

Avant 2024, la plupart des opérateurs auto-hébergés se contentaient de SPF + DKIM et zappaient DMARC. L'argument : DMARC n'est qu'une politique posée sur les deux autres, et recevoir les rapports en retour est opérationnellement pénible. Cet argument n'est plus tenable.

Concrètement, la règle de 2024 impose que DMARC existe — même en p=none — et qu'il s'aligne. « S'aligner » au sens DMARC signifie que soit le domaine From de SPF, soit le domaine de signature DKIM, correspond à l'en-tête From: visible, en mode strict ou relâché. Échec classique : un expéditeur utilise marketing@votreentreprise.com comme From visible mais route le tout via un CRM tiers qui signe DKIM avec le domaine du CRM — l'alignement échoue, DMARC échoue, et Gmail / Yahoo aiguillent le message vers le spam en silence.

La parade reste le déploiement DMARC standard : publier p=none avec rapports RUA, surveiller les agrégats quotidiens pendant deux à quatre semaines, identifier et corriger les flux non alignés, monter en p=quarantine, se fixer en p=reject. Il n'y a pas de raccourci.

Le seuil technique se résume à deux en-têtes, tous deux conformes RFC 8058 :

Le client de messagerie (Gmail, Yahoo, Apple Mail) affiche cela sous forme de lien « Se désabonner » en un clic dans l'en-tête du message. Lorsque l'utilisateur clique, le client envoie un POST List-Unsubscribe=One-Click vers l'URL. Votre serveur traite le désabonnement et renvoie 200 OK. Aucune page de confirmation, aucun captcha, aucun login.

AcelleMail émet les deux en-têtes par défaut pour toute liste de campagne où la gestion du désabonnement est activée. Là où les opérateurs trébuchent, ce sont les intégrations personnalisées — flux transactionnels qui contournent le moteur de campagne, relais SMTP tiers qui suppriment les en-têtes, ou URLs de désabonnement qui redirigent vers une page de confirmation du CMS. Chacun de ces cas est une perte de délivrabilité.

La vérification la plus simple : envoyez-vous un test, cliquez sur « Afficher l'original » dans Gmail, cherchez List-Unsubscribe-Post. Si l'en-tête est absent ou ne contient pas One-Click, vous n'êtes pas conforme. Corrigez avant que votre volume ne dépasse 5 000/jour chez l'un ou l'autre fournisseur.

Le taux de plaintes correspond au pourcentage de destinataires ayant marqué votre message comme spam, calculé par jour sur une fenêtre glissante. L'annonce de Google parlait de « sous 0,3 % » en régime durable, avec « nous voulons voir votre taux constamment sous 0,1 % » comme marge de travail.

Deux remarques d'implémentation :

1. C'est par domaine, pas par compte. Si vous isolez le marketing sur un sous-domaine (par exemple news.votreentreprise.com), le taux de plaintes est calculé contre ce seul sous-domaine. Un sous-domaine franchissant 0,3 % ne déclasse pas automatiquement votre trafic transactionnel sur le domaine apex, et c'est l'une des raisons pour lesquelles l'usage standard consiste à isoler le marketing sur un sous-domaine. (Voir /glossary/email-deliverability.)
2. Gmail et Yahoo mesurent différemment. Gmail utilise le taux de clic sur le bouton spam parmi les destinataires ayant ouvert. Yahoo applique une métrique similaire dans son interface. Les deux chiffres devraient se suivre à environ 0,05 % près ; de grands écarts signalent un biais d'audience plutôt qu'un problème d'expéditeur.

Pour la visibilité, inscrivez-vous à Google Postmaster Tools (gratuit, vérification DNS du domaine requise) et au Complaint Feedback Loop de Yahoo. Les deux exposent les taux de plaintes quotidiens. AcelleMail consomme le flux de plaintes au niveau SES via les webhooks SNS (app/SendingServers/Webhooks/ComplaintReceived.php), source de vérité au niveau serveur d'envoi. Les taux Gmail / Yahoo sont post-livraison ; le taux SES est à l'acceptation.

Stricto sensu, les règles de 2024 ne s'appliquent qu'aux expéditeurs bulk — au-delà de 5 000/jour vers Gmail ou Yahoo. Sous ce seuil, les exigences relèvent de la « bonne pratique » plutôt que d'une obligation.

En pratique, c'est sans portée. Les expéditeurs sous les 5 000 sont eux aussi mis en spam pour DMARC absent, désabonnement en un clic absent, ou taux de plaintes élevé. L'heuristique des fournisseurs est largement la même ; la différence est qu'au-delà de 5 000, les fournisseurs vous publient dans une file « bulk sender » soumise à une automatisation plus stricte, alors qu'en deçà vous tombez dans une voie de revue manuelle pilotée par l'engagement. Dans les deux cas, ignorer les règles sous 5 000 produit une perte de délivrabilité mesurable.

Le bon cadrage : les règles de 2024 ont codifié ce qui était déjà le seuil de fait chez les grands fournisseurs. Elles n'ont pas inventé de nouvelles exigences ; elles ont rendu les exigences existantes explicites et opposables. Les opérateurs auto-hébergés sous 5 000/jour devraient traiter ces règles comme leur seuil de travail, quoi qu'il arrive.

Trois schémas ont cassé à grande échelle en février-mars 2024 et provoquent encore aujourd'hui une perte de délivrabilité mesurable :

1. Échec DMARC sur retransmission. Les opérateurs de listes de diffusion qui retransmettaient le courrier vers les adresses personnelles des abonnés (le classique pattern « list service ») ont vu leur courrier retransmis rejeté en masse. La parade consiste à réécrire l'en-tête From sur le courrier retransmis (approche ARC) ou à basculer les listes vers un envoi direct depuis le domaine de la liste. Mailman 3 et le module liste de Postal le prennent en charge.
2. Expéditeurs via CRM tiers. Envoyer via un relais SMTP rattaché à un CRM qui signe avec le domaine du CRM casse l'alignement DMARC, sauf si le CRM publie aussi son propre DKIM sous votre sous-domaine. SES, Mailgun, SparkPost et SendGrid le supportent ; des relais plus anciens ou moins mainstream peuvent ne pas le faire.
3. Flux transactionnels non authentifiés. « On envoie les réinitialisations de mot de passe par Postfix sur la même machine que l'app, sans DKIM » a cessé de fonctionner à tout volume sérieux. La parade est de publier les clés DKIM pour le domaine apex et de configurer OpenDKIM sur l'installation Postfix — travail à faire une seule fois, qui paie sur l'ensemble du trafic transactionnel.

Les règles de 2024 se sont révélées plus structurantes qu'il n'y paraissait. Elles n'ont pas seulement relevé la barre — elles l'ont rendue concrète et testable. Sender Score, Talos, GlockApps, Postmark et les divers éditeurs de monitoring de délivrabilité ont tous intégré les trois piliers à leurs vérifications en l'espace de quelques mois. À la mi-2025, l'ensemble de l'écosystème commercial d'outils de délivrabilité tenait DMARC + désabonnement en un clic + taux de plaintes pour des préalables ; les anciens services du type « on vous aide à déboguer votre SPF » se sont mis à niveau ou ont disparu en silence.

Pour les opérateurs auto-hébergés en particulier, les règles de 2024 ont accéléré un basculement déjà en cours : quitter le « envoyer n'importe quoi depuis n'importe où » (norme auto-hébergée des années 2010) au profit de « n'envoyer que du courrier authentifié, aligné, facilement désabonnable, depuis un domaine dont vous gérez activement la réputation ». Le seuil opérationnel est plus haut, mais le régime stable est moins risqué. L'outillage de AcelleMail pour ce régime stable — WarmupStrategy, BounceHandler, liste de suppression, adaptateurs de vérification NeverBounce / ZeroBounce — était déjà dans le code avant 2024 ; ce qui a changé, c'est qu'il est devenu nécessaire et non plus optionnel.

Si vous n'avez pas mené d'audit de conformité aux règles de 2024 sur votre domaine d'envoi ces six derniers mois, c'est aujourd'hui un bon jour pour commencer. Version cinq minutes : envoyez-vous un test, « Afficher l'original » dans Gmail, vérifiez trois verdicts pass plus l'en-tête List-Unsubscribe-Post: List-Unsubscribe=One-Click. Si tout passe, vous êtes bon. Sinon, le chemin pour y arriver est bien balisé.