Vos e-mails sortants sont-ils rejetés avec des codes d'erreur 550 ? Vos destinataires signalent-ils que vos messages arrivent dans les dossiers indésirables plutôt que dans leur boîte de réception ? Il y a une raison claire. En février 2024, Google et Yahoo ont cessé de considérer l'authentification des e-mails comme optionnelle — c'est désormais une exigence stricte. Pour toute entreprise qui dépend de l'e-mail, ignorer ces changements nuira à la délivrabilité et, avec elle, aux revenus.

Points clés :

• Google et Yahoo exigent que les expéditeurs en masse authentifient leurs e-mails sortants avec SPF et DKIM et publient un enregistrement DMARC.
• Le seuil de 5 000 messages/jour pour les expéditeurs en masse couvre tout le trafic combiné de votre domaine principal.
• Les taux de plaintes pour spam dans Google Postmaster Tools doivent rester sous 0,1 % ; atteindre 0,3 % déclenche des pénalités automatiques de délivrabilité sur les passerelles de réception.
• Les e-mails marketing et d'abonnement doivent prendre en charge les en-têtes de désinscription en un clic RFC 8058.
• Commencer avec p=none satisfait la conformité de base, mais passer à p=quarantine ou p=reject est important pour prévenir l'usurpation de domaine et bâtir une réputation de domaine durable.

Ce qui a changé et pourquoi : les règles d'expédition Gmail/Yahoo

Pourquoi ces règles existent-elles ? La cause profonde réside dans la conception même de l'e-mail. Le protocole SMTP (Simple Mail Transfer Protocol), normalisé en 1982 via la RFC 821, ne disposait d'aucun mécanisme natif pour vérifier l'identité de l'expéditeur. N'importe quel serveur de messagerie pouvait transmettre un message prétendant provenir de n'importe quelle adresse, et les passerelles de réception l'acceptaient — n'importe qui pouvait donc usurper un nom de domaine dans l'en-tête visible, avec peu d'effort.

Les ingénieurs en sécurité ont corrigé cette faille structurelle au fil des années. SPF est apparu au milieu des années 2000 pour valider les adresses IP d'envoi par rapport à une liste DNS publique. DKIM a suivi, en utilisant la cryptographie à clé publique pour permettre aux expéditeurs de signer les en-têtes sortants. En 2012, les principaux acteurs de l'industrie ont publié DMARC afin de relier les vérifications SPF et DKIM et de donner aux propriétaires de domaines un moyen de définir des politiques d'application.

Pendant des années, les fournisseurs de boîtes de réception ont traité ces normes comme optionnelles. Les domaines dotés de SPF et DKIM gagnaient des points bonus ; ceux qui en étaient dépourvus atteignaient généralement la boîte de réception, à condition que l'adresse IP soit propre.

Cela a pris fin en février 2024. Comme l'établissent les consignes de Google pour les expéditeurs d'e-mails, les fournisseurs de boîtes de réception sont passés d'une authentification simplement recommandée à une exigence d'accès stricte.

Plutôt que de bloquer d'un coup tout le courrier non authentifié, les fournisseurs ont déployé l'application par phases. Début 2024, ils ont commencé par ralentir les vitesses de connexion et renvoyer des codes de report temporaires 4xx sur les flux non authentifiés. Au cours des mois suivants, ils sont passés à des codes de rejet stricts 5xx et à un classement automatique en spam. Microsoft a rapidement aligné ses filtres de passerelle sur les mêmes normes pour les expéditeurs à fort volume, et a depuis annoncé qu'Outlook.com appliquera des exigences SPF, DKIM et DMARC comparables aux expéditeurs en masse en 2025 — signe que ces règles deviennent un socle commun à toute l'industrie et non une simple politique de Google et Yahoo.

Qui compte comme expéditeur en masse selon les consignes Gmail

Google définit un expéditeur en masse comme tout domaine envoyant environ 5 000 messages ou plus sur une fenêtre de 24 heures vers des comptes Gmail personnels ; Yahoo applique une norme similaire. Mais se concentrer uniquement sur ce chiffre est une erreur courante.

