SPF, DKIM et DMARC : comment bloquer l'usurpation d'e-mail, étape par étape

En bref : SPF liste les serveurs autorisés à envoyer des e-mails pour votre domaine, DKIM signe chaque message, et DMARC vérifie que l'un des deux est valide pour le domaine de l'adresse d'expéditeur visible (From), puis indique aux destinataires quoi faire des messages qui échouent. Depuis février 2024, Gmail et Yahoo exigent SPF ou DKIM de tous les expéditeurs, et SPF, DKIM et DMARC des expéditeurs en masse ; Gmail durcit son application depuis novembre 2025. Publiez un seul enregistrement SPF, activez DKIM sur chaque service qui envoie pour vous, démarrez DMARC à p=none avec des rapports, puis passez à p=quarantine ou p=reject dès que vos e-mails légitimes passent.

L'e-mail a été conçu sans aucune preuve de l'identité de l'expéditeur. N'importe qui peut écrire billing@yourcompany.com dans le champ From, et sans enregistrements d'authentification, le serveur destinataire ne peut pas savoir que c'est un faux. C'est ainsi que fonctionnent la fraude à la facture et le phishing en votre nom, et c'est aussi pourquoi vos vrais e-mails peuvent paraître suspects aux yeux de Gmail.

SPF, DKIM et DMARC corrigent cela avec trois enregistrements DNS. Ce guide explique comment ils s'articulent, ce qu'exigent les grands fournisseurs de messagerie, comment notre vérificateur SPF et DMARC gratuit lit votre domaine, et comment passer de l'absence d'enregistrements à une politique appliquée sans casser vos propres envois.

Comment SPF, DKIM et DMARC fonctionnent ensemble

Le point faible de SPF et DKIM seuls se situe dans la ligne « domaine vérifié ». La RFC 7208 indique que SPF contrôle les identités MAIL FROM et HELO, que le destinataire ne voit jamais. Un usurpateur peut réussir SPF pour son propre domaine tout en affichant le vôtre dans le champ From. DMARC comble cette lacune grâce à l'alignement : un message réussit DMARC uniquement si SPF ou DKIM réussit pour un domaine correspondant au domaine From (l'alignement souple autorise les sous-domaines de la même organisation).

SPF en un enregistrement

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Chaque include autorise les serveurs d'un prestataire ; -all à la fin signifie que tout le reste échoue. La RFC 7208 définit les qualificateurs : - est fail, ~ est softfail (« probablement non autorisé »), ? est neutral et + est pass. +all autorise l'internet entier et annule l'intérêt du dispositif.

DKIM en un enregistrement

Votre fournisseur de messagerie signe les messages sortants avec une clé privée et vous donne une clé publique à publier sous un sélecteur, par exemple google._domainkey.example.com. Chaque service d'envoi utilise son propre sélecteur, vous pouvez donc avoir plusieurs clés DKIM en même temps (RFC 6376).

DMARC en un enregistrement

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p est la politique du domaine, sp celle des sous-domaines, et rua reçoit les rapports agrégés quotidiens des destinataires, qui listent les serveurs ayant envoyé du courrier au nom de votre domaine et si les messages ont réussi les contrôles.

La norme DMARC a été mise à jour en 2026

En mai 2026, l'IETF a publié la RFC 9989, qui remplace la spécification DMARC d'origine, la RFC 7489, et fait passer DMARC sur la voie de la normalisation (Standards Track). Les enregistrements existants continuent de fonctionner ; la balise de version reste v=DMARC1. Les changements à connaître :

• pct est supprimé. La RFC indique qu'il « n'était généralement pas appliqué avec exactitude ». Une nouvelle balise t (« testing ») le remplace : t=y demande aux destinataires de ne pas appliquer la politique, à peu près comme l'ancien pct=0.
• np est ajouté, une politique pour les sous-domaines inexistants.
• rf et ri sont supprimés, et un « tree walk » DNS remplace la Public Suffix List pour trouver le domaine organisationnel.

Les destinataires adopteront les nouvelles règles à des rythmes différents, et le guide de configuration de Google recommande encore pct pendant le déploiement. Utiliser pct ne casse rien, mais ne vous y fiez pas comme à un pourcentage précis.

Ce qu'exigent Gmail et Yahoo

Les deux fournisseurs ont commencé à appliquer leurs exigences aux expéditeurs en février 2024.

Sources : les consignes pour les expéditeurs de Google et les bonnes pratiques d'expédition de Yahoo. Google avertit que les messages non authentifiés « peuvent être marqués comme spam ou rejetés avec une erreur 5.7.26 », et sa FAQ indique : « À partir de novembre 2025, Gmail renforce l'application de ses règles aux envois non conformes », avec des rejets temporaires et permanents. La même FAQ recommande d'aligner DMARC avec SPF et DKIM et précise que l'alignement deviendra probablement une exigence par la suite.

Même si vous envoyez bien moins de 5 000 messages par jour, ces enregistrements déterminent si vos factures, réinitialisations de mot de passe et réponses arrivent en boîte de réception, et si quelqu'un d'autre peut envoyer des e-mails convaincants en votre nom.

