Comment valider qu’une extension de nom de domaine existe bien ?

Pour vérifier une adresse e-mail ou un nom de domaine, beaucoup de développeurs utilisent une expression régulière (regex). Le problème : la liste des extensions évolue, et la regex, elle, n’est jamais mise à jour. Voici une méthode plus fiable.

Pourquoi une regex ne suffit pas

Une regex qui valide les extensions « connues » finit toujours par être dépassée. Le jour où un client saisit une adresse en .paris, .bzh ou .app, votre formulaire la refuse. Et vous perdez un client sans même le savoir.

Le phénomène ne va pas ralentir. L’ICANN a ouvert en 2026 un nouveau cycle de création d’extensions, le premier depuis 2012. Elle a publié début octobre 2026 plus de 1 600 candidatures. Des centaines de nouvelles extensions vont donc apparaître dans les années qui viennent.

Décomposer un nom de domaine

Une adresse e-mail contient un nom de domaine. Valider le domaine, c’est donc déjà valider une bonne partie de l’adresse.

Un nom de domaine se compose de deux parties :

• un nom, par exemple le nom de votre entreprise ;
• une extension (.fr, .com, .be, .net…), qu’on appelle un TLD (Top-Level Domain) dans le jargon technique.

Utiliser la liste officielle de l’IANA

Bonne nouvelle : l’IANA, l’organisme qui gère les extensions, publie leur liste complète et la tient à jour. Elle est disponible ici : https://data.iana.org/TLD/tlds-alpha-by-domain.txt.

L’idée est simple : comparer l’extension saisie par l’utilisateur à cette liste. Elle sert de « source de vérité ». Résultat : vous savez que l’extension existe vraiment, et vous n’avez plus de regex à maintenir.

Deux détails à connaître sur ce fichier :

• la première ligne est un commentaire (date et version), à ignorer ;
• les extensions sont en majuscules, et les extensions internationales (en caractères chinois, arabes…) sont encodées en Punycode, sous la forme XN--….

On pourrait aller plus loin avec une requête DNS, pour vérifier que le domaine lui-même existe. Mais c’est plus lent et plus coûteux qu’une simple comparaison avec une liste.

Notre implémentation en Kotlin

Nous utilisons cette méthode en Kotlin, notamment pour gérer les enregistrements DNS sur notre plateforme.

Étape 1 : récupérer la liste et la mettre en cache. Notre application télécharge le fichier de l’IANA et le garde en cache, par exemple pendant une heure. Passé ce délai, elle le relit.

@Cacheable(value = ["tlds"], cacheManager = "tldsCacheManager")
fun getTlds(): List<String> {
        return iana.getTldsListAsString().split("\n").toImmutableList().drop(1).map { s -> s.lowercase() }
}

Étape 2 : trouver l’extension d’un domaine. Un service technique reçoit un nom de domaine et renvoie l’extension trouvée dans la liste. Si aucune ne correspond, il lève une erreur.

fun tld(domainName: String): String {
        return applicationContext.getBean(DomainsAndTldsService::class.java).getTlds().stream().filter {
            domainName.contains("\\.$it\$".toRegex())
        }.findFirst().orElseThrow()
}

Étape 3 : extraire le nom sans l’extension.

    fun nomDomaine(name: String): NomDomaine {
        val tld = tld(name)
        return NomDomaine(name.substringBeforeLast(".$tld").substringAfterLast("."), Tld(tld))
    }

Astuce performance : les extensions de la liste IANA ne contiennent jamais de point. Il suffit donc de prendre ce qui suit le dernier point et de vérifier sa présence dans un Set. On évite ainsi de compiler une regex par extension (il y en a plus de 1 400).

val extension = domainName.substringAfterLast(".").lowercase()
val estValide = extension in tlds.toSet()

Et l’architecture dans tout ça ?

Chez nous, cette validation s’appuie sur des Value Objects.

Un Value Object ne doit dépendre d’aucun service externe. Nous passons donc par une factory : elle interroge le service qui connaît la liste de l’IANA, puis construit le Value Object seulement si les données sont valides. Sinon, elle refuse de le créer. Ce mécanisme valide le nom de domaine, et donc aussi l’adresse e-mail.

C’est notre façon de faire, pas la seule. Vous pourriez par exemple embarquer la liste en dur dans une librairie Java. Mais il faudrait alors redéployer votre application à chaque nouvelle extension. Or, on préfère généralement laisser une application tourner sans la relivrer pour le moindre changement.

Une limite à connaître : les suffixes publics

La liste IANA ne contient que les extensions de premier niveau. Elle ne sait pas que co.uk ou gouv.fr fonctionnent comme des extensions à part entière. Si vous devez isoler précisément le « vrai » nom d’un domaine, tournez-vous vers la Public Suffix List, maintenue par Mozilla.

Et en JavaScript / TypeScript ?

Inutile de tout recoder : la librairie tldts fait le travail. Elle s’appuie justement sur la Public Suffix List.

En résumé

Chez nous, les regex s’utilisent avec parcimonie et au cas par cas. Pour valider une extension, une liste officielle et à jour fait bien mieux. Et dans tous les cas, les tests unitaires sont obligatoires : ils vérifient qu’on respecte le contrat et qu’on n’introduit pas de régression.