Délivrabilité
SPF, DKIM, DMARC : les règles de Gmail, Yahoo et Outlook
SPF, DKIM et DMARC expliqués simplement, l'alignement, les exigences de Gmail, Yahoo et Outlook, et les étapes pour arriver en boîte de réception.
Par l’équipe MAYL6 min de lecture
L’essentiel
- SPF dit quels serveurs peuvent envoyer pour votre domaine, DKIM signe chaque message, DMARC dit quoi faire en cas d'échec.
- DMARC n'est satisfait que si le domaine visible dans « De » est aligné avec SPF ou DKIM.
- Depuis février 2024, Gmail et Yahoo exigent SPF, DKIM et DMARC des expéditeurs en volume, plus une désinscription en un clic.
- Microsoft a annoncé des exigences comparables pour Outlook.com à partir de mai 2025, au-delà de 5 000 emails par jour.
- Commencez DMARC en p=none, lisez les rapports, puis durcissez la politique par étapes.
Pour qu'un email arrive en boîte de réception, votre domaine doit prouver qu'il en est bien l'expéditeur. C'est le rôle de trois enregistrements DNS : SPF liste les serveurs autorisés à envoyer, DKIM signe chaque message, DMARC vérifie que ces preuves correspondent à l'adresse affichée et indique au destinataire quoi faire en cas d'échec. Gmail, Yahoo et Outlook exigent désormais ces protocoles des expéditeurs en volume, et les prennent en compte pour tous les autres.
Pourquoi l'authentification décide de la délivrabilité
Le protocole SMTP, qui transporte les emails, a été conçu sans vérification de l'expéditeur : n'importe quel serveur peut écrire n'importe quelle adresse dans le champ « De ». C'est ce qui rend l'hameçonnage et l'usurpation d'identité si faciles. Les messageries ont donc ajouté des couches de contrôle, et un message qui ne peut pas prouver son origine est traité avec méfiance : classé en indésirables, ou refusé.
L'authentification ne garantit pas la boîte de réception. Les filtres regardent aussi la réputation du domaine et de l'adresse IP, le contenu, les plaintes et l'engagement des destinataires. Mais sans elle, le reste ne compte presque plus : c'est la condition d'entrée.
SPF, DKIM et DMARC : que fait chaque protocole ?
SPF : la liste des serveurs autorisés
SPF (Sender Policy Framework) est un enregistrement TXT publié sur votre domaine. Il énumère les serveurs et services habilités à envoyer en son nom, par exemple votre messagerie Google Workspace ou Microsoft 365 et votre outil d'emailing. Le serveur qui reçoit le message compare l'adresse IP d'envoi à cette liste.
Un seul enregistrement SPF par domaine : deux enregistrements font échouer la vérification.
La norme limite l'évaluation à 10 requêtes DNS (chaque include en consomme au moins une).
La fin de l'enregistrement fixe la règle : ~all pour un échec « doux », -all pour un refus net.
Point important : SPF vérifie le domaine de l'enveloppe technique (le « Return-Path »), pas celui que lit votre destinataire. Et il casse souvent lors d'un transfert automatique, puisque le message repart d'un autre serveur.
DKIM : une signature sur chaque message
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique dans l'en-tête de chaque email. Le serveur d'envoi signe avec une clé privée, et la clé publique correspondante est publiée dans votre DNS, sous un « sélecteur » (du type selecteur._domainkey.votredomaine.fr). Le destinataire vérifie ainsi que le message vient d'un serveur autorisé et qu'il n'a pas été modifié en route. Contrairement à SPF, DKIM résiste en général au transfert, tant que le contenu n'est pas altéré. Une clé de 2 048 bits est aujourd'hui la recommandation courante.
DMARC : la politique et les rapports
DMARC (Domain-based Message Authentication, Reporting and Conformance) se publie dans un enregistrement TXT sur _dmarc.votredomaine.fr. Il fait deux choses. D'abord, il fixe une politique pour les messages qui échouent : p=none (ne rien faire, observer), p=quarantine (placer en indésirables) ou p=reject (refuser). Ensuite, grâce à la balise rua, il vous fait recevoir des rapports agrégés qui montrent quels serveurs envoient au nom de votre domaine, et avec quel résultat.
L'alignement, la notion que tout le monde oublie
Un message peut réussir SPF et DKIM et pourtant échouer DMARC. La raison tient en un mot : l'alignement. DMARC exige que le domaine visible dans le champ « De » corresponde au domaine validé par SPF (celui du Return-Path) ou au domaine de la signature DKIM (la valeur d=). Il suffit que l'un des deux soit aligné et valide.
Exemple typique : un outil d'emailing envoie pour vous avec son propre domaine technique et sa propre signature. SPF et DKIM passent, mais pour le domaine du prestataire, pas le vôtre. Résultat : DMARC échoue. La solution consiste presque toujours à configurer un domaine d'envoi personnalisé et une signature DKIM à votre nom dans l'outil concerné. L'alignement est « relâché » par défaut : un sous-domaine comme news.votredomaine.fr est accepté pour votredomaine.fr.
Ce qu'exigent Gmail, Yahoo et Outlook
Google et Yahoo ont annoncé fin 2023 des règles communes, entrées en vigueur à partir de février 2024 et appliquées progressivement. Elles visent surtout les expéditeurs en volume, que Google définit comme ceux qui envoient près de 5 000 messages ou plus par jour vers des comptes Gmail personnels.
Authentifier les envois avec SPF et DKIM (tous les expéditeurs doivent au minimum utiliser l'un des deux).
Publier un enregistrement DMARC, avec au minimum p=none, et aligner le domaine du champ « De ».
Proposer dans les messages marketing une désinscription en un clic conforme au RFC 8058, et l'honorer sous 2 jours.
Maintenir un taux de plainte pour spam sous 0,3 %, mesuré par exemple dans Google Postmaster Tools.
Disposer d'un DNS inverse valide pour les IP d'envoi et transmettre les messages via une connexion TLS.
Microsoft a suivi pour ses messageries grand public (Outlook.com, Hotmail, Live) : des exigences annoncées pour mai 2025, visant les domaines qui envoient plus de 5 000 emails par jour. SPF et DKIM doivent passer, et DMARC doit être publié au minimum en p=none, aligné avec SPF ou DKIM. Les messages non conformes sont exposés au filtrage, puis au rejet.
Mettre en place SPF, DKIM et DMARC en 6 étapes
1Recensez tout ce qui envoie avec votre domaine : messagerie, CRM, outil d'emailing, facturation, formulaires du site, support client.
2Créez ou corrigez un enregistrement SPF unique qui inclut chacun de ces services, en surveillant la limite des 10 requêtes DNS.
3Activez DKIM dans chaque service (dans la console d'administration Google Workspace ou Microsoft 365, puis dans vos outils tiers) et publiez les clés fournies.
4Publiez DMARC en p=none avec une adresse rua pour recevoir les rapports.
5Lisez les rapports pendant quelques semaines : identifiez les sources légitimes non alignées et corrigez-les.
6Passez à p=quarantine, éventuellement avec un pourcentage progressif, puis à p=reject quand plus aucun envoi légitime n'échoue.
Pour vérifier le résultat, envoyez-vous un message vers une boîte Gmail et ouvrez « Afficher l'original » : le détail indique PASS ou FAIL pour SPF, DKIM et DMARC.
Les erreurs classiques qui envoient vos emails en spam
Deux enregistrements SPF sur le même domaine, souvent ajoutés par deux prestataires différents.
Un SPF qui dépasse 10 requêtes DNS à force d'include empilés.
Un outil d'emailing qui signe avec son propre domaine, d'où un échec d'alignement DMARC.
Un passage direct en p=reject sans avoir lu les rapports, qui bloque vos factures ou vos formulaires.
Un sous-domaine oublié, ou un domaine qui n'envoie jamais d'email et reste sans protection (publiez pour lui un SPF « v=spf1 -all » et un DMARC en p=reject).
Une adresse d'envoi « noreply » qui ne reçoit rien, alors que les réponses sont un signal d'engagement.
Email individuel et envoi de masse : deux mondes différents
Un email écrit à un client depuis votre messagerie professionnelle part de l'infrastructure de Google ou Microsoft, déjà bien réputée. Si votre domaine est correctement authentifié, ces messages individuels arrivent en général sans difficulté, et les règles sur la désinscription en un clic ne s'appliquent pas à une conversation.
Un envoi de masse est jugé autrement : volume, régularité, plaintes, taux d'erreur sur des adresses inexistantes. Une bonne pratique consiste à séparer les flux, par exemple un sous-domaine dédié au marketing, pour que la réputation d'une campagne ne pénalise pas vos échanges quotidiens. Si vous faites de la prospection, relisez aussi ce que permettent le RGPD et la CNIL, car la délivrabilité ne suffit pas à rendre un envoi légitime. Et pour les messages restés sans réponse, une relance bien construite vaut mieux que la multiplication des envois.
Et MAYL dans tout cela ?
MAYL se branche sur votre messagerie existante (Gmail, Outlook, Microsoft 365, Google Workspace, iCloud, Yahoo ou IMAP), ou travaille en autonomie avec sa propre boîte sur votre nom de domaine, pour trier vos emails, répondre dans votre style, programmer des relances, caler des rendez-vous et transférer les messages importants à votre équipe. Dans les deux cas, vos messages partent de votre propre domaine : c'est pourquoi un SPF, un DKIM et un DMARC bien configurés restent la base, avec ou sans agent email. Pour comprendre la place de ce type d'outil, voyez ce qu'est un agent email IA.
Questions fréquentes
Faut-il SPF, DKIM et DMARC si j'envoie peu d'emails ?
Oui. Les obligations les plus strictes de Gmail, Yahoo et Outlook visent les expéditeurs en volume, mais tous les filtres tiennent compte de l'authentification. Un domaine sans DKIM ni DMARC est aussi plus facile à usurper. La mise en place prend peu de temps et protège durablement votre domaine.
Quelle politique DMARC choisir pour commencer ?
Commencez par p=none avec une adresse de rapports (rua). Vous observez ainsi tous les services qui envoient en votre nom sans risquer de bloquer un flux légitime. Une fois les sources corrigées et alignées, passez à p=quarantine puis à p=reject.
Pourquoi mes emails échouent-ils DMARC alors que SPF et DKIM passent ?
C'est presque toujours un problème d'alignement : SPF ou DKIM sont validés pour le domaine d'un prestataire, pas pour celui qui apparaît dans le champ « De ». Configurez un domaine d'envoi personnalisé et une signature DKIM à votre nom dans l'outil concerné.