Nom de domaine avec ou sans accent : ce qui change pour vos emails

⚡TL;DR

• Gardez l'accent pour identifier le domaine : café.fr et cafe.fr sont deux noms distincts, avec des configurations indépendantes.
• Rapprochez café.fr et xn--caf-dma.fr : ce sont deux écritures du même nom, sans second enregistrement à acheter.
• Pour un email, relevez le domaine de l'enveloppe SPF, le domaine d= de DKIM et celui de l'adresse From avant de comparer leurs résultats.
• Vérifiez le nom interrogé dans le DNS : voir xn-- dans un rapport DMARC ne prouve pas un défaut d'alignement.

Vous avez configuré un domaine avec accent. Quelques jours plus tard, un rapport mail affiche un nom commençant par xn--. Vous cherchez alors un domaine inconnu dans votre compte, ou vous retirez l'accent pour retrouver une écriture plus familière. Ces deux réactions conduisent à des erreurs différentes.

Dans le premier cas, vous séparez deux écritures d'un même nom. Dans le second, vous remplacez le nom par un autre. Pour le DNS et la messagerie, un é n'est pas une décoration que l'on peut effacer. café.fr correspond à xn--caf-dma.fr ; le nom cafe.fr, sans accent, a une autre identité.

Cette distinction décide de la zone où chercher vos réglages et des domaines que les destinataires authentifient. Elle explique aussi pourquoi une interface lisible et un journal technique peuvent sembler se contredire. Les noms ci-dessus servent uniquement à comparer des écritures : cet article ne décrit ni leurs titulaires, ni leurs services, ni leurs enregistrements réels.

Retirer l'accent change le nom de domaine

café.fr et xn--caf-dma.fr désignent le même nom ; cafe.fr est un autre domaine. La première paire associe une forme Unicode, lisible avec son accent, et sa représentation ASCII. La seconde comparaison change l'orthographe. Aucun mécanisme du DNS ne relie automatiquement les configurations des noms avec et sans accent.

Deux écritures du même nom, mais deux noms si l'accent disparaît

La forme ASCII technique conserve l'identité du nom accentué. Elle n'est donc pas le résultat d'une suppression des accents. Les lettres, chiffres et tirets de xn--caf-dma.fr représentent ce nom précis, et le préfixe fait partie de l'écriture à conserver. Recopier seulement la fin de cette chaîne n'a pas de sens pour retrouver le domaine.

À l'enregistrement, cette distinction évite de compter deux fois le même achat. Une interface peut vous présenter le nom accentué pendant la commande, puis sa forme xn-- dans le récapitulatif. Les deux libellés peuvent désigner un seul domaine enregistré. En revanche, détenir le nom sans accent ne vous attribue pas automatiquement celui avec accent, ni l'inverse. Si vous souhaitez exploiter les deux noms, leur enregistrement et leur configuration se traitent séparément.

Le même raisonnement s'applique aux services. Une organisation qui contrôle deux noms peut choisir le même hébergeur DNS et le même fournisseur de messagerie. Elle peut même demander que les adresses correspondantes arrivent dans une seule boîte. Ce sont des choix de configuration explicites. Le retrait d'un accent ne crée ni cette boîte, ni un alias de messagerie, ni une copie des enregistrements.

Imaginez deux domaines de votre organisation, l'un accentué et l'autre non. Le second reçoit déjà des emails, tandis que le premier vient d'être enregistré. Ajouter une adresse accentuée sur vos documents commerciaux ne configure pas sa réception. Il faut que le fournisseur de messagerie connaisse ce domaine et que ses réglages DNS correspondent à l'usage prévu. L'existence du service sur l'autre nom ne comble pas ce manque.

Le schéma représente donc deux zones pédagogiques indépendantes. Cela n'impose pas deux fournisseurs ni deux serveurs physiques : une même infrastructure peut héberger plusieurs zones. L'indépendance concerne les noms et leurs données. Une modification appliquée à l'un ne se propage pas à l'autre par ressemblance orthographique.

Le nom que vous retrouvez dans la zone DNS et les journaux

La forme xn-- donne un repère commun pour rapprocher une zone DNS, un journal et une interface affichant l'accent. Elle identifie le nom internationalisé sans changer son domaine.

