Nombre de dominio con o sin acento: qué cambia para tu correo

⚡TL;DR

• Conserva el acento para identificar el dominio: café.fr y cafe.fr son dos nombres distintos, con configuraciones independientes.
• Relaciona café.fr con xn--caf-dma.fr: son dos representaciones del mismo nombre, sin un segundo registro que pagar.
• Para un correo, anota el dominio del sobre SPF, el dominio d= de DKIM y el de la dirección From antes de comparar sus resultados.
• Comprueba el nombre consultado en el DNS: ver xn-- en un informe DMARC no demuestra un problema de alineación.

Has configurado un dominio con acento. Unos días después, un informe de correo muestra un nombre que empieza por xn--. Buscas entonces un dominio desconocido en tu cuenta, o quitas el acento para recuperar una escritura más familiar. Estas dos reacciones conducen a errores diferentes.

En el primer caso, separas dos representaciones del mismo nombre. En el segundo, sustituyes el nombre por otro. Para el DNS y el correo, una é no es un adorno que se pueda borrar. café.fr corresponde a xn--caf-dma.fr; el nombre cafe.fr, sin acento, tiene otra identidad.

Esta distinción determina en qué zona debes buscar tus ajustes y qué dominios autentican los destinatarios. También explica por qué una interfaz legible y un registro técnico pueden parecer contradictorios. Los nombres anteriores solo sirven para comparar escrituras: este artículo no describe sus titulares, sus servicios ni sus registros reales.

Quitar el acento cambia el nombre de dominio

café.fr y xn--caf-dma.fr designan el mismo nombre; cafe.fr es otro dominio. La primera pareja relaciona una forma Unicode, legible con su acento, y su representación ASCII. La segunda comparación cambia la ortografía. Ningún mecanismo del DNS vincula automáticamente las configuraciones de los nombres con y sin acento.

Dos representaciones del mismo nombre, pero dos nombres si desaparece el acento

La forma ASCII técnica conserva la identidad del nombre acentuado. Por tanto, no es el resultado de eliminar los acentos. Las letras, los números y los guiones de xn--caf-dma.fr representan ese nombre concreto, y el prefijo forma parte de la escritura que debes conservar. Copiar solo el final de esa cadena no tiene sentido para localizar el dominio.

Al registrar un dominio, esta distinción evita contar dos veces la misma compra. Una interfaz puede mostrarte el nombre acentuado durante el pedido y después su forma xn-- en el resumen. Ambas etiquetas pueden designar un único dominio registrado. Tener el nombre sin acento no te asigna automáticamente el que lleva acento, ni a la inversa. Si quieres utilizar ambos nombres, su registro y su configuración se gestionan por separado.

El mismo razonamiento se aplica a los servicios. Una organización que controla dos nombres puede elegir el mismo alojamiento DNS y el mismo proveedor de correo. Incluso puede hacer que las direcciones correspondientes entreguen los mensajes en un único buzón. Son decisiones de configuración explícitas. Quitar un acento no crea ese buzón, ni un alias de correo, ni una copia de los registros.

Imagina dos dominios de tu organización, uno acentuado y otro no. El segundo ya recibe correo, mientras que el primero acaba de registrarse. Añadir una dirección acentuada a tus documentos comerciales no configura su recepción. El proveedor de correo debe conocer ese dominio, y sus ajustes DNS deben corresponder al uso previsto. La existencia del servicio en el otro nombre no cubre esa carencia.

El esquema representa, por tanto, dos zonas ilustrativas independientes. Esto no obliga a utilizar dos proveedores ni dos servidores físicos: una misma infraestructura puede alojar varias zonas. La independencia afecta a los nombres y a sus datos. Un cambio aplicado a uno no se propaga al otro por semejanza ortográfica.

El nombre que aparece en la zona DNS y los registros de actividad

La forma xn-- ofrece una referencia común para relacionar una zona DNS, un registro de actividad y una interfaz que muestra el acento. Identifica el nombre internacionalizado sin cambiar su dominio.

