netlupaVérifier SPF, DKIM et DMARC
Saisis ton domaine pour vérifier les trois enregistrements qui décident si tes e-mails arrivent en boîte de réception ou en spam.
Comment vérifier l'authentification de tes e-mails
Saisis le domaine depuis lequel tu envoies tes e-mails (la partie après le @).
Si tu connais ton sélecteur DKIM, saisis-le ; sinon laisse le champ vide et nous essaierons ceux des fournisseurs les plus courants.
Examine les trois blocs : chaque avertissement explique ce qui ne va pas et comment le corriger dans le DNS de ton domaine.
SPF, DKIM et DMARC en deux minutes
L'e-mail ne vérifie pas tout seul qui l'envoie : n'importe qui peut mettre ce qu'il veut comme expéditeur. Pour éviter l'usurpation (phishing) et le spam, les serveurs de messagerie consultent trois enregistrements TXT du domaine :
- SPF : la liste des serveurs autorisés à envoyer les e-mails du domaine.
- DKIM : une signature cryptographique sur chaque message, vérifiée avec une clé publique publiée dans le DNS.
- DMARC : la politique qui relie les deux. Elle indique quoi faire quand un e-mail ne réussit ni SPF ni DKIM alignés avec l'expéditeur (le laisser passer, l'envoyer en spam ou le rejeter) et où envoyer les rapports.
Sans les trois, tes e-mails ont beaucoup plus de chances de finir dans le dossier spam, et n'importe qui peut envoyer de faux e-mails en ton nom.
Pourquoi ils sont désormais obligatoires
Depuis 2024, Gmail et Yahoo exigent SPF, DKIM et DMARC de quiconque envoie plus de 5 000 e-mails par jour à leurs utilisateurs, et Microsoft applique les mêmes règles sur Outlook.com depuis 2025. Pour les petits expéditeurs, ce n'est pas strictement obligatoire, mais sans eux la réputation du domaine baisse et les filtres deviennent beaucoup plus sévères.
De plus, DMARC avec une politique « quarantine » ou « reject » est indispensable pour afficher ton logo à côté de tes e-mails (BIMI), et il est de plus en plus exigé par les audits de sécurité et les assurances cyber.
Les erreurs les plus courantes
- Deux enregistrements SPF : en ajoutant un nouveau fournisseur, on crée un second enregistrement au lieu d'ajouter un include à l'existant. Avec deux, SPF échoue complètement.
- Plus de 10 requêtes DNS : chaque include, a, mx ou exists compte, y compris ceux à l'intérieur des include. Avec beaucoup de fournisseurs, on dépasse la limite sans s'en rendre compte.
- « +all » à la fin : il autorise tout le monde et annule le SPF.
- DMARC bloqué sur « p=none » : c'est le mode observation, utile au début, mais il ne protège pas.
- DKIM non activé chez le fournisseur : beaucoup (Google Workspace, Microsoft 365) demandent de l'activer à la main et de publier la clé.
- Clés DKIM de 1024 bits : elles fonctionnent encore, mais il vaut mieux passer à 2048.
Comment arriver à DMARC « reject » sans perdre d'e-mails
Voici l'ordre sûr :
- Publie un SPF avec tous tes services d'envoi (ta messagerie, le site, le CRM, l'outil de newsletter) terminé par « ~all ».
- Active DKIM sur chaque service qui envoie en ton nom.
- Publie DMARC avec « p=none » et une adresse rua pour recevoir les rapports.
- Pendant quelques semaines, examine les rapports et ajoute à SPF ou DKIM les services légitimes qui échouent.
- Passe à « p=quarantine » (tu peux commencer avec pct=25 et augmenter) puis, quand tout est propre, à « p=reject ».
Reviens sur cet outil après chaque modification pour vérifier que les enregistrements sont toujours valides.
Chaque enregistrement en détail
Questions fréquentes
Quel est mon sélecteur DKIM ?
Ouvre un e-mail que tu as envoyé, affiche son code source ou ses en-têtes d'origine et cherche DKIM-Signature : la valeur de « s= » est le sélecteur et celle de « d= » le domaine. Google Workspace utilise souvent « google » et Microsoft 365 « selector1 » et « selector2 ».
Vaut-il mieux « ~all » ou « -all » ?
Avec DMARC en place, la différence pratique est faible, car c'est la politique DMARC qui décide. « -all » est plus strict ; « ~all » est plus tolérant avec les transferts et les services oubliés. Sans DMARC, « -all » protège davantage.
J'ai modifié le DNS et l'outil ne le voit pas, pourquoi ?
Les enregistrements DNS restent en cache pendant la durée de leur TTL (souvent une heure). Attends ce délai et revérifie. Vérifie aussi que l'enregistrement est sur le bon nom (par exemple _dmarc.tondomaine.fr pour DMARC).
Faut-il SPF et DMARC sur un domaine qui n'envoie pas d'e-mails ?
Oui, c'est très recommandé : publie « v=spf1 -all » et « v=DMARC1; p=reject; » pour que personne ne puisse utiliser ce domaine afin d'envoyer de faux e-mails.
Conservez-vous les domaines que je vérifie ?
Non. Nous interrogeons le DNS public au moment même, avec notre propre résolveur, et nous ne conservons ni le domaine ni le résultat.