Dans une console DNS, le titre de la zone peut être présenté en Unicode. Un export ou un journal de requêtes peut utiliser sa forme ASCII. Avant de chercher un enregistrement manquant, comparez les noms complets. Vous pouvez avoir ouvert la bonne zone sous une autre présentation, ou une zone réellement différente dont le nom a perdu son accent.

Le nom de la zone et le nom d'un enregistrement ne sont pas toujours affichés ensemble. Certaines consoles attendent un nom relatif et ajoutent la zone courante. Dans une zone fictive example.com, saisir _dmarc peut ainsi désigner _dmarc.example.com. Le petit libellé _dmarc paraît identique dans deux consoles ; le nom complet dépend pourtant de la zone ouverte. C'est ce nom complet qui permet de savoir quelle politique vous avez modifiée.

Un exemple documentaire, sans valeur issue d'un domaine tiers, rend la différence visible :

Zone ouverte : example.com
Nom relatif : _dmarc
Nom complet : _dmarc.example.com
Type recherché : TXT

Appliquez cette lecture à vos propres noms avec accent. Si l'interface affiche la zone en Unicode et le nom complet en ASCII, vérifiez leur correspondance avant de créer une deuxième entrée. Ajouter un enregistrement pour corriger un simple affichage peut introduire un doublon ; publier dans le domaine sans accent laisserait la zone attendue inchangée.

Le contenu d'un journal demande aussi un peu de contexte. Le nom interrogé, le type demandé et la réponse reçue décrivent une opération précise. Une absence de TXT ne signifie pas automatiquement une absence de domaine. Une erreur de résolution ne dit pas que l'accent était refusé. Conservez le nom exact et le résultat : les remplacer par une approximation rend le diagnostic moins fiable.

Pour un ticket de support, joignez l'écriture saisie et la forme ASCII correspondante, puis le nom complet de l'enregistrement concerné. Ajoutez la date de l'observation si vous venez de modifier la zone. Ces renseignements distinguent une confusion de nom d'une ancienne réponse encore en cache. Aucun délai d'attente ne fera apparaître une correction dans une zone que vous n'avez pas modifiée.

Enfin, convertir un nom n'interroge pas le DNS. La conversion peut produire une forme ASCII correcte sans prouver que le domaine est enregistré, qu'il possède une zone publiée ou qu'il reçoit des emails. Ces questions demandent des contrôles distincts. Le fait de savoir écrire une destination ne prouve pas qu'un service y répond.

SPF, DKIM et DMARC : vérifier le bon domaine pour vos emails

Les contrôles mail utilisent plusieurs identités de domaine, dont l'écriture dépend de l'étape du traitement. La RFC 8616 précise séparément les règles du DNS, de SPF, de DKIM et de DMARC. Confondre ces étapes conduit notamment à chercher une clé dans la mauvaise zone ou à modifier un en-tête que l'on devait conserver.

Pour suivre le texte de la RFC, deux termes sont utiles ici. Un U-label est la forme Unicode d'une partie internationalisée du nom, comme café. Son A-label est la représentation ASCII correspondante, ici xn--caf-dma. Les points séparent les parties du domaine ; fr ne change pas. Ce vocabulaire décrit deux écritures, jamais deux enregistrements de domaine à souscrire.

Les noms interrogés dans le DNS

Le §3 de la RFC 8616 maintient en ASCII les chaînes stockées dans les enregistrements DNS utilisés par ces protocoles. Un nom récupéré dans un en-tête est converti avant sa recherche DNS s'il contient des U-labels. Le logiciel qui consulte un enregistrement ne peut pas présumer que sa réponse sera lue uniquement par une messagerie à en-têtes internationalisés.

Cette règle ne décrit pas le format de tous les champs d'un email. Elle délimite les données publiées et la recherche DNS. Le même message peut comporter une adresse lisible en Unicode et déclencher une interrogation utilisant le nom ASCII correspondant. Il n'y a pas de changement de propriétaire ou de destination à cette étape.

Pour lire une configuration, séparez le nom de l'enregistrement et sa valeur. Le premier répond à « où chercher ? », la seconde contient la politique ou la clé. Un texte SPF parfaitement formé, enregistré sous le mauvais nom, ne sera pas celui que le destinataire viendra consulter. La présence d'une clé DKIM quelque part dans votre compte DNS ne suffit pas davantage : sa position doit correspondre au domaine et au sélecteur de la signature.

