Vérificateur de posture d'authentification email

Pointe un domaine et note son SPF, son DKIM, son DMARC et son BIMI dans un seul score de posture, avec une liste de corrections priorisée et le pire en haut.

Ce vérificateur de posture d'authentification email pointe un domaine et te dit si son mail est vraiment configuré pour inspirer confiance, ou s'il part tranquillement se perdre dans les spams. Il tire quatre requêtes DNS-over-HTTPS sur Google Public DNS en même temps, lit le record SPF à l'apex, le record DMARC à _dmarc, le record BIMI à default._bimi, et sonde les 12 selectors DKIM que tout le monde croise, plus celui que tu tapes. Ensuite il note chaque pilier par rapport à ce qui passe pour raisonnable en 2026 et roule le tout dans un seul score de posture avec une liste de corrections, le pire en haut. Il lit du DNS public et rien d'autre, n'envoie jamais d'email de test, et oublie chaque domaine à l'instant où tu fermes l'onglet. Sors-le avant un gros envoi, après un changement de fournisseur, ou quand un partenaire jure que ses mails marchent.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Checker SPF / DKIM / DMARC / BIMI

Tu lui donnes un domaine. Il te dit si les emails de ce domaine sont vraiment configurés pour inspirer confiance, ou s'ils partent tranquillement se perdre dans les dossiers spam. Je l'ai bricolé après une fois de trop où un client me pingait pour savoir pourquoi ses factures n'arrivaient pas, et j'en avais marre d'ouvrir cinq onglets juste pour lui répondre. Du coup maintenant c'est lui qui ouvre les onglets à ma place : il interroge Google Public DNS pour le SPF, le DMARC et le BIMI, il tape aux 12 selectors DKIM que je croise tout le temps, note chacun et te rend une liste de corrections, le pire en haut. Je le sors avant un gros envoi. Avant de valider un domaine que je viens d'acheter. Ou, soyons honnêtes, surtout quand un partenaire me jure sur tout que ses mails marchent nickel et que vraiment, vraiment non.

Le DKIM se planque derrière un selector qui vit dans le DNS à selector._domainkey.domain. Impossible de le deviner à l'aveugle. Du coup je lui balance les 12 sur lesquels je trébuche le plus (google, default, k1, selector1/2, dkim, mail, smtp, mxvault, mandrill, sendgrid, sib) en croisant les doigts pour qu'un morde. Tu en as un plus exotique ? Mets-le dans le champ au-dessus et j'irai directement le chercher.

Ce que veut vraiment dire la posture d'authentification email

Un contrôle de posture d'authentification email lit les quatre records qui décident si le mail de ton domaine est digne de confiance, puis les note ensemble. Personne ne t'explique ce truc tant que ça ne t'a pas mordu. Gmail, Outlook, Yahoo, La Poste, OVH, en gros toutes les passerelles B2B qui existent, elles ne lisent pas vraiment ton mail pour décider où il atterrit. Elles vérifient une poignée de signaux qu'une machine peut contrôler toute seule, sans aucun humain dans la boucle. Le SPF, c'est la liste d'invités des IP autorisées à envoyer "de la part" de ton domaine. Le DKIM signe chaque message avec une clé privée et range la clé publique correspondante dans le DNS, comme ça le destinataire peut prouver que personne n'a touché au message en route. Le DMARC, c'est le mot que tu laisses à l'entrée : si SPF et DKIM ratent tous les deux, voilà quoi faire (rien, dossier spam, ou porte claquée). Et le BIMI ? C'est la cerise, ton logo vérifié posé à côté de ton nom dans les boîtes qui prennent la peine de l'afficher. Loupe n'importe quoi là-dedans et tu te retrouves à fixer des dossiers spam, un branding arraché au passage, et peut-être un inconnu qui usurpe ton domaine pour phisher les clients mêmes que tu essaies de toucher.

Du coup l'outil sort les quatre records du DNS, lit chacun, le note par rapport à ce qui passe pour raisonnable en 2026, et roule le tout dans un seul score de posture. Aucun agenda commercial câblé dedans. Personne qui attend de te vendre un audit en bas de page. Ce sont exactement les mêmes données que Gmail et Microsoft sont déjà en train de scruter quand ils décident si le mail de ton domaine vaut quelque chose.

Comment le checker interroge le SPF, le DKIM, le DMARC et le BIMI

Sous le capot il tire quatre requêtes DNS-over-HTTPS sur Google Public DNS, toutes en même temps. Les faire les unes après les autres, c'est du temps mort, et personne n'a envie de regarder un spinner. Pour le SPF je récupère le record TXT à l'apex, je jette tout ce qui n'est pas v=spf1, je parcours les include, je compte les lookups DNS par rapport à ce fameux plafond de dix, et je signale les soft fails plus les policies pass-all qui font vraiment peur. Le DMARC sort du TXT à _dmarc.yourdomain : policy (none, quarantine, reject), les modes d'alignement, les adresses de reporting, le pourcentage. Le BIMI vit à default._bimi.yourdomain, et s'il est vraiment là je lis l'URL du logo SVG et, quand il y en a une, l'URL du certificat VMC. Le DKIM, c'est le casse-tête. C'est le seul pilier que tu ne peux pas trouver sans déjà connaître le selector, du coup je lui jette juste les douze suspects habituels (plus ce que tu as tapé dans le champ), je rapporte lesquels ont répondu, et je sors la longueur de clé du premier qui touche.

