Bêta privéeMailbeam est en bêta privée : l'API publique n'est pas encore ouverte.Rejoindre la liste d'attente

Mailbeam

Qu'est-ce que la validation de la syntaxe d'un e-mail ?

La validation de syntaxe contrôle qu'une adresse est correctement formée selon la norme RFC 5322 — la bonne structure de partie locale, d'arobase et de domaine. Elle attrape les adresses mal formées, mais ne peut pas confirmer qu'une adresse bien formée existe réellement.

Ce que contrôle la validation de syntaxe

La validation analyse une adresse au regard des règles qui définissent un format légal : une partie locale avant le @, une seule arobase, et un domaine de structure valide. Elle rejette les erreurs évidentes comme les @ manquants, les caractères interdits, les points doublés ou les parties vides.

Bien faite, elle gère aussi les cas particuliers que la RFC autorise — parties locales entre guillemets, adressage avec +, domaines internationalisés — que les expressions régulières naïves traitent souvent mal, en étant soit trop strictes, soit trop permissives.

Pourquoi la validation de syntaxe ne suffit pas

Une adresse parfaitement formée peut rester non délivrable : le domaine peut ne pas exister, n'avoir aucun enregistrement MX, ou la boîte n'avoir jamais été créée. La validation prouve seulement que la chaîne a la forme d'un e-mail, pas que le courrier atteindra quelqu'un.

C'est pourquoi elle est la première étape, la moins coûteuse, d'un pipeline de vérification. Elle écarte vite les saisies aberrantes avant les contrôles MX, SMTP et de réputation, plus coûteux, qui déterminent la vraie délivrabilité.

Où exécuter la validation de syntaxe

Les contrôles côté client améliorent l'expérience en attrapant les fautes à la saisie, mais ils peuvent être contournés : la validation doit donc toujours être appliquée côté serveur aussi. Mailbeam effectue une validation conforme à la RFC à chaque vérification, normalisation et détection de fautes de frappe comprises.

L'appliquer côté serveur via une API garantit que la règle ne peut pas être sautée par un formulaire manipulé ou un appel direct à l'API, ce qui tient les données mal formées à l'écart de votre système.

Des adresses qui semblent fausses et ne le sont pas

La plupart des validateurs écrits à la main rejettent des adresses valides. Celles-ci sont toutes conformes à la spécification, et les limites de longueur ci-dessous sont celles qui s'appliquent réellement.

  user+invoice@example.com        valid   subaddressing (RFC 5233)
  "john doe"@example.com          valid   quoted local-part
  user@[192.0.2.1]                valid   address literal
  ------------------------------------------------------------
  .user@example.com               invalid dot-atom cannot lead with '.'
  user..name@example.com          invalid consecutive dots unquoted
  user@@example.com               invalid second '@' outside quotes

  Limits that are normative (RFC 5321 §4.5.3.1):
    local-part   64 octets
    domain      255 octets
    path        256 octets

La spécification autorise les parties locales entre guillemets, le sous-adressage et les adresses littérales : un validateur qui les rejette rejette de vrais utilisateurs au lieu d'attraper des fautes de frappe.

En pratique

Un formulaire reçoit « jane(at)example..com ». La validation de syntaxe la rejette immédiatement — pas d'arobase et un point doublé dans le domaine — sans dépenser une requête MX ni un sondage SMTP. Une adresse correctement formée passe ensuite aux contrôles plus profonds.

Questions fréquentes

Vérifiez les e-mails en confiance

Mailbeam s'en charge pour vous : syntaxe, MX, SMTP, catch-all et jetables en un seul appel à l'API. 1 000 vérifications gratuites par mois, sans carte.