Voici les emplacements d'un scénario entièrement fictif utilisant example.com. Ce tableau décrit des noms à interroger, sans fournir de configuration à copier.

Contrôle	Identité du scénario	Nom DNS associé
SPF	Domaine d'enveloppe example.com	example.com, en TXT
DKIM	d=example.com, sélecteur s=septembre	septembre._domainkey.example.com, en TXT
DMARC	Adresse From sous example.com	_dmarc.example.com, en TXT

Dans votre messagerie, ces domaines peuvent différer. Un prestataire peut gérer le domaine de l'enveloppe ou signer avec son propre domaine. Commencez donc par relever les identités effectivement utilisées sur un message reçu. Chercher seulement le nom affiché en haut de votre console ne répond pas forcément à la question posée par chaque protocole.

SPF et le domaine de l'enveloppe

Le §4 impose la conversion de tout U-label en A-label avant validation SPF. Le domaine présenté dans EHLO doit déjà être en A-labels ; celui de MAIL FROM peut employer l'une ou l'autre forme dans un échange internationalisé. La conversion s'applique aussi aux noms utilisés par les expansions de macros SPF, pas seulement à la première recherche.

SPF examine des identités de la session SMTP. EHLO présente le serveur qui envoie ; MAIL FROM porte l'adresse de l'enveloppe, notamment utilisée pour les retours d'erreur. Cette dernière est distincte de l'adresse From que le lecteur voit dans sa messagerie. Un domaine configuré pour l'affichage ne devient donc pas automatiquement le domaine contrôlé par SPF.

Pourquoi EHLO doit-il employer la forme ASCII dès le départ ? Cette commande précède la réponse annonçant si le serveur accepte l'extension nécessaire au courrier internationalisé. Le logiciel d'envoi ne dispose pas encore de cette information. Le format imposé à ce stade ne préjuge pas du format possible dans les étapes suivantes.

Dans un scénario fictif, une plateforme expédie pour example.com avec une enveloppe sous retours.example.com. Le TXT SPF à examiner est celui du domaine d'enveloppe utilisé, pas un TXT choisi parce qu'il figure sur la page d'accueil du site. Si la plateforme utilise un domaine internationalisé, la même recherche prend sa forme ASCII après conversion. Le protocole n'essaie pas ensuite le domaine privé de son accent comme solution de secours.

Pour comprendre un résultat SPF, relevez donc l'identité testée avant de lire le détail de la politique. Un pass indique que l'adresse IP a été autorisée pour l'identité évaluée. Il ne certifie pas que cette identité est celle de l'adresse From, ni que toute la messagerie est correctement configurée. La comparaison avec From appartient à DMARC.

Les noms internationalisés mentionnés à l'intérieur d'un enregistrement SPF doivent eux aussi être écrits en A-labels. Une interface d'administration qui accepte l'accent dans le nom de la zone ne vous autorise pas à l'introduire librement dans la valeur TXT. Le champ de saisie du domaine et le contenu publié remplissent deux fonctions différentes.

Quand vous administrez les deux noms, avec et sans accent, évitez la copie automatique des politiques. Les mêmes serveurs peuvent être autorisés pour chacun, mais seulement si les flux le justifient. Un domaine utilisé uniquement pour la réception n'a pas nécessairement les mêmes besoins qu'un domaine d'expédition. La proximité des noms n'est pas un inventaire de vos émetteurs.

DKIM et les valeurs signées

Le §5 distingue les messages classiques des messages à en-têtes internationalisés. Pour les noms internationalisés de d=, de la partie domaine de i= et de s=, les A-labels sont obligatoires en message classique : la RFC emploie MUST. Avec des en-têtes internationalisés, les U-labels sont recommandés (SHOULD), tandis que les A-labels restent valides.

Ces tags n'ont pas tous la même fonction. d= indique le domaine signataire, s= le sélecteur qui repère la clé, et i=, lorsqu'il est présent, une identité comprenant une partie locale et une partie domaine. Dans l'exemple fictif i=service@example.com, seul example.com est le domaine. La règle sur son écriture ne signifie pas que service serait un nom à convertir de la même manière.

