Caractères valides d’une adresse e-mail

Quelles sont les exigences ?

Une adresse : une partie locale et un domaine

La RFC 5322 définit addr-spec comme une partie locale, un signe @ et un domaine. La partie locale désigne la boîte selon les règles du domaine. Le domaine désigne le système responsable de cet espace de noms.

local-part@domain

Ne validez pas les deux côtés avec une même classe de caractères. Un signe admis avant @ peut être invalide dans le domaine.

Sans guillemets, la partie locale admet lettres, chiffres et certains signes

La RFC 5322 définit le jeu atext. Sans guillemets, une partie locale peut utiliser lettres ASCII, chiffres et ces caractères imprimables :

Letters:       A-Z a-z
Digits:        0-9
Other ASCII:   ! # $ % & ' * + - / = ? ^ _ ` { | } ~
Separator:     .  only between non-dot elements

Des adresses comme o'connor@example.com, sales+ca@example.com et first_last@example.com sont donc possibles syntaxiquement. Aucun fournisseur n’est tenu de créer ou d’accepter ces boîtes.

Règles pour les points

La forme dot-atom sans guillemets n’admet un point qu’entre deux suites atext. La partie locale ne peut donc ni commencer ni finir par un point, ni contenir deux points adjacents.

Valid dot shape:     first.last@example.com
Invalid dot shapes:  .first@example.com
                     first.@example.com
                     first..last@example.com

Une fois la syntaxe acceptée, un fournisseur peut être plus strict ou différent. Par exemple, le guide sur les points dans les adresses Gmail explique comment Gmail personnel traite les variantes avec points.

Entre guillemets, la plage ASCII est plus large

La RFC 5322 admet aussi une partie locale entre guillemets. Les guillemets permettent des espaces et des caractères invalides dans un dot-atom ordinaire, avec échappement si la grammaire l’exige.

"customer support"@example.com

C’est un exemple de syntaxe : il n’affirme pas que tout formulaire ou fournisseur accepte les boîtes entre guillemets. Un expéditeur en production doit tester les systèmes qui créent, stockent, transportent et reçoivent l’adresse avant de s’y fier.

Le domaine suit les règles des étiquettes

La syntaxe de boîte de la RFC 5321 utilise des étiquettes de lettres, chiffres et traits d’union, séparées par des points. Une étiquette ne peut ni commencer ni finir par un trait d’union. Le tiret bas est donc invalide dans le domaine d’une boîte ordinaire, même s’il figure dans d’autres noms DNS comme _dmarc.example.com.

SMTPUTF8 étend la syntaxe au-delà de l’ASCII

La RFC 6531 définit l’extension SMTPUTF8, qui autorise l’UTF-8 dans les adresses quand les systèmes SMTP concernés la gèrent. Rétrograder une adresse Unicode en supprimant ou remplaçant des caractères n’est pas sûr. Conservez-la à l’identique et confirmez la prise en charge sur le chemin de livraison prévu.

Quand l’exigence entre-t-elle en vigueur ?

Les RFC 5321 et RFC 5322 définissent la syntaxe de base moderne de SMTP et du format des messages. La RFC 6531 ajoute les boîtes internationalisées via SMTPUTF8. Aucune date d’effet unique chez les fournisseurs ne rend toute adresse syntaxiquement valide utilisable partout.

Un produit peut adopter des règles plus strictes, mais doit les décrire comme des limites du produit, sans déclarer invalide partout une adresse conforme aux RFC. Revoyez la règle à chaque changement de fournisseur d’identité, de plateforme d’envoi ou de système de messagerie.

Comment mettre en œuvre l’exigence ?

1. Conservez l’adresse telle que saisie

Ne retirez que les espaces autour de la saisie, hors adresse. Ne supprimez pas de ponctuation, ne changez pas l’Unicode et ne mettez pas la partie locale stockée en minuscules par correction automatique.

2. Analysez partie locale et domaine séparément

Séparez au @ structurel avec un analyseur qui gère les formes d’adresse acceptées par votre produit. Évitez une courte expression régulière qui rejette en silence apostrophes, signes plus ou adresses internationalisées sans raison produit documentée.

3. Appliquez une politique documentée

Décidez si le produit gère les parties locales entre guillemets et les adresses SMTPUTF8. Renvoyez une erreur précise s’il accepte moins que la grammaire RFC. N’appelez pas mal formée une adresse valide mais non gérée.

4. Vérifiez contrôle et livraison séparément

Envoyez un message de vérification par le vrai chemin de production. La validation syntaxique ne prouve pas que le domaine se résout, que la boîte existe ni que la personne la contrôle. Pour une preuve publique du domaine, une requête DNS peut montrer ses enregistrements actuels sans valider la boîte.

Comment valider la conformité ?

Construisez des tests par classe prise en charge plutôt qu’une liste d’adresses familières. Incluez lettres et chiffres ordinaires, apostrophes, signes plus, tirets bas dans la partie locale, points bien et mal placés, une partie locale entre guillemets si elle est prise en charge, et une adresse UTF-8 si SMTPUTF8 l’est.

Notez trois résultats par cas : acceptation par l’analyseur, vérification du compte et livraison réelle. Un analyseur qui accepte prouve la syntaxe. Un clic de vérification prouve le contrôle. L’acceptation SMTP prouve la livraison. Aucun ne prouve seul le placement futur en boîte de réception.

Inscrivez ce travail dans la rubrique infrastructure e-mail, où DNS, SMTP, en-têtes et règles de transport sont des couches de preuve distinctes.