Contrôle de syntaxe, contrôle MX ou vérification SMTP : ce que détecte chacun

Un contrôle de syntaxe confirme qu'une adresse est correctement formée. Un contrôle MX confirme que le domaine publie des serveurs de messagerie. Un contrôle SMTP demande à ce serveur si la boîte mail précise existe. Chacun détecte des échecs que le précédent ne peut pas voir, et seul le dernier dit quelque chose de la personne. Les requêtes réelles ci-dessous montrent exactement où s'arrête chaque couche.

La plupart des explications sur le sujet s'arrêtent à « la syntaxe est faible, le MX est mieux, le SMTP est le meilleur ». C'est vrai, mais cela masque la partie intéressante : chaque couche a des cas limites où la lecture évidente est fausse. Nous avons lancé les requêtes DNS de cet article le 1er octobre 2026 avec dig, depuis une connexion ordinaire. La sortie brute figure dans nos notes de recherche.

Les trois couches en un coup d'œil

Chaque couche répond à une question différente, et aucune ne peut répondre à celle de la suivante.

Couche	Question à laquelle elle répond	Coût	Détecte	Ne peut pas détecter
Syntaxe	Cela a-t-il la forme d'une adresse email ?	Quelques microsecondes, sans réseau	@ manquant, espaces, points doubles, parties trop longues	Domaines mal orthographiés, domaines morts, boîtes mail mortes
MX / DNS	Ce domaine peut-il recevoir du courrier ?	Une requête DNS	Domaines inexistants, null MX, la plupart des domaines de faute de frappe	Boîtes mail mortes sur des domaines actifs
SMTP RCPT TO	Ce serveur acceptera-t-il du courrier pour cette boîte mail ?	Une connexion TCP sur le port 25, quelques secondes	Boîtes mail supprimées ou n'ayant jamais existé	Domaines catch-all, serveurs qui acceptent puis renvoient un rebond

Couche 1 : la syntaxe

Le contrôle de syntaxe rejette les saisies qui ne peuvent pas être une adresse, et rien d'autre. C'est la seule couche qui fonctionne sans réseau, ce qui la rend idéale pour un retour instantané dans un formulaire et inutile comme verdict.

Ce qu'elle détecte légitimement :

Saisie	Pourquoi elle échoue
jane.doe.example.com	Pas de @
jane doe@example.com	Espace non entre guillemets
jane..doe@example.com	Points consécutifs dans une partie locale non entre guillemets
jane@	Pas de domaine
Une partie locale de 70 caractères	La section 4.5.3.1.1 de la RFC 5321 limite la partie locale à 64 octets

Ce qu'elle laisse passer, à juste titre, car tout cela est syntaxiquement valide :

• asdkjhaslkdjh@gmail.com : bien formée, mais certainement pas une personne.
• jane@gmial.com : bien formée, mauvais domaine.
• jane+newsletter@gmail.com : bien formée et réelle. L'adressage « plus » est légitime, et une regex trop stricte qui le rejette refoule de vrais utilisateurs.

L'erreur courante est inverse : écrire une regex si stricte qu'elle rejette des adresses valides. Nous expliquons pourquoi dans pourquoi les regex de validation d'email échouent. Dans une chaîne de vérification, la syntaxe n'a besoin d'être assez stricte que pour arrêter les déchets avant d'y consacrer une requête DNS.

Couche 2 : MX et DNS

La couche MX demande au DNS quels serveurs acceptent le courrier du domaine, et la réponse peut prendre plus de deux formes. La plupart des guides la traitent comme un oui ou un non. Voici ce que nous avons réellement obtenu pour huit domaines :