En una consola DNS, el título de la zona puede aparecer en Unicode. Una exportación o un registro de consultas puede utilizar su forma ASCII. Antes de buscar un registro que falta, compara los nombres completos. Quizá hayas abierto la zona correcta con otra presentación, o una zona realmente distinta cuyo nombre ha perdido el acento.

El nombre de la zona y el de un registro no siempre se muestran juntos. Algunas consolas esperan un nombre relativo y añaden la zona actual. En una zona ficticia example.com, introducir _dmarc puede designar _dmarc.example.com. La etiqueta corta _dmarc parece idéntica en dos consolas; sin embargo, el nombre completo depende de la zona abierta. Ese nombre completo permite saber qué política has modificado.

Un ejemplo de documentación, sin valores procedentes de un dominio ajeno, muestra la diferencia:

Zona abierta: example.com
Nombre relativo: _dmarc
Nombre completo: _dmarc.example.com
Tipo solicitado: TXT

Aplica esta lectura a tus propios nombres con acento. Si la interfaz muestra la zona en Unicode y el nombre completo en ASCII, verifica que se correspondan antes de crear una segunda entrada. Añadir un registro para corregir una simple diferencia de presentación puede introducir un duplicado; publicarlo en el dominio sin acento dejaría intacta la zona prevista.

El contenido de un registro de actividad también necesita contexto. El nombre consultado, el tipo solicitado y la respuesta recibida describen una operación concreta. La ausencia de TXT no significa automáticamente que el dominio no exista. Un error de resolución no indica que se haya rechazado el acento. Conserva el nombre exacto y el resultado: sustituirlos por una aproximación reduce la fiabilidad del diagnóstico.

En una solicitud de soporte, incluye la escritura introducida y la forma ASCII correspondiente, además del nombre completo del registro afectado. Añade la fecha de la observación si acabas de modificar la zona. Estos datos distinguen una confusión de nombres de una respuesta antigua que sigue en caché. Ningún tiempo de espera hará aparecer una corrección en una zona que no has modificado.

Por último, convertir un nombre no consulta el DNS. La conversión puede producir una forma ASCII correcta sin demostrar que el dominio esté registrado, tenga una zona publicada o reciba correo. Estas preguntas requieren comprobaciones distintas. Saber escribir un destino no demuestra que un servicio responda en él.

SPF, DKIM y DMARC: comprobar el dominio correcto para tu correo

Las comprobaciones de correo utilizan varias identidades de dominio, cuya escritura depende de la etapa del procesamiento. La RFC 8616 especifica por separado las reglas del DNS, SPF, DKIM y DMARC. Confundir estas etapas puede llevarte a buscar una clave en la zona equivocada o a modificar un encabezado que debías conservar.

Para seguir el texto de la RFC, conviene conocer dos términos. Un U-label es la forma Unicode de una parte internacionalizada del nombre, como café. Su A-label es la representación ASCII correspondiente, aquí xn--caf-dma. Los puntos separan las partes del dominio; fr no cambia. Este vocabulario describe dos representaciones, nunca dos registros de dominio que debas contratar.

Los nombres consultados en el DNS

La sección 3 de la RFC 8616 mantiene en ASCII las cadenas almacenadas en los registros DNS utilizados por estos protocolos. Un nombre extraído de un encabezado se convierte antes de su consulta DNS si contiene U-labels. El software que consulta un registro no puede suponer que solo un sistema de correo con encabezados internacionalizados leerá su respuesta.

Esta regla no describe el formato de todos los campos de un correo. Delimita los datos publicados y la consulta DNS. Un mismo mensaje puede contener una dirección legible en Unicode y provocar una consulta con el nombre ASCII correspondiente. En esta etapa no cambia ni el titular ni el destino.

Para leer una configuración, separa el nombre del registro y su valor. El primero responde a "¿dónde buscar?"; el segundo contiene la política o la clave. Un texto SPF perfectamente formado, guardado bajo el nombre equivocado, no será el que consulte el destinatario. Tampoco basta con tener una clave DKIM en algún lugar de tu cuenta DNS: su ubicación debe corresponder al dominio y al selector de la firma.

