Vérifier le SPF, le DKIM et le DMARC d'un domaine
Trois enregistrements DNS décident si vos e-mails arrivent en boîte de réception ou en indésirable. Cet outil les lit en direct : qui a le droit d'écrire en votre nom (SPF), comment vos messages sont signés (DKIM), et ce que vous demandez aux destinataires de faire des imposteurs (DMARC).
Un domaine, une URL ou une adresse e-mail : on en extrait le domaine.
frComment le contrôle fonctionne
- 1
Les MX sont lus
Ils désignent les serveurs qui reçoivent le courrier du domaine. Leur absence signifie que le domaine n'est pas configuré pour recevoir — première cause de rebond dur.
- 2
Le SPF est analysé, pas seulement affiché
On compte les mécanismes qui déclenchent une requête DNS (la RFC en autorise dix, pas une de plus), on lit le qualificateur du « all », et on signale les doublons — deux enregistrements SPF font échouer le contrôle entier.
- 3
DMARC et DKIM complètent le tableau
La politique DMARC est lue avec son pourcentage et ses adresses de rapport. Côté DKIM, une vingtaine de sélecteurs courants sont sondés.
Les trois enregistrements ne font pas le même travail
SPF déclare quels serveurs ont le droit d'envoyer pour votre domaine. DKIM signe cryptographiquement chaque message, ce qui prouve qu'il n'a pas été altéré en route. DMARC est la consigne : que doit faire le destinataire quand ni SPF ni DKIM ne s'alignent avec le domaine affiché à l'écran.
Publier SPF et DKIM sans DMARC laisse le destinataire décider seul. Publier DMARC en p=none observe sans protéger. La configuration qui protège vraiment est p=quarantine ou p=reject, une fois les rapports vérifiés.
Ce que l'outil ne peut pas voir
L'absence d'un sélecteur DKIM ne prouve rien : un domaine qui signe avec un sélecteur maison n'apparaîtra pas dans la liste sondée. C'est une limite de DKIM, pas de l'outil.
La réputation de votre IP d'envoi, votre présence sur une liste de blocage et le contenu de vos messages pèsent lourd dans la délivrabilité et ne se lisent pas dans le DNS.
Questions fréquentes
Faut-il SPF, DKIM et DMARC, ou l'un suffit-il ?
Les trois. Depuis 2024, Gmail et Yahoo exigent SPF ou DKIM pour tout expéditeur, et les trois pour ceux qui dépassent 5 000 messages par jour vers leurs utilisateurs. Un domaine sans DMARC voit son courrier de plus en plus souvent filtré, même légitime.
Pourquoi mon SPF échoue-t-il alors qu'il a l'air correct ?
La cause la plus fréquente est la limite de dix requêtes DNS. Chaque « include: » en consomme une, et un include peut en contenir d'autres : trois prestataires d'e-mailing suffisent à dépasser le plafond. Au-delà, le contrôle renvoie une erreur permanente, exactement comme s'il n'y avait pas de SPF.
Que veut dire ~all et faut-il passer à -all ?
Le tilde demande de marquer les messages non conformes sans les rejeter ; le tiret demande de les rejeter. Passez au tiret une fois que vos rapports DMARC confirment qu'aucun envoi légitime n'échoue — sinon vous couperez vos propres factures ou vos notifications applicatives.
Ces requêtes passent-elles par vos serveurs ?
Non. Elles partent de votre navigateur vers les résolveurs publics de Google et Cloudflare, en DNS-over-HTTPS. Nous ne voyons pas les domaines que vous testez, et le quota consommé est celui de votre connexion — ce qui permet de laisser l'outil gratuit et sans compte.
Le même contrôle par API
Cet outil tourne dans votre navigateur. Pour le même contrôle dans votre code, en masse ou côté serveur, l'API répond en JSON.
Voir la documentation