Domaine	Statut DNS	Réponse MX	Ce que cela signifie
gmail.com	NOERROR	Cinq hôtes MX de Google	Peut recevoir du courrier
outlook.com	NOERROR	outlook-com.olc.protection.outlook.com	Peut recevoir du courrier
nonexistent-domain-zz918273.com	NXDOMAIN	aucune	Le domaine n'existe pas. Invalide, avec certitude
example.com	NOERROR	0 .	Null MX : n'accepte explicitement aucun courrier
yahoo.co	NOERROR	0 .	Null MX. Une faute de frappe de yahoo.com qui refuse le courrier
gmial.com	NOERROR	aucune, mais un enregistrement A existe	Pas de MX. Voir la règle du MX implicite ci-dessous
gmai.com	NOERROR	1 mail.h-email.net.	Un domaine de faute de frappe avec un MX qui fonctionne
hotmial.com	SERVFAIL à la première requête, puis 5 mail.h-email.net.	Une panne DNS temporaire, puis un MX qui fonctionne	Réessayer, ne jamais trancher sur un SERVFAIL

Ce tableau contient quatre leçons.

Le null MX est un « non » définitif

example.com et yahoo.co publient un unique enregistrement MX pointant vers . avec une préférence de 0. C'est un null MX, défini par la RFC 7505 : « To indicate that a domain does not accept email, it advertises a single MX RR ... with ... preference number 0 and a zero-length label » (pour indiquer qu'il n'accepte pas d'email, un domaine annonce un unique enregistrement MX de préférence 0 avec une étiquette de longueur nulle). Un contrôle naïf qui demande seulement « y a-t-il un enregistrement MX ? » voit un enregistrement et valide le domaine. Un contrôle correct reconnaît le point et fait échouer toutes les adresses de ce domaine. Vous pouvez contrôler n'importe quel domaine avec l'outil de recherche MX.

Pas de MX ne veut pas tout à fait dire pas de courrier

gmial.com n'a pas d'enregistrement MX, mais possède un enregistrement A. Selon la section 5.1 de la RFC 5321, « If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR ... pointing to that host. » (si une liste de MX vide est renvoyée, l'adresse est traitée comme si elle était associée à un enregistrement MX implicite pointant vers cet hôte). Autrement dit, un serveur d'envoi est censé essayer l'enregistrement A.

En pratique, un domaine sans MX qui n'héberge qu'une page parking ne fait presque jamais tourner de serveur de messagerie : la tentative de remise échoue donc. Mais le comportement strictement correct consiste à traiter « pas de MX, mais un A » comme « essayer l'hôte sur le port 25 », et à ne le faire échouer que si rien ne répond. Le considérer immédiatement comme invalide est généralement juste, et parfois faux.

Les domaines de faute de frappe peuvent passer le contrôle MX

gmai.com et hotmial.com publient tous deux un MX pointant vers le même hôte tiers, mail.h-email.net. Le courrier envoyé là ne parvient pas à la personne qui a mal tapé son adresse Gmail. La couche MX ne peut pas vous le dire. Elle indique, à juste titre, que le domaine reçoit du courrier. C'est pourquoi la détection des fautes de frappe est un contrôle distinct du DNS : elle compare le domaine à une liste de fautes d'orthographe connues des grands fournisseurs. Voir repérer les fautes de frappe dans les emails à l'inscription.

SERVFAIL n'est pas NXDOMAIN

Notre première requête pour hotmial.com a renvoyé SERVFAIL. Une seconde a renvoyé un enregistrement MX. La RFC 5321 dit explicitement qu'un domaine inexistant « MUST be reported as an error » (doit être signalé comme une erreur), tandis que « If a temporary error is returned, the message MUST be queued and retried later. » (si une erreur temporaire est renvoyée, le message doit être mis en file d'attente et renvoyé plus tard). Un vérificateur qui marque un SERVFAIL comme invalide supprimera de vraies adresses chaque fois qu'un serveur DNS passe une mauvaise minute.

Couche 3 : le contrôle SMTP de la boîte mail

Le contrôle SMTP est la seule couche qui interroge le serveur sur la boîte mail plutôt que sur le domaine. Le vérificateur se connecte à l'hôte MX de plus haute priorité sur le port 25, se présente, indique un expéditeur, puis nomme le destinataire avec RCPT TO. Le code de réponse du serveur est la réponse, et la connexion est fermée avant l'envoi de tout message. La conversation complète est détaillée étape par étape dans comment vérifier un email sans envoyer de message.