D'abord, le volume est calculé sur l'ensemble du domaine racine, et non par adresse IP ou nom d'hôte de serveur. Si une plateforme marketing envoie 3 500 newsletters tandis qu'un serveur applicatif envoie 2 000 réinitialisations de mot de passe ou reçus de facture sous le même domaine, le seuil est franchi.

Ensuite, la règle s'applique à tout le courrier sortant, pas seulement au marketing. Les notifications système, les reçus clients et les e-mails professionnels quotidiens comptent tous dans la limite journalière. Tout domaine envoyant près de 3 000 messages par jour devrait mettre en place une authentification complète, comme s'il avait déjà dépassé la limite.

Les exigences essentielles pour les expéditeurs d'e-mails

Pour satisfaire aux exigences d'envoi en masse de Google et Yahoo, l'infrastructure e-mail doit passer six vérifications techniques :

1. Mettre en place des enregistrements SPF valides et des paires de clés DKIM pour tous les flux de courrier sortant.
2. Publier un enregistrement DMARC TXT valide dans le DNS du domaine.
3. S'assurer que le domaine de l'en-tête visible « From: » correspond au domaine authentifié par SPF ou DKIM.
4. Maintenir les taux de plaintes pour spam sous 0,1 % dans Google Postmaster Tools, sans jamais atteindre 0,3 %.
5. Inclure des en-têtes natifs de désinscription en un clic sur tous les e-mails marketing et newsletters.
6. S'assurer que les IP des serveurs d'envoi disposent d'enregistrements A/AAAA correspondants et d'un DNS inverse (PTR) valide.

Ce qui se passe en cas de non-conformité

L'échec des vérifications d'authentification nuit à la réputation du domaine auprès des serveurs de réception, généralement en trois étapes :

1. Les serveurs de réception répondent par des codes de report 4xx ; les files d'attente se remplissent et la livraison est retardée de plusieurs heures.
2. Les messages passent la passerelle mais sont redirigés vers les dossiers de spam des destinataires au lieu de la boîte de réception principale.
3. Les serveurs de messagerie coupent entièrement la connexion et renvoient des erreurs de rejet définitif 5xx.

Comment satisfaire chaque exigence : pas à pas

1. Configurer SPF et surveiller la limite des 10 requêtes

Ajoutez un enregistrement DNS TXT à la racine du domaine listant chaque adresse IP autorisée et chaque fournisseur de messagerie tiers. Attention à la limite de 10 requêtes DNS : la RFC de SPF plafonne les enregistrements à 10 requêtes DNS externes (include, a, mx, redirect). La dépasser provoque une SPF PermError, que les serveurs de réception traitent comme un échec d'authentification. Auditez régulièrement l'enregistrement et supprimez les includes de fournisseurs obsolètes pour rester sous la limite.

2. Mettre en place la signature DKIM sur tous les canaux sortants

DKIM signe les en-têtes des e-mails sortants avec une signature cryptographique et doit être activé pour chaque plateforme envoyant du courrier au nom du domaine. Générez une paire de clés DKIM de 2048 bits dans le portail de votre service e-mail et publiez la clé publique sous forme d'enregistrement CNAME ou TXT dans le DNS. Une fois le DNS propagé, activez la signature dans la console d'administration et inspectez les en-têtes bruts d'un e-mail de test pour confirmer que l'en-tête DKIM-Signature est présent et valide.

3. Publier un enregistrement DMARC

Pour satisfaire l'exigence DMARC de base imposée par Gmail et Yahoo, publiez un enregistrement DMARC TXT à _dmarc.yourdomain.com. Pour une première configuration, commencez par une politique de surveillance (p=none) afin de collecter des données de rapport sans risquer la livraison. Avant la mise en production, testez l'entrée DNS avec un vérificateur d'enregistrement DMARC public pour détecter les erreurs de syntaxe.

4. Ajouter les en-têtes de désinscription en un clic RFC 8058

Un simple lien de désinscription HTML en bas d'un e-mail ne suffit pas pour le courrier marketing. Deux en-têtes bruts doivent être injectés dans le flux sortant :

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

Lorsque des clients comme Gmail ou Yahoo analysent ces en-têtes, ils affichent un bouton « Se désabonner » bien visible à côté du nom de l'expéditeur dans l'interface. Un clic déclenche une requête POST automatisée vers le serveur, retirant immédiatement l'abonné sans ouvrir de fenêtre de navigateur.