Estas son las ubicaciones de un caso completamente ficticio con example.com. La tabla describe nombres que consultar, sin proporcionar una configuración que puedas copiar.

Comprobación	Identidad del caso	Nombre DNS asociado
SPF	Dominio del sobre example.com	example.com, tipo TXT
DKIM	d=example.com, selector s=septembre	septembre._domainkey.example.com, tipo TXT
DMARC	Dirección From bajo example.com	_dmarc.example.com, tipo TXT

En tu sistema de correo, estos dominios pueden ser diferentes. Un proveedor puede gestionar el dominio del sobre o firmar con su propio dominio. Empieza por anotar las identidades que realmente utiliza un mensaje recibido. Buscar únicamente el nombre que aparece en la parte superior de la consola no siempre responde a la pregunta de cada protocolo.

SPF y el dominio del sobre

La sección 4 exige convertir todos los U-labels en A-labels antes de la validación SPF. El dominio presentado en EHLO ya debe estar en A-labels; el de MAIL FROM puede utilizar cualquiera de las dos formas en un intercambio internacionalizado. La conversión también se aplica a los nombres utilizados en las expansiones de macros SPF, no solo a la primera consulta.

SPF examina identidades de la sesión SMTP. EHLO presenta el servidor que envía; MAIL FROM contiene la dirección del sobre, utilizada, entre otras cosas, para las devoluciones por error. Esta última es distinta de la dirección From que el lector ve en su cliente de correo. Un dominio configurado para mostrarse no pasa a ser automáticamente el dominio que comprueba SPF.

¿Por qué debe EHLO utilizar la forma ASCII desde el principio? Este comando precede a la respuesta que anuncia si el servidor acepta la extensión necesaria para el correo internacionalizado. El software de envío todavía no dispone de esa información. El formato exigido en ese punto no determina qué formatos serán posibles en los pasos siguientes.

En un caso ficticio, una plataforma envía para example.com con un sobre bajo devoluciones.example.com. El TXT SPF que debes examinar es el del dominio del sobre utilizado, no uno elegido porque aparece en la página de inicio del sitio. Si la plataforma utiliza un dominio internacionalizado, esa misma consulta adopta su forma ASCII después de la conversión. El protocolo no prueba después el dominio sin acento como alternativa de respaldo.

Para entender un resultado SPF, identifica primero qué identidad se ha comprobado y después lee los detalles de la política. Un pass indica que la dirección IP estaba autorizada para la identidad evaluada. No certifica que esa identidad coincida con la dirección From, ni que todo el sistema de correo esté bien configurado. La comparación con From corresponde a DMARC.

Los nombres internacionalizados mencionados dentro de un registro SPF también deben escribirse en A-labels. Que una interfaz de administración acepte el acento en el nombre de la zona no autoriza a introducirlo libremente en el valor TXT. El campo de entrada del dominio y el contenido publicado cumplen funciones distintas.

Si administras ambos nombres, con y sin acento, evita copiar automáticamente las políticas. Los mismos servidores pueden estar autorizados para los dos, pero solo si los flujos de correo lo justifican. Un dominio utilizado exclusivamente para recibir no tiene necesariamente las mismas necesidades que un dominio de envío. La semejanza entre los nombres no es un inventario de tus remitentes.

DKIM y los valores firmados

La sección 5 distingue los mensajes convencionales de los mensajes con encabezados internacionalizados. Para los nombres internacionalizados de d=, de la parte de dominio de i= y de s=, los A-labels son obligatorios en los mensajes convencionales: la RFC utiliza MUST. Con encabezados internacionalizados, recomienda los U-labels (SHOULD), aunque los A-labels siguen siendo válidos.

Estas etiquetas no tienen todas la misma función. d= indica el dominio firmante, s= el selector que localiza la clave e i=, cuando aparece, una identidad con una parte local y una parte de dominio. En el ejemplo ficticio i=service@example.com, solo example.com es el dominio. La regla sobre su escritura no significa que service sea un nombre que deba convertirse de la misma manera.