Comment fonctionne le vérificateur SPF et DMARC de Searvia

Le vérificateur SPF et DMARC gratuit fait partie de notre outil d'analyse SEO de site web et affiche en premier le contrôle de l'authentification e-mail. Saisissez un domaine (un www. initial est retiré) et l'outil :

1. Recherche les enregistrements TXT du domaine et retient ceux qui commencent par v=spf1. Plus d'un est signalé, car SPF échoue alors.
2. Compte les requêtes DNS nécessaires à l'enregistrement SPF (include, a, mx, ptr, exists et redirect, en suivant chaque include sur un niveau de profondeur) et signale plus de 10.
3. Recherche les enregistrements TXT de _dmarc. suivi du domaine et retient celui qui commence par v=DMARC1.
4. Lit la politique p= de l'enregistrement DMARC et vérifie la présence d'une adresse de rapport rua.
5. Affiche les deux enregistrements en entier, avec une coche ou une croix, et une ligne DKIM marquée « Non vérifié ».

Dans l'audit global, ce contrôle a une priorité moyenne. Remarquez sa rigueur concernant DMARC : p=none satisfait le minimum de Gmail mais affiche tout de même un avertissement, car il n'empêche pas l'usurpation.

Ce que le contrôle gratuit ne couvre pas :

• DKIM. Les clés DKIM se trouvent sous des sélecteurs choisis par chaque service de messagerie, et il est impossible de les lister depuis le DNS ; le rapport marque donc DKIM comme non vérifié. Vérifiez DKIM dans le panneau d'administration de votre fournisseur de messagerie ou dans les en-têtes d'un message que vous avez envoyé (cherchez dkim=pass).
• Toutes les règles de SPF. Il signale les doublons et les dépassements de 10 requêtes, mais pas si l'enregistrement se termine par -all ou ~all. Les includes sont suivis sur un niveau de profondeur, donc un enregistrement profondément imbriqué peut nécessiter plus de requêtes que le décompte affiché.
• Les détails de DMARC. Il lit p= et vérifie rua, mais pas sp= ni les paramètres d'alignement.

Comment lire votre résultat

• Échec : votre domaine est exposé à l'usurpation et vos e-mails ne respectent pas les exigences de Gmail et Yahoo. Commencez à l'étape 1 ci-dessous.
• « DMARC est absent » ou « SPF est absent » : le travail est à moitié fait. Ajoutez l'enregistrement manquant.
• « DMARC est réglé sur none » : le résultat le plus courant. Vous collectez des rapports (si rua est défini), ce qui est la bonne première étape. Planifiez le passage à l'application de la politique.
• Réussite : très bien. Vérifiez les éléments que l'outil gratuit ne voit pas : DKIM pour chaque expéditeur, les includes SPF profondément imbriqués et la politique sp des sous-domaines.

Comment corriger, étape par étape

Étape 1 : listez tout ce qui envoie des e-mails au nom de votre domaine

Votre fournisseur de messagerie (Google Workspace, Microsoft 365), l'outil de newsletter, le CRM, le help desk, le logiciel de facturation, la plateforme e-commerce, le formulaire de contact du site et tout serveur qui envoie des notifications. En oublier un ici est la principale raison pour laquelle l'application de DMARC tourne mal par la suite.

Étape 2 : publiez un seul enregistrement SPF

1. Rassemblez la valeur include: documentée par chaque prestataire.
2. Combinez-les en un seul enregistrement. La RFC 7208 est explicite : s'il existe plus d'un enregistrement SPF, le résultat est « permerror ».
3. Terminez par ~all pendant vos tests, puis par -all.
4. Comptez les requêtes. include, a, mx, ptr, exists et redirect coûtent chacun une requête DNS, et la limite est de 10, y compris les requêtes dans les includes imbriqués. Au-delà de 10, c'est une permerror. Supprimez les services que vous n'utilisez plus, et abandonnez ptr, dont la RFC dit qu'il « NE DEVRAIT PAS être publié ».

Si un prestataire envoie avec son propre domaine d'enveloppe (courant pour les outils de newsletter), il n'a pas besoin d'figurer dans votre SPF ; il lui faut DKIM avec votre domaine pour que DMARC réussisse.

Étape 3 : activez DKIM pour chaque expéditeur

Dans chaque service, trouvez le réglage d'authentification de domaine ou DKIM, publiez l'enregistrement fourni (un TXT ou un CNAME sous un sélecteur) et activez la signature. Google recommande d'attendre 48 heures après la configuration de SPF et DKIM avant d'ajouter DMARC. Envoyez ensuite un message de test à une adresse Gmail et vérifiez « Afficher l'original » : vous voulez voir SPF: PASS, DKIM: PASS et DMARC: PASS.

Étape 4 : publiez DMARC en p=none avec des rapports

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Google recommande de commencer par p=none et d'inclure toujours rua. Les rapports agrégés sont des fichiers XML ; un service de rapports DMARC ou un analyseur les rend lisibles. Si l'adresse de rapport se trouve sur un autre domaine, ce domaine doit l'autoriser avec un enregistrement DNS.