La vérification DKIM comporte une recherche de clé publique dans le DNS et un calcul cryptographique sur le message. Les deux opérations n'ont pas la même règle de transformation. Le nom de recherche doit prendre la forme attendue par le DNS. Pour calculer ou vérifier le hash, la RFC exige au contraire d'utiliser le domaine tel qu'il est écrit dans l'en-tête, avec les règles de canonicalisation DKIM applicables.

Cette nuance interdit une réparation tentante : remplacer les noms Unicode par leur forme ASCII partout dans un email brut avant de vérifier sa signature. Même si les noms désignent le même domaine, leur écriture n'est pas identique dans les données signées. Une équivalence de noms ne rend pas deux suites d'octets interchangeables pour le calcul cryptographique.

Supposons qu'un message à en-têtes internationalisés contienne un domaine signataire en Unicode. Le vérificateur retrouve sa clé avec le nom ASCII correspondant, puis vérifie la signature en conservant la représentation de l'en-tête. Une interface peut afficher ces deux écritures côte à côte pour aider l'administrateur. Cet affichage n'autorise pas la modification du message original.

Pour un diagnostic, conservez donc une copie brute du message reçu. Une capture d'écran où la messagerie a reformaté les adresses aide à lire, mais ne restitue pas nécessairement les valeurs utilisées pour la signature. Relevez d= et s= dans l'en-tête DKIM, puis cherchez la clé à l'emplacement construit à partir de ces valeurs. Une clé publiée pour le nom sans accent ne devient pas celle du domaine accentué.

Le sélecteur mérite autant d'attention que le domaine. Deux envois du même domaine peuvent employer des sélecteurs différents ; trouver une clé avec l'un ne valide pas la signature faite avec l'autre. Dans le scénario example.com, septembre._domainkey.example.com et archives._domainkey.example.com sont deux emplacements. L'erreur serait alors un mauvais sélecteur, même si l'écriture du domaine était correcte.

DMARC et le domaine visible dans From

Le §6 demande de convertir en A-labels tous les U-labels du domaine de l'adresse From avant la suite du traitement DMARC. Il conserve aussi des adresses conventionnelles dans les tags de rapport rua et ruf. Cette dernière règle concerne les destinations des rapports, pas l'écriture autorisée partout dans le message.

Le point de départ est le domaine de l'adresse From, après l'arobase. Le nom affiché de la personne, par exemple « Équipe commerciale », ne sert pas à cette comparaison. Un accent dans ce libellé peut être présent alors que l'adresse ne contient aucun domaine internationalisé. Ouvrir le détail de l'expéditeur évite de diagnostiquer le mauvais élément.

DMARC recherche une authentification SPF ou DKIM réussie et alignée avec ce domaine From. L'alignement strict compare les domaines exacts ; l'alignement relâché tient compte du domaine organisationnel. Une différence de sous-domaine peut donc être admise selon le mode choisi. Une suppression d'accent n'est pas une règle d'alignement relâché : elle ne transforme pas deux noms indépendants en un seul.

Dans la comparaison de cet article, café.fr et xn--caf-dma.fr peuvent correspondre lors du traitement des noms. cafe.fr reste distinct. Posséder les deux domaines, utiliser le même serveur ou afficher le même nom d'entreprise ne change pas cette relation. Si votre expéditeur doit utiliser le nom accentué mais signe pour l'autre, corrigez la configuration du flux concerné.

Pour les rapports, une destination documentaire telle que rua=mailto:rapports@example.com montre le format d'une adresse conventionnelle. Si le domaine destinataire est internationalisé, sa partie domaine utilise la forme ASCII ; ajouter un accent dans la partie locale ne respecte pas la règle du §6. L'adresse doit aussi pouvoir recevoir les rapports. Sa syntaxe ne crée pas une boîte.

Enfin, considérez le cas qui déclenche souvent le doute : vous avez configuré le nom accentué, puis un rapport DMARC ou l'en-tête Authentication-Results présente xn--caf-dma.fr. Le rapprochement avec l'interface peut être parfaitement correct. Cherchez quel champ porte cette valeur, puis lisez le résultat associé : le domaine From, le domaine SPF et le domaine signataire ne sont pas interchangeables.