La verificación DKIM incluye una consulta de clave pública en el DNS y un cálculo criptográfico sobre el mensaje. Las dos operaciones no siguen la misma regla de transformación. El nombre de consulta debe adoptar la forma que espera el DNS. Para calcular o verificar el hash, en cambio, la RFC exige utilizar el dominio tal como está escrito en el encabezado, con las reglas de canonicalización DKIM aplicables.

Esta diferencia descarta una corrección tentadora: sustituir los nombres Unicode por su forma ASCII en todo el mensaje original antes de verificar la firma. Aunque los nombres designen el mismo dominio, su representación no es idéntica en los datos firmados. La equivalencia de nombres no vuelve intercambiables dos secuencias de bytes para un cálculo criptográfico.

Supón que un mensaje con encabezados internacionalizados contiene un dominio firmante en Unicode. El verificador encuentra su clave con el nombre ASCII correspondiente y después comprueba la firma conservando la representación del encabezado. Una interfaz puede mostrar ambas formas una junto a otra para ayudar al administrador. Esa presentación no autoriza a modificar el mensaje original.

Para un diagnóstico, conserva una copia del mensaje recibido en su formato original. Una captura de pantalla en la que el cliente ha reformateado las direcciones facilita la lectura, pero no reproduce necesariamente los valores utilizados para la firma. Anota d= y s= del encabezado DKIM y busca la clave en la ubicación construida a partir de esos valores. Una clave publicada para el nombre sin acento no se convierte en la del dominio acentuado.

El selector merece tanta atención como el dominio. Dos envíos del mismo dominio pueden utilizar selectores diferentes; encontrar una clave con uno no valida la firma realizada con el otro. En el caso de example.com, septembre._domainkey.example.com y archives._domainkey.example.com son dos ubicaciones distintas. El error sería entonces un selector incorrecto, aunque la escritura del dominio fuera correcta.

DMARC y el dominio visible en From

La sección 6 exige convertir en A-labels todos los U-labels del dominio de la dirección From antes de continuar el procesamiento DMARC. También mantiene direcciones convencionales en las etiquetas de informes rua y ruf. Esta última regla se refiere a los destinos de los informes, no a la escritura permitida en cualquier parte del mensaje.

El punto de partida es el dominio de la dirección From, después de la arroba. El nombre visible de la persona, por ejemplo "Equipo comercial", no interviene en esta comparación. Ese texto puede contener un acento aunque la dirección no incluya ningún dominio internacionalizado. Abrir los detalles del remitente evita diagnosticar el elemento equivocado.

DMARC busca una autenticación SPF o DKIM correcta y alineada con ese dominio From. La alineación estricta compara los dominios exactos; la relajada tiene en cuenta el dominio organizativo. Por tanto, una diferencia de subdominio puede ser admisible según el modo elegido. Quitar un acento no es una regla de alineación relajada: no convierte dos nombres independientes en uno solo.

En la comparación de este artículo, café.fr y xn--caf-dma.fr pueden corresponderse durante el procesamiento de nombres. cafe.fr sigue siendo distinto. Poseer los dos dominios, utilizar el mismo servidor o mostrar el mismo nombre de empresa no cambia esa relación. Si tu remitente debe utilizar el nombre acentuado pero firma para el otro, corrige la configuración del flujo afectado.

Para los informes, un destino de documentación como rua=mailto:rapports@example.com muestra el formato de una dirección convencional. Si el dominio destinatario está internacionalizado, su parte de dominio utiliza la forma ASCII; añadir un acento a la parte local no respeta la regla de la sección 6. La dirección también debe poder recibir informes. Su sintaxis no crea un buzón.

Considera, por último, el caso que suele generar dudas: has configurado el nombre acentuado, pero un informe DMARC o el encabezado Authentication-Results muestra xn--caf-dma.fr. La correspondencia con la interfaz puede ser completamente correcta. Identifica qué campo contiene ese valor y lee el resultado asociado: el dominio From, el dominio SPF y el dominio firmante no son intercambiables.