Cas d'usage courants d'un checker d'authentification email

  • Vérif avant le décollage d'une campagne marketing. Le matin d'un envoi de cinquante mille newsletters, je le lance. À chaque fois, sans exception. Un record de travers et tout l'envoi se vautre dans les spams, et à ce moment-là ? Bien trop tard pour rattraper le coup.
  • Enquêter sur "le mail du partenaire part en spam". Arrête de te disputer par email et pointe juste ce truc sur leur domaine. Neuf fois sur dix c'est une clé DKIM qui n'a jamais été configurée, ou un SPF tellement laxiste que la moitié d'internet peut envoyer en se faisant passer pour eux.
  • Auditer une nouvelle acquisition. Une boîte se fait intégrer dans le groupe, et d'un coup sa config email devient un sujet pour la revue de sécurité. Un SPF bâclé, un DMARC faiblard, c'est une porte grande ouverte pour quiconque a envie d'usurper la marque que tu viens d'acheter.
  • Se préparer aux règles bulk-sender de Gmail et Yahoo. Les deux exigent un SPF valide, du DKIM et un vrai DMARC de la part des gros expéditeurs depuis 2024. Je m'appuie là-dessus pour confirmer que je suis au-dessus de la barre bien avant qu'une échéance ne morde.
  • Activer le BIMI pour la reconnaissance de marque. Quoi que tu fasses, ne paie pas un Verified Mark Certificate avant d'avoir confirmé que ton DMARC est bien à p=quarantine ou p=reject. Sinon le BIMI t'ignore, point. Ça fait quelques centaines d'euros jetés par la fenêtre pour rien.
  • Changer de fournisseur mail. Les migrations, c'est là que la délivrabilité va mourir en silence. Une fois le transfert fait je le lance pour confirmer que le nouveau SPF inclut vraiment le nouveau prestataire et que les nouvelles clés DKIM sont bien actives.

Limites et notes sur la confidentialité

Soyons clairs sur les bords du truc. Ça lit du DNS public et rien d'autre. Ça n'envoie jamais d'email de test, ça ne tape jamais sur un serveur mail, et ça oublie chaque domaine que tu tapes à l'instant où tu fermes l'onglet. Le DKIM reste le pénible de la bande, vu qu'il repose entièrement sur le fait de connaître le selector de ton fournisseur, donc si le tien sort des sentiers battus, c'est exactement à ça que sert le champ perso au-dessus. Côté SPF je compte les include de premier niveau par rapport au plafond de dix lookups, mais je l'avoue, je ne descends pas en récursion dans les include imbriqués, donc une config vraiment touffue pourrait quand même mériter un coup d'œil manuel. Quant au BIMI, tout ce que je prétends c'est que le record est là. Est-ce que le logo s'affiche vraiment, est-ce que le VMC tient la route, ça c'est l'affaire du serveur destinataire. Pas la mienne.

Questions fréquentes

Est-ce que j'ai vraiment besoin à la fois du SPF et du DKIM ?

Ouais. Vraiment. Ils ne font pas le même boulot deux fois : le SPF se porte garant de l'IP qui a envoyé le truc, le DKIM se porte garant du message lui-même, et le DMARC ne passe que quand au moins un des deux est clean avec des identifiants qui s'alignent. En plus, Gmail et Yahoo exigent purement et simplement les deux des gros expéditeurs depuis 2024. Donc optionnel a cessé d'être le mot juste il y a un moment.

Quelle est une policy DMARC sûre pour démarrer ?

Vas-y mollo. Commence avec p=none et une adresse rua qui marche vraiment, comme ça les rapports ont un endroit où atterrir. Ensuite pose-toi avec ces rapports agrégés pendant une semaine ou deux et identifie quels expéditeurs légitimes échouent. Une fois ça réglé, grimpe à p=quarantine à 25%, pousse à 100%, et seulement après tout ça file vers p=reject. J'ai vu des gens balancer reject dès le premier jour sans aucun monitoring et cramer en silence leurs propres factures. Sois pas cette personne, franchement.

Pourquoi le record SPF a-t-il une limite de 10 "include" ?

C'est un garde-fou tout droit sorti de la RFC 7208. Plafonné à 10 pour que personne ne puisse transformer ton record SPF en bazar d'amplification DNS. Chaque include, a, mx, ptr, exists et redirect fait grimper le compteur d'un. Dépasse 10 et les destinataires te renvoient un permerror, ce qui, en pratique, éteint complètement ton SPF. Du coup je commence à le signaler pendant que tu te rapproches de la ligne. Pas une fois que tu t'es déjà vautré par-dessus.

Quel selector dois-je utiliser pour le lookup DKIM ?

Pas besoin de le connaître par cœur. J'essaie automatiquement les douze que je croise le plus (google, default, k1, selector1, selector2, dkim, mail, smtp, mxvault, mandrill, sendgrid, sib). Si ton fournisseur est parti choisir un nom custom, c'est en général enterré quelque part dans sa doc. Déterre-le, colle-le dans le champ optionnel au-dessus, et j'irai droit dessus.

Le BIMI exige-t-il un certificat payant ?

Pour les deux gros, ouais, en gros. Gmail et Yahoo refusent purement et simplement d'afficher ton logo sans un Verified Mark Certificate d'une CA comme DigiCert ou Entrust, et en obtenir un, c'est payant et un peu galère. D'autres destinataires sont plus souples et affichent le BIMI sans. Moi, je peux juste te dire si ton record existe et s'il pointe vers un VMC tout court. Acheter le cert pour de vrai ? Cette partie-là, c'est à toi de la gérer.

Le domaine que je vérifie est-il stocké quelque part ?

Nan. Les lookups partent vers Google Public DNS comme de simples requêtes DoH, et ça s'arrête là. Rien n'est loggé. Le domaine disparaît à l'instant où tu fermes l'onglet, et il ne part jamais en douce vers un pixel d'analytics non plus. Tout ce que tu regardes dans ce tableau de résultats vit dans la mémoire de ton navigateur et nulle part ailleurs sur terre.