Validateur d'adresse e-mail et d'enregistrement MX

Validez une adresse e-mail et vérifiez si son domaine peut recevoir du courrier.

email-validator

🌐 The domain is resolved server-side over DNS-over-HTTPS. Only the part after @ is looked up — the local part is never sent to a resolver, and no mail is sent.

§01 À PROPOS DE CET OUTIL

Aperçu

Deux questions distinctes sont confondues. « Cette adresse est-elle bien formée ? » se répond depuis la chaîne. « Le courrier envoyé ici arrivera-t-il ? » se répond en partie depuis le DNS. « Cette boîte existe-t-elle ? » ne se répond pas du tout sans envoyer de courrier, et tout ce qui prétend le contraire devine.

Cet outil répond aux deux premières et le dit clairement pour la troisième. Il vérifie la syntaxe selon les règles que les serveurs appliquent en pratique, puis résout le domaine pour les enregistrements MX, A/AAAA, SPF et DMARC — assez pour distinguer une faute de frappe d’un domaine qui ne peut pas recevoir de courrier, et d’un domaine dont l’authentification est cassée.

Utilisation

Saisissez ou collez une adresse.
Lisez les deux résultats principaux : Syntax et Domain accepts mail.
Lisez les remarques. Elles nomment le problème précis plutôt qu’un verdict.

Ce que la vérification syntaxique applique

La RFC 5322 autorise bien plus que ce que les systèmes de messagerie acceptent. Les commentaires entre parenthèses, les parties locales entre guillemets avec espaces et les espaces de pliage imbriqués sont une grammaire légale qu’une part substantielle des serveurs réels rejette. Un vérificateur qui accepte tout ce qui est légal vous dit qu’une adresse convient alors qu’elle sera rejetée.

Les règles appliquées ici sont donc les règles pratiques :

La partie locale peut contenir lettres, chiffres et !#$%&'*+-/=?^_`{|}~. — ce qui inclut l’apostrophe, car des noms comme o'[email protected] existent, et +, car le sous-adressage à la Gmail est d’usage quotidien.
Pas de point initial, pas de point final, pas de points consécutifs.
La partie locale est limitée à 64 caractères et le domaine à 255, selon la RFC 5321. Chaque étiquette de domaine est limitée à 63.
Le domaine doit être un nom d’hôte valide avec un TLD d’au moins deux lettres. user@localhost est refusé ; il n’a de sens qu’au sein d’une seule machine.
Le non-ASCII doit être en Punycode. user@日本語.jp est rejeté au profit de sa forme xn--, car la livraison à la forme Unicode exige la prise en charge de SMTPUTF8 à chaque saut.

Lire le résultat DNS

Les enregistrements MX sont listés par priorité croissante. Plusieurs enregistrements sont normaux — ce sont des recours, et des priorités égales répartissent la charge.

Le null MX (RFC 7505) est un unique enregistrement de priorité 0 avec un hôte vide. Il signifie que le domaine n’accepte délibérément aucun courrier, et il supprime le recours au MX implicite. C’est la configuration correcte pour un domaine servant uniquement un site web, et example.com l’utilise.

Le MX implicite est la situation inverse : aucun enregistrement MX, les expéditeurs se rabattent donc sur l’adresse A ou AAAA. Le domaine est techniquement joignable et le résultat est généralement accidentel. Le courrier arrive à ce qui écoute sur le port 25 du serveur web, c’est-à-dire nulle part d’utile.

SPF est examiné pour les défauts qui cassent la livraison, non pour le style. Plus de dix mécanismes à résolution DNS (include, a, mx, ptr, exists, redirect) provoquent une erreur permanente selon la RFC 7208 §4.6.4 et l’authentification échoue purement et simplement — une limite facile à franchir en ajoutant un prestataire de plus. +all autorise tout expéditeur sur Internet et annule entièrement SPF. ptr est déconseillé. Un enregistrement sans mécanisme all reste ouvert, sauf s’il utilise redirect=, auquel cas omettre all est correct.

Deux enregistrements SPF sur un domaine constituent également une erreur permanente, et c’est signalé car cela se présente comme un échec de livraison intermittent et inexpliqué. Cela arrive dès qu’on ajoute l’enregistrement d’un second prestataire à côté du premier au lieu de le fusionner avec include:.

DMARC est lu depuis _dmarc.<domaine>. p=none est signalé : il ne fait que collecter des rapports, les échecs sont donc consignés puis livrés quand même. C’est le bon point de départ et le mauvais endroit pour s’arrêter.

Exemples