Si los nombres coinciden después de la conversión, continúa con las causas señaladas por los resultados: IP no autorizada, clave no encontrada, firma inválida o identidad autenticada realmente distinta del dominio From. No reescribas tu política solo por el prefijo. Ver xn-- en lugar del acento no es, por sí solo, un error de alineación.

Qué comprueban las herramientas cuando introduces café.fr

La consulta DNS y la comprobación DMARC de CaptainDNS aceptan café.fr y consultan su forma ASCII. Para DMARC, el nombre de consulta es _dmarc.xn--caf-dma.fr. La consulta DNS muestra el Unicode junto a esa forma. La comprobación DMARC muestra el nombre consultado en ASCII. Estos nombres ilustran el procesamiento de la entrada, sin presentar resultados reales sobre ese dominio ajeno.

La consulta responde a una pregunta sobre la publicación DNS: ¿qué registros se devuelven para el nombre y el tipo solicitados? La comprobación DMARC se centra en la política publicada y su sintaxis. Ayudan a verificar la zona correcta, pero un TXT DMARC válido no demuestra que todas las plataformas de envío firmen tus mensajes con el dominio adecuado.

Este límite importa cuando cambias de proveedor. Puedes haber publicado exactamente el valor solicitado y seguir recibiendo fallos en algunos correos. La plataforma que los envía puede utilizar todavía una identidad antigua. Compara entonces la publicación DNS y los encabezados de un envío de esa plataforma. La comprobación del dominio y la del mensaje se complementan; no observan lo mismo.

Un resultado vacío también debe leerse junto al nombre solicitado. Si has introducido el dominio sin acento, la herramienta ha examinado ese nombre distinto. Si has introducido el dominio correcto, la ausencia de un registro requiere revisar su publicación. En ambos casos, la primera comprobación sigue siendo la identidad de la zona, antes de modificar cualquier valor.

Para relacionar únicamente las representaciones del nombre, el Conversor Punycode / IDN proporciona ambas formas sin consultar el DNS. Para conocer los datos publicados por la entidad gestora del registro, puedes consultar el registro del dominio con RDAP. RDAP no valida SPF ni DMARC: una ficha de registro describe el dominio registrado, no el funcionamiento correcto de su correo.

Una tabla de caracteres latinos bajo .fr

La política de nombres de Afnic permite una tabla de caracteres latinos, incluidas letras acentuadas, pero no caracteres cirílicos bajo .fr. En esta comparación entre un nombre acentuado y su escritura sin acento, solo se considera como equivalente visual el nombre ASCII sin acento, que sigue siendo un nombre distinto; esta comparación no protege frente a otras semejanzas visuales. Para nombres engañosos y enlaces sospechosos fuera de este caso, consulta nuestros artículos para reconocer un correo de phishing y examinar redirecciones y enlaces sospechosos.

Un acento antes de la arroba es otro asunto

En el ejemplo ficticio élise@example.com, el acento pertenece a la parte local que identifica el buzón; no se convierte como un dominio. La internacionalización de direcciones de correo (EAI) distingue intercambiar mensajes con una dirección internacionalizada de crear ese buzón en un proveedor. Gmail permite enviar a estas direcciones y recibir desde ellas, pero sus reglas para crear nombres de usuario excluyen letras acentuadas. En Microsoft 365, Exchange Online anuncia estos intercambios con direcciones internacionalizadas, mientras que las reglas de creación de usuarios excluyen acentos en la dirección. Que el tránsito sea posible no autoriza a crear un buzón acentuado en estos proveedores ni garantiza la compatibilidad de cada intermediario.

El certificado también utiliza la forma ASCII del dominio

El campo dNSName de la extensión SAN de un certificado contiene la forma ASCII del dominio internacionalizado. La RFC 5280, sección 7.2, exige ese formato para almacenar el nombre. Ver xn-- en los detalles de un certificado puede, por tanto, corresponder al dominio que el navegador muestra con su acento.

Un certificado que cubre el nombre acentuado no cubre automáticamente el nombre sin acento. Si un servicio debe presentar ambas identidades, los nombres cubiertos deben responder a esa necesidad. El principio es el mismo que para el correo: una semejanza ortográfica no sustituye una configuración explícita.

