Vérification SPF, DKIM et DMARC
Trois enregistrements DNS disent au reste du monde quels e-mails viennent vraiment de votre domaine. Cette vérification les lit comme le fait un serveur récepteur et traduit chaque terme qu’elle trouve.
La ligne d’expéditeur d’un e-mail ne prouve rien
L’e-mail a été conçu comme une enveloppe de papier. L’expéditeur écrit l’adresse de retour et personne ne la vérifie. Un serveur de n’importe quel pays peut envoyer un message dont la ligne From affiche votre domaine. Trois ajouts ultérieurs comblent cette lacune et tous les trois vivent dans votre zone DNS sous forme d’enregistrements TXT.
- SPF, sur le domaine lui-même
- Une liste des serveurs autorisés à envoyer pour le domaine. Le récepteur compare l’adresse IP qui se connecte avec la liste.
- DKIM, à
selector._domainkey - Une clé publique. Le service d’envoi signe chaque message avec la clé privée correspondante, ce qui permet au récepteur de savoir que personne n’a modifié le message et quel domaine s’en porte garant.
- DMARC, à
_dmarc - Votre consigne pour le courrier qui ne réussit aucun des deux tests sous votre propre nom de domaine : le livrer, l’envoyer dans les indésirables ou le refuser. Il désigne aussi une boîte pour des rapports quotidiens.
Depuis février 2024, Gmail et Yahoo refusent les envois en masse des domaines qui n’ont pas ces enregistrements et Microsoft a suivi en 2025 pour Outlook.com.
Ce que la vérification examine
Elle commence par vos enregistrements MX, pour reconnaître le fournisseur de boîtes (Google Workspace, Microsoft 365, Proton Mail, Fastmail et huit autres). Elle sait alors quel include SPF et quels sélecteurs DKIM attendre.
| Enregistrement | Marqué comme faute | Marqué comme avertissement |
|---|---|---|
| SPF | Aucun enregistrement sur un domaine qui a des serveurs de messagerie ; deux enregistrements ; plus de 10 requêtes DNS ; un include qui n’a pas de SPF propre ou qui boucle ; un terme mal orthographié ; +all ; plus de deux requêtes qui ne renvoient rien | 8 à 10 requêtes ; ?all ou pas de all ; ptr ; des termes placés après all ; votre fournisseur de boîtes absent de la liste |
| DKIM | Une clé publiée inutilisable : RSA de moins de 1024 bits, valeur p= endommagée, algorithme inconnu | Aucune clé sous aucun des noms essayés ; une clé de 1024 bits ; l’indicateur de test t=y |
| DMARC | Aucun enregistrement ; deux enregistrements ; pas de p= valide ; une adresse de rapport ou une valeur de balise mal formée | p=none ; pct sous 100 ; sp=none sous une politique plus stricte ; des rapports envoyés à un autre domaine qui n’a pas accepté de les recevoir |
Les requêtes sont comptées à travers chaque include imbriqué et c’est généralement là que la limite de 10 est dépassée sans que personne s’en aperçoive. Pour un sous-domaine, la recherche DMARC remonte au domaine parent et applique sa valeur sp=. Le verdict global est le pire des trois résultats. Trois enregistrements facultatifs (MTA-STS, TLS-RPT, BIMI) sont seulement signalés comme publiés ou non.
Un domaine dont tout le SPF est v=spf1 -all est traité comme un domaine qui n’envoie rien. L’absence de clé DKIM y est normale et le DMARC suggéré est p=reject.
Comment trouver votre sélecteur DKIM
Les clés DKIM n’ont pas d’adresse fixe. Chaque service d’envoi choisit une étiquette, appelée le sélecteur et le DNS ne permet pas de les lister. La vérification essaie environ trois douzaines de noms usuels, comme google, selector1, k1 et s1. Un « aucune clé trouvée » veut donc souvent dire seulement que la vôtre porte un autre nom.
- Envoyez un message depuis votre domaine vers une boîte que vous pouvez ouvrir.
- Affichez sa source brute : « Afficher l’original » dans Gmail, « Afficher la source du message » dans Outlook, « Présentation > Message > Tous les en-têtes » dans Apple Mail.
- Trouvez la ligne qui commence par
DKIM-Signature:et lisez deux balises.d=est le domaine signataire ets=est le sélecteur.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta2024; …
Ici, vous saisiriez mta2024 dans la case du sélecteur. Si d= affiche le nom de votre plateforme d’infolettres et non votre domaine, le message est signé, mais pas par vous et cette signature ne compte pas pour DMARC. Notre décodeur d’en-têtes d’e-mail lit ces lignes à votre place.
Réparer dans un ordre sûr
Dressez la liste de tout ce qui envoie au nom de votre domaine : boîtes de messagerie, plateforme d’infolettres, boutique en ligne, service d’assistance, formulaire de contact du site web. Mettez chacun dans un seul enregistrement SPF. Activez ensuite DKIM dans chaque service qui le propose, puisque DKIM survit au transfert alors que SPF non.
Publiez DMARC avec p=none et une adresse rua= et lisez les rapports pendant quelques semaines avec le lecteur de rapports DMARC. Une fois que chaque source légitime réussit, passez à quarantine, puis à reject. Le générateur d’enregistrements écrit les deux enregistrements.
Cette vérification lit le DNS et ne voit jamais un seul de vos messages. Elle ne peut pas confirmer qu’un service signe réellement avec la clé trouvée, ni que le domaine signataire correspond à votre adresse From. Pour cela, il faut les en-têtes d’un message livré.
Questions fréquentes
Pourquoi mes e-mails vont-ils dans les indésirables alors que SPF, DKIM et DMARC réussissent tous ?
L’authentification prouve qui a envoyé le message. Elle ne dit pas si les gens le veulent. Les filtres pèsent aussi les taux de plainte, la réputation de l’adresse IP et du domaine d’envoi, les liens du message et la réaction des destinataires aux envois précédents. Commencez par une recherche dans les listes noires.
Un domaine peut-il avoir deux enregistrements SPF ?
Non. Deux enregistrements TXT qui commencent par v=spf1 produisent une erreur permanente et les récepteurs agissent comme si vous n’en aviez aucun. Fusionnez-les en un seul v=spf1 avec tous les termes include: et ip4: et un seul all à la fin.
Que signifie « SPF PermError: too many DNS lookups » ?
Le traitement de votre enregistrement a demandé plus de 10 requêtes DNS. Chaque include, a, mx, exists et redirect en coûte une et les includes à l’intérieur d’un include comptent aussi. Retirez les services que vous n’utilisez plus, ou remplacez a et mx par des adresses ip4: fixes, qui ne coûtent rien.
Le SPF doit-il finir par ~all ou -all ?
Avec DMARC en place, les deux conviennent, car DMARC décide du sort d’un message qui échoue. ~all est le choix le plus prudent tant que vous découvrez encore vos expéditeurs. N’utilisez jamais +all, qui autorise tous les serveurs d’Internet.
p=none suffit-il pour Gmail et Yahoo ?
Oui, leurs règles pour les expéditeurs en masse acceptent p=none. Il ne vous donne que des rapports et le courrier falsifié est quand même livré. La protection commence à quarantine.
Ai-je besoin de DMARC sur un domaine qui n’envoie jamais d’e-mail ?
C’est là que c’est le plus simple et le plus utile, car un domaine inutilisé est un déguisement pratique pour l’hameçonnage. Publiez v=spf1 -all sur le domaine et v=DMARC1; p=reject; à _dmarc.