Si les noms correspondent après conversion, poursuivez avec les causes indiquées par les résultats : IP non autorisée, clé introuvable, signature invalide ou identité authentifiée réellement différente du domaine From. Ne réécrivez pas votre politique à cause du seul préfixe. Voir xn-- à la place de l'accent n'est pas une erreur d'alignement en soi.

Ce que les outils vérifient quand vous saisissez café.fr

Le DNS lookup et le contrôle DMARC de CaptainDNS acceptent café.fr et interrogent sa forme ASCII. Pour DMARC, le nom de recherche est _dmarc.xn--caf-dma.fr. Le DNS lookup affiche l'Unicode en regard de cette forme. Le contrôle DMARC affiche le nom interrogé en ASCII. Ces noms illustrent le traitement de l'entrée, sans présenter de résultat réel sur ce domaine tiers.

Le lookup répond à une question de publication DNS : quels enregistrements sont renvoyés pour le nom et le type demandés ? Le contrôle DMARC se concentre sur la politique publiée et sa syntaxe. Ils aident à vérifier la bonne zone, mais un TXT DMARC valide ne prouve pas que chaque plateforme d'envoi signe vos messages avec le bon domaine.

Cette limite compte lors d'un changement de fournisseur. Vous pouvez avoir publié exactement la valeur demandée et continuer à recevoir des échecs sur certains emails. La plateforme qui les expédie peut encore utiliser une ancienne identité. Comparez alors la publication DNS et les en-têtes d'un envoi de cette plateforme. Un contrôle de domaine et une vérification de message se complètent ; ils n'observent pas la même chose.

Un résultat vide doit lui aussi être lu avec le nom demandé. Si vous avez saisi le domaine sans accent, l'outil a examiné ce nom distinct. Si vous avez saisi le bon domaine, l'absence d'un enregistrement appelle un examen de sa publication. Dans les deux cas, la première vérification reste l'identité de la zone, avant toute modification de valeur.

Pour rapprocher uniquement les écritures du nom, le convertisseur Punycode fournit les deux formes sans consulter le DNS. Pour connaître les données publiées par le registre, vous pouvez consulter l'enregistrement du domaine avec RDAP. RDAP ne valide ni SPF ni DMARC : une fiche d'enregistrement décrit le domaine enregistré, pas le bon fonctionnement de ses emails.

Sous .fr, une table de caractères latins

La charte de nommage Afnic autorise une table de caractères latins, comprenant des lettres accentuées, mais pas de cyrillique sous .fr. Dans cette comparaison entre un nom accentué et son écriture sans accent, le seul jumeau considéré est le nom ASCII sans accent, qui reste un nom distinct ; cette comparaison ne protège pas contre d'autres ressemblances visuelles. Pour les noms trompeurs et les liens suspects hors de ce cas, consultez nos articles pour reconnaître un email de phishing et examiner les redirections et les liens suspects.

Un accent avant l'arobase est un autre sujet

Dans l'exemple fictif élise@example.com, l'accent appartient à la partie locale, qui désigne la boîte ; il ne se convertit pas comme un domaine. L'internationalisation des adresses email (EAI) distingue la capacité d'échanger avec une adresse internationalisée et la possibilité de créer cette boîte chez un fournisseur. Gmail accepte l'envoi vers ces adresses et la réception depuis celles-ci, mais ses règles de création de noms d'utilisateur excluent les lettres accentuées. Pour Microsoft 365, Exchange Online annonce ces échanges avec des adresses internationalisées, tandis que les règles de création d'utilisateurs excluent les accents dans l'adresse. Le transit possible n'autorise donc pas la création d'une boîte accentuée chez ces fournisseurs, et ne garantit pas la compatibilité de chaque intermédiaire.

Le certificat utilise aussi la forme ASCII du domaine

Le champ dNSName de l'extension SAN d'un certificat contient la forme ASCII du domaine internationalisé. La RFC 5280, §7.2, impose ce format pour stocker le nom. Voir xn-- dans le détail d'un certificat peut donc correspondre au domaine que le navigateur affiche avec son accent.

