Outil gratuit
Vos e-mails sont-ils authentifiés ?
SPF, DKIM et DMARC lus dans votre zone DNS, et expliqués en français — pas affichés en données brutes à déchiffrer.
Deux problèmes pour le prix d'un
Sans ces trois réglages, n'importe qui peut envoyer un e-mail qui semble venir de votre domaine — c'est ainsi que débutent la plupart des fraudes au virement. Et dans l'autre sens, vos propres e-mails légitimes partent en indésirable : depuis 2024, Gmail et Yahoo exigent une authentification correcte pour tout expéditeur régulier.
Les trois, en une phrase chacun
SPF déclare quels serveurs ont le droit d'écrire en votre nom. DKIM signe chaque message pour prouver qu'il n'a pas été modifié en route. DMARC dit au destinataire quoi faire quand les deux échouent — et vous fait remonter les tentatives d'usurpation. Les trois se posent dans le DNS, en trois enregistrements.
La décision
Le chemin que suit un message avant d'atterrir
SPF, DKIM et DMARC ne sont pas trois contrôles indépendants : les deux premiers produisent un résultat, le troisième décide quoi en faire. Réglez les trois interrupteurs et suivez le chemin.
Les trois réglages
SPF
Le serveur qui a envoyé est-il autorisé par votre domaine ?
DKIM
La signature du message tient-elle, au nom de votre domaine ?
DMARC
Ce que vous demandez de faire aux messages qui échouent.
Un message arrive, il dit venir de votre domaine
Au moins un des deux passe-t-il, aligné sur votre domaine ?
oui
non
Que demande votre enregistrement DMARC ?
Un des deux contrôles passe et il est aligné : DMARC est satisfait, votre politique n'est même pas consultée. Remis.
Un message passe DMARC si SPF le valide en étant aligné, OU si DKIM le valide en étant aligné. Un seul des deux suffit ; c'est pour cela qu'on met les deux en place (RFC 7489).
Ce qui protège un domaine
Trois enregistrements. Aucun par défaut.
Un domaine neuf n'en porte aucun : n'importe qui peut écrire en son nom, et les destinataires n'ont rien pour en douter. Les trois se posent dans le DNS, en une fois.
- SPFqui a le droit d'envoyer
- DKIMla signature qui voyage avec le message
- DMARCce qu'on fait des messages qui échouent
Lire le résultat
Le contrôle lit trois enregistrements dans votre zone DNS et les juge séparément. Un SPF parfait avec un DMARC absent laisse la porte ouverte, et l'inverse aussi.
- SPF en place et correctement formé
- Un seul enregistrement, des termes reconnus, un « all » final, et moins de dix résolutions DNS.
- Aucun SPF
- N'importe quel serveur peut écrire en se faisant passer pour votre domaine. Le défaut est grave si le domaine reçoit du courrier, à surveiller sinon.
- Plusieurs enregistrements SPF
- La norme n'en autorise qu'un. Face à deux, le destinataire n'en choisit pas un : il abandonne le contrôle entier.
- Un SPF qui se termine par « +all »
- Il autorise le monde entier à écrire en votre nom. C'est l'équivalent d'un SPF absent, en pire, puisqu'il a l'apparence d'une protection.
- Plus de dix résolutions DNS
- La norme fixe la limite à dix. Au-delà, le contrôle est déclaré en erreur permanente, et ce sont vos e-mails légitimes qui paient.
- Un SPF en « ~all »
- Les messages non autorisés sont acceptés puis marqués. Réglage le plus répandu et bon point de départ, avant « -all ».
- Un SPF sans « all », ou en « ?all »
- L'enregistrement n'exprime aucun avis sur les expéditeurs non listés. Le destinataire ne fait donc rien : la protection est nulle.
- Un SPF qui utilise « ptr »
- La norme le déconseille, le jugeant lent et peu fiable, et plusieurs grands fournisseurs l'ignorent. Il coûte une résolution pour rien.
- DMARC en « quarantine » ou « reject »
- La politique est appliquée : les messages qui usurpent votre domaine sont mis de côté ou refusés. C'est l'état visé.
- DMARC en « p=none »
- La politique observe sans rien bloquer. Bonne première étape, pas la destination — et à condition qu'une adresse de rapport soit déclarée.
- Aucun DMARC, ou politique invalide
- Sans DMARC, vous ne saurez jamais qu'on usurpe votre domaine. Une politique qui n'est ni « none », ni « quarantine », ni « reject » n'est pas appliquée du tout.
- DKIM : aucun sélecteur courant trouvé
- Un sélecteur porte le nom que son fournisseur a choisi. L'outil en teste douze parmi les plus répandus : ne rien trouver ne prouve rien.
- Aucun serveur de messagerie déclaré
- Le domaine ne reçoit pas de courrier. Les trois réglages restent utiles : ils empêchent qu'on usurpe votre nom pour en envoyer.
Les erreurs qu'on voit le plus souvent
Deux enregistrements SPF au lieu d'un
Ce qui la provoque : on ajoute un prestataire d'envoi et, au lieu de compléter le SPF existant, on crée un second enregistrement TXT. Le contrôle échoue alors entièrement.
Le geste qui corrige : fusionner les deux en un seul « v=spf1 … » qui rassemble tous les « include: ».
Le SPF dépasse dix résolutions DNS
Ce qui la provoque : chaque « include: », « a », « mx », « exists » et « redirect= » coûte une résolution, et les « include: » de vos prestataires en contiennent d'autres.
Le geste qui corrige : remplacer les « include: » les plus lourds par les plages « ip4: », et retirer les prestataires dont on ne se sert plus.
Un DMARC posé en observation, puis oublié
Ce qui la provoque : commencer par « p=none » est la bonne méthode. Sans adresse « rua », il n'y a pourtant aucun rapport à lire : la politique n'observe rien et ne bloque rien.
Le geste qui corrige : ajouter « rua=mailto:… » sur une boîte réellement relevée, puis passer à « quarantine ».
L'enregistrement DMARC est publié au mauvais endroit
Ce qui la provoque : DMARC se publie sur le sous-domaine « _dmarc », pas sur le domaine lui-même. Posé à la racine, il n'est jamais lu.
Le geste qui corrige : créer un TXT sur « _dmarc.votredomaine », commençant par « v=DMARC1; ».
Le prestataire signe avec son domaine à lui
Ce qui la provoque : DMARC exige que SPF ou DKIM soit aligné avec le domaine affiché dans le champ « De ». Un envoi qui passe SPF chez le prestataire peut donc échouer au contrôle.
Le geste qui corrige : activer la signature DKIM à votre nom chez chaque prestataire d'envoi.
Les termes d'un enregistrement SPF
Un SPF est une liste de termes lus de gauche à droite, du premier qui correspond.
| Terme | Ce qu'il fait | Résolution DNS |
|---|---|---|
| v=spf1 | Ouvre l'enregistrement. Obligatoire, et toujours en premier. | Non |
| ip4: | Autorise une adresse IPv4 ou une plage entière. | Non |
| ip6: | Autorise une adresse IPv6 ou une plage entière. | Non |
| a | Autorise les adresses du domaine, ou du domaine indiqué. | Oui |
| mx | Autorise les adresses des serveurs de messagerie du domaine. | Oui |
| include: | Reprend le SPF d'un autre domaine — souvent un prestataire d'envoi. | Oui |
| exists: | Autorise si un nom construit à la volée se résout. | Oui |
| ptr | Teste le nom inverse de l'adresse. La norme déconseille de le publier. | Oui |
| redirect= | Remplace l'évaluation par celle d'un autre domaine. | Oui |
| exp= | Désigne le texte d'explication renvoyé en cas de refus. | Non |
| all | Correspond toujours. Se place en dernier et décide du sort des non-listés. | Non |
Chaque terme peut porter un qualificateur : « + » autorise (défaut), « - » refuse, « ~ » accepte puis marque, « ? » n'exprime aucun avis. La norme limite à dix les termes qui déclenchent une résolution DNS. Source : RFC 7208, §4.6.2, §4.6.4 et §5.
Les balises d'un enregistrement DMARC
Des balises séparées par des points-virgules, publiées en TXT sur le sous-domaine « _dmarc ».
| Balise | Ce qu'elle règle | Par défaut |
|---|---|---|
| v | Version. Doit valoir « DMARC1 » et venir en premier. | Obligatoire |
| p | Politique demandée : « none », « quarantine » ou « reject ». | Obligatoire |
| sp | Politique appliquée aux sous-domaines. | La valeur de « p » |
| rua | Adresses qui reçoivent les rapports agrégés quotidiens. | Aucun rapport |
| ruf | Adresses qui reçoivent les rapports d'échec détaillés. | Aucun rapport |
| pct | Part du courrier à laquelle la politique s'applique. | 100 |
| adkim | Alignement DKIM : strict (« s ») ou souple (« r »). | r |
| aspf | Alignement SPF : strict (« s ») ou souple (« r »). | r |
| fo | Conditions de production d'un rapport d'échec. | 0 |
| ri | Intervalle entre deux rapports agrégés, en secondes. | 86400 |
| rf | Format des rapports d'échec. | afrf |
Source : RFC 7489, §6.3. Un enregistrement minimal tient en trois balises — « v=DMARC1; p=none; rua=mailto:… » — mais sans adresse de rapport, la politique d'observation n'observe rien.
Questions fréquentes
Comment vérifier son SPF, son DKIM et son DMARC ?
Entrez le nom de domaine ci-dessus. L'outil interroge votre zone DNS, lit le SPF, le DMARC publié sur « _dmarc », les serveurs de messagerie déclarés, et cherche une signature DKIM sur douze sélecteurs répandus. Le résultat est rendu en français, pas en données brutes.
À quoi servent SPF, DKIM et DMARC ?
SPF déclare quels serveurs ont le droit d'écrire en votre nom. DKIM signe chaque message pour prouver qu'il n'a pas été modifié en route. DMARC dit au destinataire quoi faire quand les deux échouent, et fait remonter les tentatives d'usurpation.
Faut-il terminer son SPF par « -all » ou par « ~all » ?
« ~all » fait accepter puis marquer les messages non autorisés, « -all » les fait refuser. La méthode raisonnable : commencer par « ~all », lire les rapports DMARC pour repérer les expéditeurs légitimes oubliés, puis passer à « -all ». Y aller directement fait disparaître du courrier réel.
Pourquoi l'outil ne trouve-t-il pas mon DKIM ?
Parce qu'une signature DKIM se publie sous un sélecteur, et qu'un sélecteur porte le nom que son fournisseur a choisi. Aucun outil public ne peut les deviner tous : celui-ci en teste douze parmi les plus courants, et affiche « indéterminé » plutôt que « absent ».
Combien de temps une modification DNS met-elle à prendre effet ?
Le délai dépend de la durée de vie déclarée sur l'enregistrement et de ce que les résolveurs ont en cache. Un enregistrement posé pour la première fois apparaît souvent en quelques minutes ; un enregistrement modifié met au plus la durée de vie de l'ancienne valeur à disparaître.
Gmail et Yahoo exigent-ils vraiment DMARC ?
Depuis février 2024, oui, pour qui envoie en volume : Google fixe le seuil à cinq mille messages par jour vers ses boîtes, et demande alors SPF, DKIM et DMARC, avec un taux de signalement sous 0,30 %. « p=none » suffit. En dessous du seuil, SPF ou DKIM reste demandé.
Les trois nombres qui cassent un SPF
Dix, un, zéro.
Les SPF des vraies entreprises ne tombent presque jamais sur la syntaxe. Ils tombent sur ces trois-là.
10
Résolutions DNS, pas une de plus
La norme limite à dix les termes qui demandent une résolution — « include: », « a », « mx », « exists: », « ptr », « redirect= ». Au-delà, la vérification échoue en bloc, et ajouter un prestataire d'envoi suffit à franchir la limite.
1
Un seul SPF par domaine
Deux enregistrements « v=spf1 » ne s'additionnent pas : la vérification échoue. C'est l'erreur qu'on commet en suivant la notice d'un nouveau service sans toucher à celle du précédent.
0
Ce qu'un DMARC en « p=none » empêche
« none » ne demande rien aux destinataires : il observe et fait remonter des rapports. C'est la bonne première étape — et la mauvaise étape finale, sur laquelle des domaines restent des années.
La limite de dix résolutions et le SPF unique viennent de la RFC 7208 ; les politiques DMARC, de la RFC 7489 § 6.3. Les deux tables de cette page les détaillent terme par terme.
Le vocabulaire
Six signes qui changent tout le sens
Ils tiennent en un caractère, se collent devant un terme, et décident si un message est refusé ou simplement marqué.
+all- Autorise le monde entier à écrire en votre nom. Publié par erreur, il annule l'intérêt du
SPF. -all- Refuse tout ce qui n'est pas listé. C'est la position ferme, à ne prendre qu'une fois la liste complète.
~all- Accepte puis marque. La position de transition, le temps de lire les rapports.
?all- N'exprime aucun avis. Revient à ne rien publier, mais donne l'impression d'avoir agi.
p=quarantine- Demande aux destinataires de mettre les échecs de côté, sans les refuser.
rua=mailto:- L'adresse qui reçoit les rapports quotidiens. Sans elle, un
DMARCen observation n'apprend rien à personne.
Vingt contrôles, sans inscription
- Le bilan complet d'un domaine
- Quand expire ce nom de domaine ?
- Ce certificat SSL est-il valide ?
- Ce domaine est-il sur une liste noire ?
- Quels serveurs reçoivent les e-mails de ce domaine ?
- Quels serveurs de noms répondent pour ce domaine ?
- Quels enregistrements TXT porte ce domaine ?
- Vers quoi pointe cet alias ?