La CSR, o solicitud de firma de certificado, permite examinar los nombres solicitados antes de la emisión. No demuestra qué nombres aparecen finalmente en el certificado instalado. Durante un diagnóstico, distingue lo que se solicitó de lo que realmente presenta el servidor: tras una CSR correcta puede haberse instalado otro certificado.

El analizador de CaptainDNS marca como inválida una forma Unicode sin convertir en un SAN dNSName y muestra el Unicode junto a una forma xn-- correcta. Puedes examinar los nombres del certificado en la CSR para comprobar esa escritura. Esta verificación se refiere a la solicitud y no permite concluir nada sobre los ajustes SPF o DMARC del dominio.

Qué queda fuera de este artículo

Este artículo ayuda a identificar el dominio al que pertenecen tus ajustes DNS y de correo. No desarrolla un tutorial de conversión, una guía sobre enlaces engañosos ni un procedimiento de configuración HTTP. Las páginas enlazadas tratan esas necesidades por separado.

La internacionalización completa de los buzones también requiere otras comprobaciones aparte de las del dominio. Aquí se busca un resultado concreto: saber si dos representaciones designan el mismo nombre, localizar su zona y comparar las identidades que realmente utiliza el remitente. Conserva los encabezados originales cuando el problema afecte a una firma.

FAQ

¿Un nombre de dominio con acento es el mismo que sin acento?

No. Quitar el acento cambia el dominio: café.fr y cafe.fr son distintos. En cambio, café.fr y xn--caf-dma.fr son dos representaciones del mismo nombre.

¿Hay que registrar por separado el dominio con acento y el dominio sin acento?

Sí, si quieres tener ambos nombres y están disponibles para su registro. Comprar uno no te asigna automáticamente el otro. Las formas Unicode y xn-- de un mismo dominio corresponden, en cambio, a un único registro.

¿Por qué mi informe DMARC muestra xn-- si he configurado el nombre con acento?

El informe puede mostrar la representación ASCII del dominio internacionalizado configurado. Compara los nombres después de la conversión y lee los resultados SPF, DKIM y su alineación con From. El prefijo por sí solo no indica un fallo.

¿Mis ajustes SPF, DKIM y DMARC del dominio sin acento también cubren el dominio acentuado?

No, estos nombres tienen configuraciones independientes. Puedes configurar los mismos servicios para ambos, pero las publicaciones DNS y las identidades de envío deben corresponder a cada dominio. Quitar el acento no hace que compartan ajustes.

¿Puedo introducir mi dominio con acento en una herramienta de comprobación DNS o DMARC?

Sí, en la consulta DNS y la comprobación DMARC de CaptainDNS: aceptan esa entrada y consultan la forma ASCII correspondiente. Revisa el nombre completo que aparece en el resultado. Una comprobación DNS correcta no sustituye el análisis de un mensaje enviado.

¿Un acento en el dominio de una dirección de correo equivale a un acento antes de la arroba?

No. Después de la arroba, el acento pertenece al dominio, que tiene una representación ASCII. Antes de la arroba, pertenece a la parte local del buzón y depende de EAI y de las capacidades del proveedor de correo.

¿Qué forma del dominio debe utilizarse en el certificado?

El SAN dNSName utiliza la forma ASCII del dominio internacionalizado. Un programa puede mostrar el Unicode al lado para facilitar la lectura. Comprueba por separado los nombres solicitados en la CSR y los del certificado instalado.

Fuentes

• RFC 8616 - reglas DNS, SPF, DKIM y DMARC para correo internacionalizado, secciones 3 a 6.
• Afnic - política de nombres del 6 de julio de 2026, artículo 2.2, caracteres permitidos.
• RFC 5280 - nombres internacionalizados en el campo dNSName de certificados, sección 7.2.
• Ayuda de Gmail - caracteres permitidos al crear un nombre de usuario.
• RFC 9989 - dominios autenticados y alineación DMARC, sección 4.4.