Un certificat couvrant le nom accentué ne couvre pas automatiquement le nom sans accent. Si un service doit présenter les deux identités, les noms couverts doivent correspondre à ce besoin. Le principe est le même que pour la messagerie : une proximité d'orthographe ne remplace pas une configuration explicite.

La CSR, ou demande de signature de certificat, sert à examiner les noms demandés avant l'émission. Elle ne prouve pas quels noms figurent finalement dans le certificat installé. Lors d'un diagnostic, distinguez ce qui a été demandé de ce que le serveur présente réellement : une CSR correcte peut avoir été suivie de l'installation d'un autre certificat.

Le parseur CaptainDNS signale comme invalide une forme Unicode brute dans un SAN dNSName et affiche l'Unicode à côté d'une forme xn-- correcte. Vous pouvez examiner les noms du certificat dans la CSR pour contrôler cette écriture. Cette vérification porte sur la demande, sans conclusion sur les réglages SPF ou DMARC du domaine.

Ce que cet article n'est pas

Cet article aide à identifier le domaine auquel appartiennent vos réglages DNS et mail. Il ne déroule pas un tutoriel de conversion, un guide de liens trompeurs ou une procédure de configuration HTTP. Les pages liées traitent ces besoins séparément.

L'internationalisation complète des boîtes mail demande aussi d'autres vérifications que celles du domaine. Ici, le résultat recherché reste concret : savoir si deux écritures désignent le même nom, retrouver sa zone, puis comparer les identités effectivement utilisées par l'expéditeur. Conservez les en-têtes originaux quand le problème concerne une signature.

FAQ

Un nom de domaine avec accent est-il le même que sans accent ?

Non. Retirer l'accent change le domaine : café.fr et cafe.fr sont distincts. En revanche, café.fr et xn--caf-dma.fr sont deux écritures du même nom.

Faut-il enregistrer séparément le domaine avec accent et celui sans accent ?

Oui, si vous souhaitez détenir les deux noms et qu'ils peuvent être enregistrés. L'achat de l'un n'attribue pas automatiquement l'autre. La forme Unicode et la forme xn-- d'un même domaine correspondent, elles, à un seul enregistrement.

Pourquoi mon rapport DMARC affiche-t-il xn-- alors que j'ai configuré le nom avec accent ?

Le rapport peut afficher la représentation ASCII du domaine internationalisé configuré. Comparez les noms après conversion, puis lisez les résultats SPF, DKIM et leur alignement avec From. Le préfixe seul ne signale pas un échec.

Mes réglages SPF, DKIM et DMARC du domaine sans accent couvrent-ils aussi celui avec accent ?

Non, ces noms ont des configurations indépendantes. Vous pouvez configurer les mêmes services pour les deux, mais les publications DNS et les identités d'envoi doivent correspondre à chaque domaine. Aucun partage ne découle du retrait de l'accent.

Puis-je saisir mon domaine avec accent dans un outil de vérification DNS ou DMARC ?

Oui, dans le DNS lookup et le contrôle DMARC de CaptainDNS : ils acceptent cette saisie et interrogent la forme ASCII correspondante. Vérifiez le nom complet affiché dans le résultat. Un contrôle DNS réussi ne remplace pas l'analyse d'un message envoyé.

Un accent dans le domaine d'une adresse email est-il équivalent à un accent avant l'arobase ?

Non. Après l'arobase, l'accent appartient au domaine, qui possède une représentation ASCII. Avant l'arobase, il appartient à la partie locale de la boîte et relève de l'EAI ainsi que des capacités du fournisseur de messagerie.

Quelle forme du domaine faut-il utiliser dans le certificat ?

Le SAN dNSName utilise la forme ASCII du domaine internationalisé. Un logiciel peut afficher l'Unicode à côté pour faciliter la lecture. Vérifiez séparément les noms demandés dans la CSR et ceux du certificat installé.

Sources

• RFC 8616 - règles DNS, SPF, DKIM et DMARC pour le courrier internationalisé, §3 à §6.
• Afnic - charte de nommage du 6 juillet 2026, article 2.2, caractères autorisés.
• RFC 5280 - noms internationalisés dans le champ dNSName des certificats, §7.2.
• Aide Gmail - caractères autorisés à la création d'un nom d'utilisateur.
• RFC 9989 - domaines authentifiés et alignement DMARC, §4.4.