Étape 5 : lisez les rapports et corrigez les échecs

Pendant deux à quatre semaines, repérez les services légitimes qui échouent à l'alignement SPF ou DKIM. Chacun a besoin d'une signature DKIM avec votre domaine ou d'un include SPF. Les e-mails transférés et les listes de diffusion peuvent échouer pour des raisons légitimes ; la RFC 9989 suggère que les domaines dont les utilisateurs écrivent sur des listes de diffusion restent au moins un mois à p=none et une durée similaire à p=quarantine avant p=reject.

Étape 6 : passez à quarantine, puis à reject

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Changez une étape à la fois et continuez à surveiller les rapports. Dès que vous atteignez p=quarantine, notre vérificateur affiche une réussite. p=reject est l'objectif : les destinataires refusent les messages qui échouent.

Étape 7 : verrouillez les domaines qui n'envoient pas d'e-mails

Les domaines parqués et les domaines de simple redirection attirent les usurpateurs car personne ne les surveille. Les recommandations du gouvernement britannique préconisent :

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Vérifiez les enregistrements vous-même

Le vérificateur lit SPF et DMARC ; vous pouvez consulter les trois enregistrements avec des outils DNS standard. Sur macOS ou Linux :

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

Sous Windows, nslookup -type=TXT _dmarc.example.com fait la même chose. Pour DKIM, il vous faut le sélecteur, que votre fournisseur indique dans ses réglages DKIM et qui apparaît sous la forme s= dans l'en-tête DKIM-Signature de tout message envoyé ; google est la valeur par défaut de Google Workspace. Certains fournisseurs publient la clé sous forme de CNAME pointant vers leur propre DNS, ce qui convient.

Le test de bout en bout le plus fiable reste un vrai message. Envoyez-en un depuis chaque service vers une adresse Gmail et ouvrez « Afficher l'original » : il indique le résultat SPF, DKIM et DMARC ainsi que le domaine pour lequel chacun a réussi. Un DKIM validé pour le domaine du fournisseur plutôt que le vôtre signifie que l'alignement DMARC échoue encore ; cherchez donc votre propre domaine dans le résultat.

Erreurs courantes

Exemple pratique (hypothétique)

L'exemple suivant est hypothétique, il ne s'agit pas de données réelles. Pinecrest Dental, un cabinet imaginaire, apprend par ses patients qu'ils ont reçu une fausse demande de paiement « venant » du cabinet. Le vérificateur SPF et DMARC affiche :

• SPF : v=spf1 include:_spf.google.com ~all
• DMARC : absent. Résultat : avertissement, « DMARC est absent. »

L'étape 1 révèle trois expéditeurs : Google Workspace, le système de réservation qui envoie des rappels par e-mail et un outil de newsletter. Le système de réservation a besoin d'un include SPF ; l'outil de newsletter utilise son propre domaine d'enveloppe, il reçoit donc DKIM avec le domaine du cabinet. Le cabinet publie DMARC en p=none avec une adresse de rapport. Deux semaines de rapports montrent le système de réservation qui réussit SPF et la newsletter qui réussit DKIM, ainsi que quelques centaines de messages provenant de serveurs inconnus à l'étranger qui échouent aux deux contrôles : c'est l'usurpation. Le cabinet passe à p=quarantine, où le vérificateur affiche une réussite, puis un mois plus tard à p=reject. Les faux messages envoyés en son nom sont désormais refusés par les destinataires qui appliquent DMARC.

Une checklist à terminer cette semaine

1. Lancez le vérificateur SPF et DMARC sur chaque domaine que vous possédez, y compris les domaines parqués.
2. Listez tous les services qui envoient des e-mails au nom de votre domaine.
3. Fusionnez SPF en un seul enregistrement, sous 10 requêtes, se terminant par ~all ou -all.
4. Activez DKIM dans chaque service et testez avec « Afficher l'original » dans Gmail.
5. Publiez DMARC en p=none avec rua, et lisez les rapports.
6. Passez à p=quarantine, puis à p=reject.
7. Publiez v=spf1 -all et p=reject sur les domaines qui n'envoient rien.

Comment Searvia surveille votre authentification e-mail

Le vérificateur SPF et DMARC gratuit lit vos enregistrements en quelques secondes, sans inscription, dans le cadre d'un audit de 38 contrôles qui couvre aussi l'apparence de votre site dans les résultats de recherche, sa vitesse et sa sécurité.

Un compte Searvia gratuit ajoute une analyse de sécurité hebdomadaire qui va plus loin sur l'e-mail : elle signale un enregistrement SPF absent ou trop permissif (+all, ?all ou pas de all du tout), une politique DMARC absente ou encore en p=none, et un enregistrement CAA manquant, avec la requête DNS derrière chaque constat et un enregistrement à copier. L'analyse se répète chaque jeudi, de sorte qu'une modification DNS qui casse vos enregistrements apparaît en une semaine. Pour la sécurité côté site web, consultez notre guide des en-têtes de sécurité.