SPF, DKIM et DMARC sont les trois enregistrements DNS qui prouvent qu'un message envoyé en votre nom vient bien de vous. Google et Yahoo les exigent depuis le 1er février 2024, avec un second niveau d'obligations au-delà de 5 000 messages par jour vers des adresses Gmail.
Point de situation
Ce que Google et Yahoo exigent : l'état des règles en 2026
Les exigences annoncées par Google et par Yahoo fin 2023 ne sont désormais plus un projet. Elles s'appliquent depuis le 1er février 2024, et leur mise en oeuvre s'est durcie depuis. Autrement dit, la question n'est plus de savoir si un domaine sera concerné ; il faut vérifier ce que sa zone DNS publie déjà.
Cependant, le sujet reste mal compris parce qu'il mélange deux régimes distincts. Tout expéditeur doit en effet respecter un socle minimal, y compris celui qui envoie dix messages par jour. Ensuite, un second niveau d'exigences s'ajoute au-delà d'un seuil de volume précis, que Google publie et que Yahoo refuse de chiffrer.
Le socle qui s'applique à tous les expéditeurs, quel que soit le volume
Google demande donc quatre choses à tout le monde : d'abord une authentification SPF ou DKIM sur les domaines d'envoi, ensuite des enregistrements DNS direct et inverse valides, puis une connexion TLS pour le transport, enfin un formatage des messages conforme à la norme RFC 5322.
De même, un taux de plainte pour spam inférieur à 0,3 % dans Postmaster Tools appartient à ce socle. Ce niveau de base ne réclame néanmoins ni enregistrement DMARC, ni désabonnement en un clic. C'est effectivement la première nuance que beaucoup d'articles écrasent.
Le second régime, réservé aux seuls expéditeurs en nombre
Au-delà de 5 000 messages par jour vers des adresses Gmail, Google exige alors SPF et DKIM ensemble, un enregistrement DMARC, un alignement du domaine et un désabonnement en un clic sur les messages marketing et les messages d'abonnement.
Par ailleurs, Yahoo publie une liste voisine mais ne fixe aucun seuil chiffré. Sa formulation est explicite, puisque l'opérateur annonce qu'il ne précisera pas de seuil de volume. En conséquence, un domaine prudent traite les exigences renforcées comme applicables, sans attendre de franchir une limite.
Premier pilier
Le SPF : la liste des serveurs autorisés à écrire
Le Sender Policy Framework reste à ce jour le plus ancien des trois mécanismes. Il consiste en un enregistrement TXT publié dans la zone DNS du domaine, lequel énumère les serveurs autorisés à émettre du courrier au nom de ce domaine. Le serveur destinataire compare enfin l'adresse IP émettrice à cette liste.
Toutefois, le SPF ne vérifie pas l'adresse affichée au lecteur. Il contrôle plutôt l'enveloppe technique du message, celle que Google appelle le domaine SPF. Un message peut ainsi passer le SPF tout en affichant une adresse d'expéditeur différente, ce qui explique pourquoi ce protocole ne suffit plus seul. Pour comprendre la mécanique de résolution qui porte tout cela, l'article sur le fonctionnement des serveurs DNS pose notamment les bases.
Ce qu'un enregistrement SPF contient réellement, et ce qu'il ignore
Un enregistrement SPF se lit de gauche à droite : d'abord la version, ensuite les mécanismes qui autorisent des adresses IP ou des domaines tiers, enfin un qualificateur qui dit quoi faire du reste. La forme courante ressemble en général à v=spf1 include:exemple.com -all.
Ce qualificateur final compte davantage que tout le reste. Ainsi, -all refuse tout serveur non listé, tandis que ~all se contente de signaler un échec doux. Néanmoins, un enregistrement trop permissif vide le mécanisme de sa portée, et un enregistrement trop strict coupe les envois légitimes le jour où une plateforme change d'infrastructure.
La limite technique que presque personne ne surveille pourtant
Le SPF autorise au maximum dix résolutions DNS par évaluation. Chaque directive d'inclusion en consomme une, et une plateforme d'emailing en consomme souvent plusieurs à elle seule. Au-delà, la vérification retourne alors une erreur permanente, et le message est traité comme non authentifié.
De ce fait, un domaine qui cumule un hébergeur, une messagerie professionnelle, un outil de facturation et une plateforme de newsletter et emailing marketing dépasse la limite sans le savoir. Un contrôle annuel de cet enregistrement appartient en outre aux tâches de monitoring et maintenance qui évitent une panne silencieuse.
Deuxième pilier
Le DKIM : la signature qui scelle le message
Le DomainKeys Identified Mail ajoute quant à lui une signature cryptographique à chaque message sortant. Le serveur d'envoi signe une partie des en-têtes et du corps avec une clé privée. Puis le serveur destinataire récupère la clé publique correspondante dans le DNS du domaine et vérifie la signature.
Cette signature apporte deux garanties que le SPF ne donne pas. D'abord, elle prouve que le message provient bien d'un système détenant la clé du domaine. Ensuite, elle prouve que le contenu signé n'a pas été altéré pendant le transport, ce qui survit notamment aux relais et aux redirections.
La longueur de clé exigée, et celle qui reste seulement recommandée
Yahoo impose une clé DKIM d'au moins 1 024 bits et recommande 2 048 bits. Cette exigence figure effectivement noir sur blanc dans ses règles pour expéditeurs. Une clé plus courte fait par conséquent échouer la vérification, même si la signature est par ailleurs correcte.
En revanche, Google ne publie pas de longueur minimale dans ses propres règles. Il demande la signature, mais pas une taille de clé. Puisque les deux opérateurs reçoivent souvent le même envoi, la règle la plus stricte s'impose en pratique, à savoir signer en 2 048 bits et ne plus s'interroger.
Les sélecteurs multiples, désormais le cas courant en entreprise
Un domaine peut publier plusieurs clés DKIM en parallèle, à savoir une par sélecteur. Cette possibilité devient essentielle lorsque la messagerie interne, la plateforme de newsletter et l'outil de support envoient tous sous le même domaine.
Cela dit, chaque plateforme doit disposer de sa propre clé et signer réellement. Une plateforme non configurée envoie alors des messages non signés, qui échoueront à l'alignement DMARC décrit plus bas. Un audit et conseils sur la zone DNS met du reste ces oublis en évidence en quelques minutes.
Troisième pilier
Le DMARC : la politique et l'alignement du domaine
Le DMARC ne remplace ni le SPF ni le DKIM, car il les chapeaute. Son enregistrement est un TXT publié sur un sous-domaine technique réservé, lequel déclare la politique à appliquer aux messages en échec, ainsi que l'adresse de réception des rapports.
Sa forme minimale tient en deux paramètres, à savoir la version v=DMARC1 et la politique p=none. Google demande en effet un enregistrement DMARC pour les expéditeurs en nombre et précise que la politique peut rester à none. Yahoo demande également une politique valide d'au moins p=none. Ni l'un ni l'autre n'exige donc p=reject, contrairement à ce qui circule.
L'alignement, la notion qui fait échouer les domaines pourtant configurés
Google exige que le domaine du champ From soit aligné avec le domaine SPF ou avec le domaine DKIM. C'est effectivement la condition que les domaines oublient le plus souvent, car elle ne se voit pas dans un simple test de présence des enregistrements.
Un cas classique l'illustre. Une plateforme d'emailing signe en DKIM avec son propre domaine, alors que le message affiche l'adresse de l'entreprise. Les deux protocoles passent, mais l'alignement échoue, et le DMARC échoue avec lui. Par conséquent, il faut configurer un domaine d'envoi personnalisé chez la plateforme, ce qui reste presque toujours possible.
Pourquoi la politique stricte se pose en dernier, et jamais en premier
Passer directement à p=reject est la fausse bonne idée de ce dossier. Une politique de rejet posée avant l'inventaire de tous les émetteurs légitimes supprime en effet des messages de facturation, de formulaire ou de notification, et sans le moindre avertissement.
La séquence raisonnable commence plutôt par p=none avec collecte des rapports, se poursuit par p=quarantine une fois les émetteurs identifiés, et se termine éventuellement par p=reject. En somme, la politique stricte reste un objectif de fin de chantier. Cette progression rejoint d'ailleurs la logique de sécurité et conformité appliquée au reste du système d'information.
Champ couvert
Le seuil de 5 000 messages : qui bascule en expéditeur en nombre
Le chiffre de 5 000 messages par jour est publié par Google, car il conditionne le passage au régime renforcé. Il ne s'agit en réalité ni d'une moyenne mensuelle, ni d'un total tous destinataires confondus, mais des messages envoyés vers des comptes Gmail personnels sur une seule journée.
Deux précisions de la documentation de Google changent toutefois la portée de ce seuil. D'abord, le volume se compte par domaine principal, en agrégeant les sous-domaines. Ensuite, un expéditeur qui atteint ce seuil ne serait-ce qu'une fois est considéré de manière permanente comme un expéditeur en nombre.
Ce que cette règle de permanence implique donc concrètement
Un pic ponctuel suffit à faire basculer un domaine. Une campagne annuelle, une annonce de fermeture ou un envoi de factures groupé en fin d'exercice fixent alors le statut, et ce statut ne se perd pas si le volume retombe ensuite.
Effectivement, cette règle rend tout calcul d'évitement inutile. Un domaine qui adresse des campagnes à plusieurs milliers de contacts a tout intérêt à configurer le régime renforcé d'emblée, plutôt qu'à surveiller un compteur. Le coût de la configuration reste ponctuel, tandis que celui d'une campagne rejetée se répète.
Le cas des sous-domaines et des envois délégués à un tiers
L'agrégation par domaine principal a une conséquence directe : isoler les campagnes sur un sous-domaine ne met donc pas le domaine principal à l'abri du seuil. Les volumes s'additionnent en effet au niveau du domaine racine.
En revanche, un sous-domaine dédié reste utile pour une autre raison. Il cloisonne la réputation d'envoi, de sorte qu'une campagne mal reçue n'entraîne pas la messagerie interne avec elle. Cette séparation se décide notamment au moment de la migration de site internet ou de la mise en place de l'hébergement et de l'infogérance.
Seuils chiffrés
Taux de plainte et désabonnement : les deux chiffres qui décident
Deux valeurs chiffrées résument l'essentiel des sanctions, à savoir le taux de plainte pour spam et le délai de traitement d'une demande de désabonnement. Toutes deux sont également publiées et vérifiables.
Google demande de maintenir le taux de plainte sous 0,1 % et de ne jamais atteindre 0,3 %. Yahoo demande quant à lui de rester sous 0,3 %. Ces taux se mesurent d'ailleurs dans Postmaster Tools pour Gmail et dans les outils du Sender Hub pour Yahoo.
Ce que mesure exactement le taux de plainte, et ce qu'il ignore
Le taux de plainte compte les signalements manuels des destinataires, et non les messages classés en indésirables par le filtre. Un envoi peut ainsi finir massivement en dossier spam tout en affichant un taux de plainte flatteur, ce qui trompe beaucoup d'annonceurs.
D'ailleurs, ce taux se calcule par domaine d'envoi et non par campagne. Une seule opération agressive fait alors monter la moyenne du domaine pendant des semaines. Par conséquent, la qualité de la liste compte davantage que la créativité du message.
Le désabonnement en un clic, et son délai réel de traitement
Google impose le désabonnement en un clic sur les messages marketing et les messages d'abonnement des expéditeurs en nombre, avec les en-têtes décrits par les RFC 2369 et RFC 8058. Sa documentation précise en outre un traitement sous 48 heures.
Yahoo demande la même fonction et fixe un délai de 2 jours. Toutefois, cette exigence ne remplace pas le lien de désabonnement visible dans le corps du message, car les deux coexistent. Un lien enfoui en bas de page ne satisfait pas la règle, puisque le mécanisme attendu vit dans les en-têtes techniques.
Synthèse
Tableau de conformité : exigence par exigence
Le tableau ci-dessous reprend les exigences publiées par les deux opérateurs. Il ajoute en outre, pour chacune, le point qui fait échouer les domaines en pratique.
Exigence | Google | Yahoo | Point de vigilance |
|---|---|---|---|
SPF | Exigé seul ou avec DKIM, puis les deux au-delà de 5 000 messages par jour | Enregistrement valide toujours exigé | La limite de dix résolutions DNS casse en effet le mécanisme sans alerte |
DKIM | Exigé seul ou avec SPF, puis les deux au-delà du seuil | Clé de 1 024 bits au minimum, mais 2 048 recommandés | Une plateforme tierce non configurée envoie alors sans signature |
Enregistrement DMARC | Exigé au-delà de 5 000 messages par jour, la politique none restant néanmoins acceptée | Politique valide d'au moins p=none, car le DMARC doit passer | Poser p=reject trop tôt supprime ainsi des messages légitimes |
Alignement du domaine | Le champ From doit s'aligner sur le domaine SPF ou bien sur le domaine DKIM | Vérifié de même par la validation DMARC | Invisible pourtant dans un test de présence des enregistrements |
Désabonnement en un clic | Exigé au-delà du seuil, selon les RFC 2369 et RFC 8058, traitement sous 48 heures | Exigé sur les messages promotionnels, puis honoré sous 2 jours au plus | Le lien visible en bas de message ne suffit jamais, contrairement à une idée répandue |
Taux de plainte | Sous 0,1 % en cible, toutefois jamais 0,3 % | Sous 0,3 % également | Il ignore néanmoins les messages filtrés sans signalement manuel |
DNS inverse et TLS | DNS direct et inverse valides, et également le transport TLS | Enregistrement PTR valide, explicite et donc non générique | Un PTR générique d'hébergeur fait alors échouer le contrôle |
Chronologie
Ce qui a changé depuis février 2024 : de l'annonce à l'exécution
La date de février 2024 a beaucoup circulé, puis le sujet est retombé parce que rien de spectaculaire ne s'est produit dans les semaines suivantes. Cette accalmie a pourtant été mal interprétée, car les règles étaient bien en vigueur, mais leur application montait en charge progressivement.
Google indique désormais que son application se durcit depuis novembre 2025, et que les messages non conformes subissent des perturbations incluant des rejets temporaires et des rejets définitifs. Les codes d'erreur SMTP correspondants sont également publiés dans sa documentation.
La différence entre un rejet temporaire et un rejet définitif
Un rejet temporaire renvoie un code de la famille 4.7 et laisse en outre le serveur d'envoi retenter. Il se traduit par des retards, puis par un abandon si la situation persiste. Un rejet définitif renvoie en revanche un code de la famille 5.7 et supprime toute chance de livraison.
Cette distinction compte pour le diagnostic. Effectivement, une file d'attente qui gonfle sans erreur visible signale souvent un rejet temporaire en cours, autrement dit un problème d'authentification récent. Un dépannage de site internet commence ainsi fréquemment par la lecture de ces journaux.
Le calendrier réel, opérateur par opérateur
Trois dates structurent ce dossier : d'abord février 2024 pour l'entrée en vigueur chez Google et chez Yahoo, ensuite juin 2024 pour l'application du désabonnement en un clic annoncée par Yahoo, enfin novembre 2025 pour la montée en charge de l'application chez Google.
Aucune autre échéance n'est publiée à ce jour par ces deux opérateurs. Il n'existe pas de nouvelle date butoir à attendre, puisque la conformité se vérifie maintenant, sur l'état actuel de la zone DNS.
Méthode
Vérifier son domaine : outils, ordre et pièges
La vérification se fait en lecture seule, sans rien modifier, et prend quelques minutes. Elle porte en premier lieu sur la validité du SPF, en second lieu sur la présence d'au moins une clé DKIM active, enfin sur la présence de l'enregistrement DMARC et sur l'alignement constaté.
Plusieurs services publics permettent également ces contrôles. Ils consultent la zone DNS publique et n'ont par ailleurs besoin d'aucun accès au domaine. Le vocabulaire technique de ces outils est notamment rassemblé dans le lexique du webmaster freelance.
Les outils de contrôle des trois enregistrements
Pour le SPF, trois services suffisent. MXToolbox, Mimecast et EasyDMARC affichent ainsi l'enregistrement, le nombre de résolutions consommées et les erreurs de syntaxe.
Pour le DKIM et le DMARC, quatre autres prennent le relais. Dmarcian, EasyDMARC, MXToolbox et DMARC Advisor vérifient alors la présence des clés et la validité de la politique. Cela dit, aucun de ces outils ne mesure l'alignement à votre place, puisque seul l'examen d'un message reçu le montre.
L'ordre des opérations qui évite de couper les envois
L'ordre compte autant que le contenu des enregistrements. Il faut d'abord inventorier tous les systèmes qui envoient sous le domaine, ensuite les authentifier un par un, enfin poser le DMARC en p=none et lire les rapports pendant plusieurs semaines.
Le durcissement de la politique vient en dernier lieu, lorsque les rapports ne montrent plus d'émetteur légitime en échec. Néanmoins, cette phase d'observation est celle que les projets pressés suppriment, et c'est exactement celle qui évite la coupure. Un accompagnement en support utilisateur et gestion d'urgence sert en définitive surtout à tenir cette discipline.
Sur le terrain
Cas d'usage
- Vérifier la zone DNS d'un domaine avant une première campagne d'emailing.
- Corriger un enregistrement SPF qui dépasse la limite de dix résolutions.
- Aligner le domaine d'envoi d'une plateforme de newsletter sur celui de l'entreprise.
- Faire passer une politique DMARC de l'observation au rejet sans couper les envois.
Vos questions
Questions fréquentes
Mon site WordPress envoie moins de cent messages par jour, suis-je donc concerné ?
Oui, mais par le socle seulement. Un domaine sous le seuil doit publier SPF ou DKIM, disposer de DNS direct et inverse valides, transporter en TLS et rester sous 0,3 % de plainte. Il n'a donc aucune obligation d'enregistrement DMARC ni de désabonnement en un clic du fait de Google.
Cela dit, la prudence commande de publier quand même les trois enregistrements. Un formulaire de contact, une boutique et toute création de site WordPress génèrent en effet des messages transactionnels dont la livraison dépend de la même réputation. Le coût de la configuration reste nul, tandis que celui d'une commande non confirmée ne l'est pas.
Faut-il obligatoirement passer la politique DMARC en rejet ?
Non. Google accepte explicitement une politique à none pour les expéditeurs en nombre, et Yahoo demande une politique valide d'au moins p=none. Aucun des deux opérateurs n'exige toutefois p=reject dans ses règles publiées.
En revanche, une politique à none ne protège pas contre l'usurpation de votre domaine, car elle se contente d'observer et de rapporter. Le rejet reste ainsi l'objectif à viser, comme aboutissement d'un chantier, jamais comme case à cocher.
Yahoo applique-t-il le même seuil de 5 000 messages par jour que Google ?
Non. Yahoo écrit précisément qu'il ne fixera pas de seuil de volume. Ses exigences sont de ce fait formulées sans plancher chiffré, ce qui les rend applicables à un envoi bien plus modeste que celui visé par Google.
Par conséquent, raisonner uniquement sur le chiffre de Google conduit à une conformité partielle. Un domaine qui vise les deux opérateurs applique plutôt le régime renforcé sans se référer à un compteur.
Mon prestataire d'emailing gère-t-il tout cela à ma place ?
En partie seulement. Une plateforme sérieuse signe en DKIM, gère les en-têtes de désabonnement et surveille également sa propre réputation. Elle ne peut pas, en revanche, modifier la zone DNS de votre domaine ni décider de votre politique DMARC.
De surcroît, la question décisive reste celle du domaine d'envoi. Tant que la plateforme signe avec son propre domaine plutôt qu'avec le vôtre, l'alignement échoue. Cette vérification revient au fond au responsable du domaine, jamais au prestataire seul.
Que se passe-t-il si mon domaine n'est pas conforme ?
Les messages ne sont pas tous bloqués du jour au lendemain. La dégradation est plutôt progressive, avec un classement en indésirables, des retards de livraison liés à des rejets temporaires de la famille 4.7, enfin des rejets définitifs de la famille 5.7 sur une partie du trafic.
Cette progressivité est précisément ce qui rend le problème difficile à détecter. Globalement, le symptôme apparaît côté destinataire avant d'apparaître côté expéditeur, et il est souvent signalé par un client plutôt que par un outil de supervision technique.
Ces règles concernent-elles aussi les messages internes de l'entreprise ?
Elles concernent avant tout les messages qui sortent vers des boîtes Gmail et Yahoo. Un échange strictement interne, qui ne quitte jamais le serveur de l'entreprise, n'est de fait pas évalué par ces opérateurs.
Néanmoins, la séparation est rarement aussi nette. Des collaborateurs relèvent en effet leur courrier professionnel sur une adresse personnelle, et des alertes automatiques partent vers des destinataires externes. Finalement, un domaine qui authentifie tout évite d'avoir à tracer cette frontière.
Existe-t-il une autre échéance à surveiller après novembre 2025 ?
Aucune date postérieure n'est publiée par Google ni par Yahoo dans leurs règles pour expéditeurs. Le calendrier connu s'arrête en effet à la montée en charge de l'application annoncée par Google pour novembre 2025.
Malgré tout, le sujet reste mouvant puisque d'autres opérateurs de messagerie alignent progressivement leurs propres exigences. Surveiller les pages officielles des deux opérateurs une fois par an suffit néanmoins à rester à jour.
Ressources liées
Aller plus loin
- Comprendre le fonctionnement des serveurs DNS : où vivent précisément les enregistrements SPF, DKIM et DMARC, et donc où les corriger
- Newsletter et emailing marketing : la mise en place des envois et notamment de leur authentification
- Hébergement et infogérance : la gestion de la zone DNS et également des enregistrements inverses
- Sécurité et conformité RGPD : le cadre dans lequel s'inscrit ensuite l'authentification des messages
- Webmaster expert WordPress : le périmètre d'intervention sur un site, puis sur sa messagerie
Passer à l'action
Conclusion
Le test à s'appliquer tient en une seule question. Si vous envoyiez demain 5 000 messages vers des adresses Gmail, votre domaine passerait-il le contrôle d'alignement ? Si la réponse n'est pas un oui documenté, la conformité n'est donc pas acquise, quel que soit le volume actuel.
Ces exigences ne sont en réalité ni une taxe ni une contrainte arbitraire. Elles rendent simplement vérifiable ce qui ne l'était pas, à savoir le fait qu'un message envoyé en votre nom vient bien de vous. Du reste, la grille tarifaire distingue clairement ce diagnostic du chantier de mise en conformité qui peut suivre.
Action réalisable aujourd'hui : lancez une recherche DMARC sur votre domaine avec MXToolbox et notez la politique retournée. Si aucun enregistrement n'apparaît, vous tenez votre première tâche.
Laisser un commentaire