Email DNS Health Checker
Vérifiez les records MX, SPF et DMARC d'un domaine et évaluez s'il est configuré pour envoyer et recevoir du courrier ou cassé en silence.
Ce vérificateur de santé DNS email lit les records MX, SPF et DMARC qui décident si un domaine peut envoyer et recevoir du courrier. Saisissez un domaine et nous récupérons le MX, pour que le courrier entrant ait une destination, le SPF, qui indique quels serveurs peuvent envoyer en votre nom, et la politique DMARC, qui définit ce qui se passe quand le SPF ou le DKIM échouent. Nous évaluons ensuite le résultat et signalons les défauts courants : un MX absent, deux records SPF qui s'annulent, ou un DMARC bloqué en p=none qui ne protège presque rien. Nous lisons tout ce que le DNS public renvoie, c'est-à-dire presque tout. Le DKIM reste manuel parce que chaque fournisseur le place derrière son propre sélecteur, alors vous vérifiez cette partie à part. Utile comme premier contrôle avant une migration ou un envoi important.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Audit DNS du mail en direct
Ce vérificateur lit les records MX, SPF et DMARC qui décident si un domaine peut envoyer et recevoir du courrier. Saisissez un domaine et nous récupérons le MX, pour que le courrier entrant ait une destination, le SPF, qui indique quels serveurs peuvent envoyer en votre nom, et la politique DMARC, qui définit ce qui se passe quand le SPF ou le DKIM échouent. Nous évaluons le résultat en quelques secondes et signalons les défauts courants : un MX absent, deux records SPF qui s'annulent, ou un DMARC bloqué en p=none. Le DKIM reste manuel parce que chaque fournisseur le place derrière son propre sélecteur. C'est le premier contrôle que nous lançons avant de passer à plus lourd.
Ce que couvre ce health check DNS email
La délivrabilité du mail, ce n'est pas un seul réglage. C'est tout un paquet de records DNS qui doivent s'entendre, et honnêtement je crois que c'est pour ça que tant de gens n'en font que la moitié. Le MX capte ton courrier entrant. Le SPF dit quels serveurs ont le droit d'envoyer en ton nom. Le DKIM signe chaque message pour que personne ne puisse le trafiquer en douce. Le DMARC ? C'est le règlement qui décide quoi faire quand le SPF ou le DKIM tombent. Ce checker lit tout ce que le DNS public veut bien donner. C'est-à-dire la plupart du temps presque tout.
Comment rattraper un résultat faible
- Ce domaine reçoit-il vraiment du mail ? Alors fais pointer ses records MX vers le bon host. Saute cette étape et il n'y a aucune boîte de réception où quoi que ce soit puisse atterrir.
- Un seul record SPF. Un seul. Liste dedans tous les services qui envoient pour toi, parce que publier deux records SPF, c'est l'erreur classique qui te pète les pieds, et ça casse les deux d'un coup en silence.
- Démarre le DMARC en mode monitoring et reste un moment sur les rapports. Une fois que tu fais confiance à ce que tu vois, durcis vers quarantine, puis reject. Passer direct à reject, c'est comme ça qu'on fait rebondir sa propre newsletter dès le premier jour.
- Le DKIM vit dans ta plateforme mail, pas dans ce checker. Il te faudra son selector pour le confirmer, alors va vérifier cette partie à part.
FAQ
Est-ce que ça garantit l'arrivée en boîte de réception ?
Non. Ne fais confiance à rien qui prétende le garantir. Un DNS propre te donne juste une place à table. Ta réputation d'expéditeur compte toujours, le contenu du message compte, et le fait que les gens ouvrent ou suppriment ton mail compte aussi, et n'importe lequel de ces trucs peut te coller en spam quand même. Cela dit, je n'ai jamais vu un domaine bien délivrer pendant que ces records étaient en vrac. Alors nettoie-les d'abord, puis va t'occuper du reste.
Pourquoi le DKIM n'est-il pas totalement automatique ici ?
Parce que le DKIM se planque derrière un selector, et chaque fournisseur invente le sien. Google choisit un nom. Ton service transactionnel en choisit un complètement différent. Il n'y a pas de moyen propre de le deviner depuis le domaine sans lancer une centaine de requêtes à l'aveugle, ce que je préfère éviter. Donc une fois que tu as déterré le tien, glisse-le dans le DKIM lookup tool et vérifie-le là-bas.
Questions fréquentes
Est-ce que ça garantit l'arrivée en boîte de réception ?
Non. Ne fais confiance à rien qui prétende le garantir. Un DNS propre te donne juste une place à table. Ta réputation d'expéditeur compte toujours, le contenu du message compte, et le fait que les gens ouvrent ou suppriment ton mail compte aussi, et n'importe lequel de ces trucs peut te coller en spam quand même. Cela dit, je n'ai jamais vu un domaine bien délivrer pendant que ces records étaient en vrac. Alors nettoie-les d'abord, puis va t'occuper du reste.
Pourquoi le DKIM n'est-il pas totalement automatique ici ?
Parce que le DKIM se planque derrière un selector, et chaque fournisseur invente le sien. Google choisit un nom. Ton service transactionnel en choisit un complètement différent. Il n'y a pas de moyen propre de le deviner depuis le domaine sans lancer une centaine de requêtes à l'aveugle, ce que je préfère éviter. Donc une fois que tu as déterré le tien, glisse-le dans le DKIM lookup tool et vérifie-le là-bas.
À quoi pointe vraiment un score de santé faible ?
Il pointe vers le record qui manque ou qui est en double. Pas de MX, ça veut dire aucune boîte où le mail puisse atterrir. Deux records SPF se cassent l'un l'autre en silence. Un DMARC bloqué en monitoring rapporte moins qu'un DMARC réglé sur quarantine ou reject. Le score n'est qu'une lecture rapide de laquelle de ces quatre pièces réclame ton attention en premier.
Pourquoi ne publier qu'un seul record SPF ?
Parce que deux records SPF, c'est l'erreur classique, et ça les casse tous les deux d'un coup. La solution est de garder un seul record SPF et d'y lister, dans cette unique chaîne, chaque service qui envoie pour toi. Les serveurs de réception traitent un domaine avec plus d'un record SPF comme une erreur permanente, alors la politique que tu as bossée arrête de compter.