Email DNS Health Checker
Colle un domaine et lis ses records MX, SPF et DMARC, puis score si le domaine est câblé pour envoyer et recevoir du mail ou cassé en silence.
Ce health check DNS email lit les records qui décident si ton mail arrive ou pourrit en spam. Colle un domaine et il récupère le MX, pour que le courrier entrant ait où atterrir, le SPF, qui dit quels serveurs ont le droit d'envoyer en ton nom, et la politique DMARC, qui tranche quand le SPF ou le DKIM tombent. Ensuite il score le résultat et signale les casses habituelles : pas de MX, deux records SPF qui s'annulent en silence, ou un DMARC bloqué en monitoring qui ne rapporte presque rien. Il lit tout ce que le DNS public veut bien donner, c'est-à-dire presque tout. Le DKIM reste manuel parce que chaque fournisseur le planque derrière son propre selector, alors ce bout-là tu le vérifies à part.
Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.
Audit DNS du mail en direct
"Nos emails finissent toujours en spam." Je l'entends sans arrêt, et à chaque fois ça se termine pareil : moi en train de fouiller les mêmes records DNS à la main. J'ai vite saturé. Du coup maintenant je colle juste un domaine ici. Ça récupère le MX, le SPF, le DMARC, puis ça te dit si le domaine est vraiment câblé pour envoyer et recevoir du mail, ou si quelque chose cloche en silence. Trente secondes. C'est le test que je lance avant de perdre du temps sur quoi que ce soit de plus poussé.
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.