Exigences de Gmail et Yahoo pour les expéditeurs : ce qui a changé en 2024 et ce qu'il faut vérifier
Depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur qu'il authentifie ses e-mails, et ils imposent des règles plus strictes aux expéditeurs en masse : SPF et DKIM, un enregistrement DMARC publié, un domaine From aligné sur SPF ou DKIM, le désabonnement en un clic pour les e-mails marketing et un faible taux de plaintes pour spam. Les messages qui ne respectent pas ces exigences peuvent être retardés, classés en spam ou rejetés.
Ces règles s'appliquent à toute personne qui écrit à des adresses personnelles Gmail et Yahoo, ce qui représente pour la plupart des entreprises une grande part de leurs clients. Les factures, réinitialisations de mot de passe et confirmations de commande sont concernées tout autant que les newsletters.
Voici ce que chaque fournisseur exige réellement, avec des liens vers sa propre documentation, puis les vérifications que vous pouvez faire vous-même.
Ce qu'exige Gmail
Les consignes pour les expéditeurs de Google sont entrées en vigueur en février 2024. Pour tous les expéditeurs vers des comptes Gmail personnels :
- Authentification SPF ou DKIM pour le domaine d'envoi.
- Des enregistrements DNS directs et inverses (PTR) valides pour les IP d'envoi.
- Une connexion TLS pour la transmission des e-mails.
- Un taux de spam signalé dans Postmaster Tools inférieur à 0,3 %.
- Des messages formatés selon la RFC 5322.
Pour les expéditeurs de 5 000 messages ou plus par jour, Google ajoute :
- SPF et DKIM, les deux.
- Un enregistrement DMARC pour le domaine d'envoi (la politique peut être
p=none). - Un domaine From aligné sur le domaine SPF ou sur le domaine DKIM.
- Le désabonnement en un clic pour les messages marketing et les abonnements, plus un lien de désabonnement visible dans le corps du message.
La FAQ des consignes pour les expéditeurs de Google apporte 3 précisions importantes en pratique. Les messages issus d'un même domaine principal sont comptés ensemble pour le seuil de 5 000. Un expéditeur qui le franchit une seule fois est définitivement considéré comme expéditeur en masse. Et à partir de novembre 2025, Gmail a renforcé l'application des règles, les messages non conformes s'exposant à des rejets temporaires et définitifs.
Ce qu'exige Yahoo
Les bonnes pratiques pour les expéditeurs de Yahoo sont elles aussi entrées en vigueur en février 2024. Pour tous les expéditeurs : SPF ou DKIM, un taux de spam inférieur à 0,3 %, des DNS directs et inverses valides, et le respect des RFC 5321 et RFC 5322.
Pour les expéditeurs en masse, Yahoo exige :
- SPF et DKIM, les deux.
- Une politique DMARC valide, au minimum
p=none, et DMARC doit réussir. - Un domaine From aligné sur le domaine SPF ou DKIM (l'alignement souple est accepté).
- Un en-tête List-Unsubscribe fonctionnel prenant en charge le désabonnement en un clic. Yahoo recommande vivement la méthode POST de la RFC 8058.
- Des désabonnements pris en compte sous 2 jours.
Contrairement à Google, Yahoo ne publie pas de nombre fixe de messages qui fait de vous un expéditeur en masse : il est donc raisonnable de respecter les exigences correspondantes dès que vous envoyez des e-mails marketing.
Là où les entreprises pèchent souvent
DKIM uniquement sur la messagerie principale. Vos e-mails de bureau sont signés, mais le CRM, l'outil de newsletter ou le logiciel de facturation envoie des messages non signés ou signés avec le domaine de l'éditeur de l'outil, ce qui casse l'alignement.
Un SPF qui réussit pour le mauvais domaine. Beaucoup de services d'envoi utilisent leur propre domaine de retour, si bien que SPF réussit pour bounces.vendor.net et non pour votre domaine. Sans DKIM aligné, DMARC échoue alors.
Aucun enregistrement DMARC. Même p=none est exigé des expéditeurs en masse par les deux fournisseurs. Notre guide SPF, DKIM et DMARC explique le format de l'enregistrement.
Un désabonnement limité à un lien. Le désabonnement en un clic suppose des en-têtes que le fournisseur de messagerie peut traiter directement, pas seulement un lien en pied de message.
Des listes anciennes. Écrire à des adresses qui n'ont jamais donné leur accord fait grimper les plaintes pour spam, et le plafond de 0,3 % est bas.
Comment vérifier votre domaine
Commencez par le DNS :
dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
Envoyez ensuite un message depuis chaque système qui écrit à vos clients (messagerie de bureau, CRM, newsletter, facturation, support) vers une adresse Gmail que vous contrôlez. Dans Gmail, ouvrez le message, choisissez « Afficher l'original » et cherchez :
SPF: PASS with domain yourcompany.com
DKIM: PASS with domain yourcompany.com
DMARC: PASS
Le domaine indiqué pour SPF ou DKIM doit correspondre à votre domaine From. Pour les e-mails marketing, la source originale doit contenir les 2 en-têtes nécessaires au désabonnement en un clic :
List-Unsubscribe: <https://yourcompany.com/unsubscribe?id=...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Enfin, enregistrez votre domaine dans Google Postmaster Tools pour voir le taux de spam que Google mesure pour vous.
Une courte liste de contrôle
- SPF publié et réussi pour votre domaine.
- Signature DKIM avec votre propre domaine dans chaque système d'envoi.
- DMARC publié, au minimum
p=none, avec des rapports lus régulièrement. - Domaine From aligné sur SPF ou DKIM dans chaque système.
- En-têtes de désabonnement en un clic sur les e-mails marketing, demandes traitées sous 2 jours.
- Taux de spam suivi dans Postmaster Tools et maintenu bien en dessous de 0,3 %.
- Enregistrements PTR valides pour toute IP depuis laquelle vous envoyez directement.
Microsoft a introduit des règles similaires pour Outlook.com en 2025, présentées dans les exigences d'Outlook pour les expéditeurs et le rejet 550 5.7.515.
Comment Datahorses vous aide
L'authentification des e-mails fait partie de ce que Datahorses surveille depuis l'extérieur chaque jour. Si votre enregistrement SPF change, si une clé DKIM disparaît, si DMARC est affaibli ou si votre domaine se retrouve sur une liste de blocage, une personne l'examine et vous recevez des étapes précises pour votre développeur. Consultez ce que nous surveillons pour la liste complète, ou demandez une proposition si vous souhaitez que vos domaines soient couverts.
Plus d’articles
Ports de bases de données exposés : MySQL, PostgreSQL, MongoDB, Redis et Elasticsearch
Les bases de données sont faites pour dialoguer avec votre application, pas avec tout Internet. Voici comment savoir si la vôtre est joignable de l'extérieur et comment la fermer.
Les en-têtes de sécurité HTTP que tout site d'entreprise devrait envoyer
Quelques lignes dans la réponse de votre serveur imposent HTTPS, bloquent l'intégration dans des frames et limitent les scripts. Voici les en-têtes utiles et comment les vérifier.
PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre
Le projet PHP a corrigé 2 failles critiques le 21 octobre 2026. Voici les versions qui contiennent le correctif, comment voir ce qu'annonce votre serveur et quoi demander à votre hébergeur.