5. Vérifier le DNS direct et inverse

Les serveurs de réception vérifient que l'adresse IP d'envoi correspond au domaine dans le DNS. L'IP doit résoudre vers un nom d'hôte valide via un enregistrement PTR, et ce nom d'hôte doit résoudre vers la même IP via un enregistrement DNS A standard. Les opérateurs de serveurs de messagerie dédiés ou d'instances cloud peuvent modifier les paramètres de DNS inverse dans la console de leur fournisseur ou ouvrir un ticket pour associer l'IP au nom de domaine pleinement qualifié (FQDN) du serveur de messagerie.

6. Suivre les métriques dans Postmaster Tools et les rapports DMARC

Créez un compte Google Postmaster Tools et vérifiez la propriété du domaine via un enregistrement DNS TXT. Le tableau de bord offre une visibilité directe sur la réputation du domaine, les taux de plaintes pour spam et les taux de réussite d'authentification. Gardez le taux de plaintes sous 0,1 % ; atteindre 0,3 % amène Google à router le courrier vers les dossiers de spam, indépendamment du statut SPF et DKIM. Pour surveiller les échecs d'authentification chez tous les fournisseurs de réception et détecter les IP d'envoi malveillantes, mettez en place la génération de rapports DMARC automatisée.

Au-delà de la conformité : utiliser les règles pour améliorer la délivrabilité

Une politique p=none seule laisse le domaine sans protection contre l'usurpation — elle indique aux serveurs de réception d'enregistrer les données d'authentification, mais n'empêche pas les attaquants d'usurper le domaine lors de campagnes de phishing.

Une fois que tous les flux légitimes passent l'alignement SPF et DKIM, passez la politique DMARC à p=quarantine ou p=reject. p=quarantine envoie le courrier non authentifié directement en spam, tandis que p=reject rejette les faux messages dès la passerelle de réception.

Après avoir atteint l'application DMARC, les expéditeurs peuvent publier BIMI (Brand Indicators for Message Identification), qui affiche un logo de marque vérifié à côté des messages dans les boîtes de réception, renforçant visibilité et confiance.

Questions fréquentes sur les exigences pour les expéditeurs en masse

Quel est le seuil d'expéditeur en masse pour Google et Yahoo ?

Google et Yahoo définissent les expéditeurs en masse comme des domaines envoyant ~5 000 messages ou plus par jour vers des comptes personnels. Le volume est calculé sur l'ensemble du domaine principal, tous services d'envoi confondus.

Ces règles s'appliquent-elles aussi aux e-mails transactionnels ?

Oui. Les e-mails transactionnels tels que les réinitialisations de mot de passe, les mises à jour de commande et les alertes système doivent passer les vérifications SPF, DKIM, DMARC et DNS, mais ne nécessitent pas d'en-têtes de désinscription en un clic.

Une politique DMARC p=none suffit-elle pour être conforme ?

Oui, p=none satisfait les exigences de base de Google et Yahoo. Toutefois, elle ne fait que surveiller le trafic sans bloquer l'usurpation d'identité ; il est donc recommandé de passer à p=quarantine ou p=reject.

Qu'arrive-t-il à mes e-mails si je ne respecte pas les exigences ?

Les fournisseurs de messagerie limiteront vos connexions SMTP avec des codes d'erreur 4xx, routeront vos e-mails directement vers les dossiers de spam ou émettront des rejets définitifs 5xx refusant le courrier.

Combien de temps faut-il pour se remettre d'un taux de plaintes élevé ?

Une fois l'hygiène des listes corrigée et le taux de plaintes revenu sous 0,1 %, il faut généralement 7 à 14 jours d'envoi propre pour que Google Postmaster Tools reconstruise la réputation du domaine.

Comment vérifier si mon enregistrement SPF dépasse la limite des 10 requêtes ?

Inspectez l'enregistrement SPF TXT et comptez chaque mécanisme déclenchant une requête DNS. Si le nombre total de requêtes DNS, entre l'enregistrement principal et les enregistrements imbriqués, dépasse 10, l'enregistrement SPF échouera avec une PermError.

Source : FinTechZoom