Ce qu'elle détecte et que les couches précédentes ne peuvent pas voir :

Adresse	Syntaxe	MX	SMTP
former.employee@company.com (boîte mail supprimée)	Réussi	Réussi	Rejetée, 550 5.1.1
random-string-xyz@gmail.com	Réussi	Réussi	Rejetée, 550 5.1.1
real.person@gmail.com	Réussi	Réussi	Acceptée, 250

C'est la couche qui compte pour les hard bounces sur une liste de personnes réelles. Quand les gens quittent leur emploi ou abandonnent un compte, le domaine continue de fonctionner et seule la boîte mail meurt : seule cette couche le voit.

Où le SMTP s'arrête

La couche SMTP a ses propres limites, et c'est pour elles qu'existe un quatrième résultat, risky (risqué) :

• Les domaines catch-all répondent 250 à toutes les adresses, y compris celles qui ne peuvent pas exister. Un bon vérificateur teste d'abord une adresse aléatoire pour le détecter. Voir qu'est-ce qu'un domaine catch-all.
• Les fournisseurs qui acceptent puis renvoient un rebond répondent 250 au RCPT TO et renvoient le rebond plus tard. Yahoo en est l'exemple le plus connu, traité dans pourquoi les adresses Yahoo sont difficiles à vérifier.
• Le greylisting et les délais dépassés renvoient un code temporaire 4xx, ou rien du tout. Réessayez plus tard.
• Le port 25 bloqué côté vérificateur. Le contrôle n'a jamais lieu. Nous l'avons mesuré sur des hébergeurs cloud dans notre article sur les fournisseurs cloud qui bloquent le port 25.

Dans chacun de ces cas, la réponse honnête est risky ou unknown (inconnu). Répondre valid revient à deviner.

Quelles couches utiliser, selon la situation

Utilisez autant de couches que votre budget de latence le permet, et ne vous arrêtez jamais à la syntaxe pour une adresse à laquelle vous comptez écrire.

Situation	Couches à utiliser	Pourquoi
Champ de formulaire en direct, pendant la saisie	Syntaxe uniquement	Retour instantané, sans appel réseau
Envoi du formulaire	Syntaxe + MX + contrôle des fautes de frappe, SMTP s'il répond dans votre délai	Voir la vérification en temps réel sur les formulaires d'inscription
Liste de cold emailing avant une campagne	Les trois, plus la détection des catch-all	Une boîte mail morte coûte de la réputation, pas seulement un envoi perdu
Ancienne liste de newsletter que l'on relance	Les trois	L'obsolescence se joue au niveau de la boîte mail, que la syntaxe et le MX ne voient pas
Nettoyage de saisie dans un CRM, sans envoi prévu	Syntaxe + MX	Peu coûteux, repère les domaines morts

Comment SimpleVerifier les enchaîne

Nous lançons les trois couches dans l'ordre et nous arrêtons dès que l'une donne une réponse définitive : une syntaxe cassée ou un domaine sans serveur de messagerie renvoie invalid sans ouvrir de connexion SMTP. Les domaines actifs passent au contrôle RCPT TO. Tout ce que le serveur de messagerie ne confirme pas, domaines catch-all compris, ressort en risky, jamais en valid.

À retenir

La syntaxe est un filtre, le MX un test du domaine, le SMTP le test de la boîte mail. Si un outil ou un script que vous avez écrit s'arrête au MX, il vous dit que le domaine fonctionne et rien sur la personne. Avant de vous fier à l'un d'eux, lisez correctement la réponse DNS : NXDOMAIN et null MX sont des échecs définitifs, SERVFAIL appelle une nouvelle tentative, et un domaine de faute de frappe avec un MX actif est un problème qu'aucune requête DNS ne signalera.

Pour voir les trois couches à l'œuvre sur une adresse, essayez l'outil gratuit de vérification d'email.