Un formulaire d’inscription qui rejette de vraies adresses — comparez votre validation à ce qui est appliqué ici. Les expressions régulières copiées sur le web rejettent couramment les balises +, les apostrophes et les TLD longs.
« Ils n’ont jamais reçu mon courrier » — vérifiez d’abord le domaine du destinataire. Un null MX ou un MX absent l’explique immédiatement et déplace la conversation hors de votre serveur.
Auditer votre propre domaine d’envoi — le nombre de résolutions SPF, +all et un DMARC resté à p=none sont les trois constats qui expliquent le plus souvent le courrier arrivant en indésirable.
Après l’ajout d’un prestataire de messagerie — les prestataires vous donnent un include: et mentionnent rarement le plafond de dix résolutions. Vérifiez le total, pas la nouvelle ligne.
Enquêter sur un message précis — l’analyseur d’en-têtes de courriel montre le chemin de livraison et les verdicts SPF, DKIM et DMARC tels que le destinataire les a consignés, et la visionneuse .eml ouvre un message enregistré. Cet outil répond à la question avant l’envoi ; ces deux-là y répondent après.

Remarques

Le DNS est résolu via DNS-over-HTTPS avec un délai d’attente de cinq secondes par requête. Si une requête échoue, les champs qu’elle aurait remplis sont rapportés comme absents plutôt qu’en erreur : une résolution TXT lente ne fait donc pas perdre un résultat MX correct.

Le domaine n’est interrogé que s’il constitue un nom d’hôte valide. Une adresse qui échoue à la vérification structurelle ne génère aucun trafic DNS.

La liste des domaines jetables couvre des fournisseurs bien connus à titre d’avertissement, non d’autorité — de nouveaux domaines apparaissent constamment et l’absence de la liste ne signifie rien. La vérification des comptes de rôle est de même informative : info@ et admin@ sont des adresses parfaitement valides, qui n’appartiennent simplement pas à une personne.

Aucun courrier n’est envoyé, aucune connexion SMTP n’est ouverte, et la partie locale de l’adresse n’est jamais incluse dans une requête DNS. Voir la politique de confidentialité.

FAQ

Cet outil me dit-il si la boîte existe ?

Non, et aucun outil ne peut le dire de façon fiable. La commande VRFY de SMTP est désactivée presque partout, et sonder avec RCPT TO relève de la collecte d'adresses : c'est ce que font les spammeurs, cela vous fait limiter ou bloquer, et les fournisseurs avec adresse fourre-tout répondent oui à tout. Ce à quoi on peut répondre, c'est si la syntaxe est valide et si le domaine accepte du courrier, et c'est ce qui est rapporté.

L'adresse que je saisis est-elle envoyée quelque part ?

Le domaine est résolu via DNS-over-HTTPS. La partie locale — tout ce qui précède le @ — n'est pas nécessaire pour résoudre quoi que ce soit, elle n'est donc jamais incluse dans une requête DNS. Aucun courrier n'est envoyé et rien n'est conservé.

Pourquoi mon adresse valide est-elle signalée comme incorrecte ?

Le plus souvent des points consécutifs, un point en début ou en fin de partie locale, ou un caractère non ASCII. Les domaines internationalisés doivent être fournis en Punycode (xn--…), car un expéditeur sans prise en charge de SMTPUTF8 ne peut pas livrer à la forme Unicode. Les parties locales entre guillemets comme "a b"@example.com sont également refusées : elles sont légales dans la RFC 5322 et rejetées par une large part des systèmes de messagerie réels.

Qu'est-ce qu'un null MX ?

Un unique enregistrement MX de priorité 0 pointant vers la racine (un simple point), défini par la RFC 7505. C'est le propriétaire du domaine qui déclare explicitement que ce domaine ne reçoit aucun courrier, et cela empêche les expéditeurs de se rabattre sur l'enregistrement A. example.com en publie un, d'où le rapport « n'accepte aucun courrier » plutôt que « pas de MX ».

Le domaine n'a pas de MX mais est signalé comme joignable. Pourquoi ?

C'est la règle du MX implicite : sans enregistrement MX, les expéditeurs se rabattent sur l'adresse A ou AAAA. C'est valide et presque jamais voulu, d'où le signalement. Si cet hôte est un serveur web et non un serveur de messagerie, le courrier est livré quelque part où personne ne le lit.

Un compte de rôle ou un domaine jetable pose-t-il problème ?

Ni l'un ni l'autre n'est invalide — ce sont des éléments de contexte. info@ et support@ aboutissent à une boîte partagée que plusieurs personnes ou personne ne lit, ce qui compte pour la récupération de compte. Un domaine jetable suggère une adresse créée pour être abandonnée. La vérification est informative, et la liste des jetables ne couvre que des fournisseurs bien connus : l'absence de cette liste ne prouve donc rien.