Una buena solución de problemas de registros DNS para correo comienza con un hecho incómodo: cuando SPF, DKIM o un CNAME de seguimiento no se verifica, la causa rara vez es el registro que pretendías publicar. Casi siempre es la forma en que tu panel DNS lo almacenó. Una clave de más de 255 caracteres, un nombre de dominio añadido dos veces, un par de comillas que pasó a formar parte del valor, un segundo registro SPF o una respuesta antigua que aún no ha caducado en una caché. Repasaremos cada uno de estos casos, mostraremos cómo comprobarlos con dig y nslookup y terminaremos con una tabla que puedes usar según el síntoma.
Cómo viven los registros de correo en el DNS
Todos los métodos de autenticación de correo se apoyan en unos pocos tipos de registro. SPF y DKIM se publican como registros TXT, DMARC es un registro TXT en un nombre que empieza por _dmarc, y muchas plataformas de envío piden registros CNAME para un nombre de host de return-path o de seguimiento. Los registros MX dirigen el correo entrante. Un resolvedor pide un nombre y un tipo, y la respuesta incluye un tiempo de vida, o TTL, que indica a cada caché durante cuánto tiempo puede reutilizarla.
Tres detalles explican la mayoría de los problemas. Primero, los paneles DNS son interfaces amigables sobre una zona, y cada uno toma sus propias decisiones sobre nombres, comillas y división de valores. Segundo, hay cachés en varias capas, así que durante un tiempo el mismo nombre puede dar respuestas distintas en lugares distintos. Tercero, algunos tipos de registro se excluyen entre sí en el mismo nombre. Cubrimos el conjunto completo de registros en nuestra guía de autenticación y el flujo de verificación en cómo verificar tu dominio de envío. Este artículo es su complemento de diagnóstico.
Comprueba primero el lugar correcto: los servidores de nombres autoritativos
Antes de cambiar nada, averigua qué está publicado realmente. Un resolvedor público, como el que usa tu portátil, puede conservar una respuesta antigua. Los servidores de nombres autoritativos son los que alojan tu zona y dan la respuesta definitiva, por eso siempre les preguntamos a ellos primero.
# 1. Find the authoritative nameservers for the domain
dig NS example.com +short
# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer
# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer
# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer
# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.exampleSi la respuesta autoritativa es incorrecta, el problema está en el panel: corrige el registro. Si la respuesta autoritativa es correcta y la del resolvedor público es distinta, el problema es una caché: espera. Si ambas son correctas y la verificación sigue fallando, probablemente estás comprobando el nombre equivocado o la plataforma espera un tipo de registro distinto. Esta única comparación elimina más conjeturas que cualquier otra cosa de este artículo.
Consejo: Comprueba desde una máquina que no use tu propia caché DNS y recuerda que el resultado de un verificador web refleja el resolvedor de ese verificador, no el tuyo.
Cadenas TXT de más de 255 caracteres y claves DKIM de 2048 bits
Un registro TXT contiene una o más cadenas de caracteres, y cada cadena está limitada a 255 bytes. Esto proviene del formato original del DNS en la RFC 1035, que almacena cada cadena con una longitud de un byte. Un registro puede contener varias cadenas y, tanto en SPF como en DKIM, el receptor las une en orden sin añadir espacios. Las especificaciones de ambos lo establecen así (RFC 7208 para SPF, RFC 6376 para DKIM).
El impacto práctico se da en DKIM. Una clave pública RSA de 1024 bits en base64 queda cerca del límite una vez que se añaden las etiquetas de versión y tipo de clave, mientras que una clave de 2048 bits es aproximadamente el doble de larga, de modo que solo el valor p= ya ocupa varios cientos de caracteres. Debe almacenarse como más de una cadena. Nuestra guía sobre rotación de claves DKIM, selectores y longitud de clave explica por qué las claves de 2048 bits merecen el esfuerzo.
| Cómo se comporta tu panel | Qué debes hacer | Cómo verificarlo |
|---|---|---|
| Divide automáticamente los valores largos | Pega el valor completo una sola vez, sin comillas ni saltos de línea | dig muestra varias cadenas entre comillas que juntas forman la clave completa |
| Espera que introduzcas fragmentos entre comillas | Divide en cualquier punto por debajo de 255 caracteres, encierra cada parte entre comillas y sepáralas con un solo espacio | El texto unido es exactamente igual a la clave original |
| Rechaza valores de más de 255 caracteres | Busca un ajuste para registros largos o un modo de edición distinto; consulta a tu proveedor si no existe ninguno | La consulta devuelve la clave completa, no una truncada |
| Trunca el valor en silencio | Vuelve a introducirlo en fragmentos y lee el resultado | Una clave que termina antes de tiempo hace fallar DKIM con un error de clave o de sintaxis |
Cómo se ve una división correcta
El siguiente ejemplo muestra la forma de un registro dividido. El texto de la clave es inventado y está abreviado para ilustrar. En un registro real, los fragmentos suman la clave completa que te proporciona tu plataforma.
selector1._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"IDAQAB" )Hay dos trampas habituales. No añadas un espacio dentro de la clave al dividirla, porque el receptor concatena las cadenas y el espacio pasaría a formar parte de la clave. Y no cortes el registro por la mitad del nombre del selector ni de las etiquetas. Si una clave dividida falla, compara el resultado unido con el original, carácter por carácter, usando una herramienta de diferencias de texto en lugar de tus ojos.
Rarezas de los registradores y de los paneles DNS
El mismo registro puede introducirse de cuatro maneras distintas en cuatro paneles. Estas son las rarezas que vemos con más frecuencia.
El dominio se añade dos veces
Muchos paneles añaden automáticamente el nombre de la zona. Si escribes selector1._domainkey.example.com en el campo de host, el panel puede almacenar selector1._domainkey.example.com.example.com. El síntoma es que el registro existe en el panel, pero la consulta del nombre correcto no devuelve nada. Introduce solo la parte relativa, selector1._domainkey, y usa @ o deja el campo vacío para el apex, según el panel. Un punto final normalmente marca un nombre como completamente cualificado en los archivos de zona, pero los paneles web difieren, así que lee el nombre guardado con dig.
Comillas, saltos de línea y caracteres invisibles
Al copiar un valor de una página web o un documento pueden colarse comillas tipográficas, espacios de no separación o un salto de línea. Si además el panel añade sus propias comillas, puedes acabar con un carácter de comilla literal al inicio del valor, y un registro que comienza con una comilla no empieza por v=spf1 ni v=DKIM1, por lo que no se reconoce. Pega primero en un editor de texto plano, después en el panel, y lee el resultado.
El tipo de registro o el nombre equivocado
A veces las plataformas piden un registro TXT donde esperarías un CNAME, o al revés. Usa el tipo exactamente como se indica. Comprueba también que estás en la zona correcta: si el dominio usa servidores de nombres de un proveedor, pero editaste la zona en tu registrador, la modificación nunca se sirve. La consulta NS mostrada antes te dice dónde está la zona activa.
| Síntoma en el panel | Causa probable | Solución |
|---|---|---|
| El registro muestra el dominio dos veces en el nombre | El panel añadió la zona a un nombre completo | Introduce solo el nombre relativo |
| El valor empieza y termina con comillas solo en la salida de la consulta | Es normal en la salida TXT de dig | No hace falta ningún cambio |
| El valor contiene comillas escapadas o una comilla al inicio | Añadiste comillas y el panel añadió las suyas | Quita tus comillas |
| El registro se guarda, pero la consulta no devuelve nada | Editaste una zona que los servidores de nombres activos no sirven | Edita la zona en el proveedor indicado por los registros NS |
| El panel no acepta un guion bajo en el nombre | Regla de validación de nombres del panel | Usa otro modo de edición o consulta al proveedor de DNS |
CNAME en el apex, aplanamiento y conflictos entre registros
Un CNAME indica que un nombre es un alias de otro nombre, de modo que el resolvedor debe seguirlo y usar las respuestas de ese destino. Por esa razón, un CNAME no puede coexistir con ningún otro registro en el mismo nombre (RFC 1034 y RFC 2181). La raíz de tu dominio, el apex, debe llevar registros SOA y NS, y normalmente también MX y TXT, por lo que un CNAME en el apex no es válido.
Algunos proveedores de DNS evitan esta limitación con el aplanamiento o con un tipo de registro de alias. El proveedor resuelve el destino por su cuenta y devuelve registros de direcciones normales en el apex. Esto ayuda a apuntar tu dirección web raíz a un servicio alojado. No ayuda con la autenticación de correo. Si una plataforma pide un CNAME en un nombre de host como un subdominio, colócalo en ese subdominio. Si una plataforma pide un CNAME en el dominio desnudo, solicítale una alternativa, como TXT y registros de direcciones.
El conflicto también funciona a la inversa. Si añades un CNAME para un nombre que ya tiene un registro TXT, por ejemplo un selector DKIM que publicaste antes como TXT, uno de los dos será rechazado o ignorado, según el panel. Elimina el registro antiguo antes de añadir el CNAME. Esta situación es común al cambiar de proveedor, y nuestra guía de migración explica el orden de los pasos.
Registros SPF duplicados y otros duplicados
Un dominio solo puede publicar un registro SPF, que es un registro TXT que comienza por v=spf1. Si los receptores encuentran dos, el resultado es un error permanente (RFC 7208) y SPF falla para todos los mensajes, no solo para los de un proveedor. Esto ocurre cuando dos equipos añaden cada uno el registro que pidió su proveedor.
| Situación | Qué ven los receptores | Solución |
|---|---|---|
| Dos registros TXT que empiezan ambos por v=spf1 | Error permanente, SPF no pasa | Combínalos en un solo registro con todos los mecanismos include |
| Un registro con más de 10 consultas | Error permanente tras el límite de consultas | Aplana o elimina includes; consulta la guía de consultas SPF |
| Dos registros DMARC en _dmarc | La política puede ignorarse | Conserva un solo registro |
| El mismo selector publicado dos veces con claves distintas | Selección de clave impredecible | Elimina la clave antigua o usa un selector nuevo |
Combinar es sencillo en principio: toma los mecanismos include e ip4 de cada registro, colócalos en un solo registro v=spf1 y termina con un único calificador all. Lo más difícil es el recuento de consultas, que explicamos en la guía del permerror de SPF y en cómo gestionar varios proveedores en un mismo dominio.
Registros con proxy: desactiva el proxy DNS para el correo
Algunos proveedores de DNS ofrecen un modo proxy, a menudo representado con un icono de nube de color junto al registro. En este modo, el proveedor responde a las consultas del nombre con sus propias direcciones y hace pasar el tráfico web por su red. Eso es útil para sitios web y poco útil para el correo.
Si un CNAME relacionado con el correo pasa por proxy, la consulta ya no devuelve el destino que espera tu plataforma de envío. La verificación falla, los nombres de host de seguimiento o de return-path no se resuelven en el servidor correcto y es posible que no se emitan los certificados HTTPS de los dominios de seguimiento. Un nombre de host de servidor de correo con proxy no aceptará conexiones SMTP en absoluto, porque el proxy gestiona puertos web y no de correo. Por eso, configura todos los registros relacionados con el correo en modo solo DNS: destinos MX, registros A de servidores de correo, CNAME de nombres de host de return-path y de seguimiento, y CNAME de DKIM. Los registros TXT nunca pasan por proxy, por lo que no se ven afectados. Nuestra guía sobre dominios de return-path y de seguimiento explica por qué esos nombres de host deben resolverse directamente hacia la plataforma.
Comprobación: Una consulta dig de un nombre con proxy devuelve direcciones que no pertenecen a tu plataforma aunque hayas guardado un CNAME. Esa es la señal de que el proxy está activado.
Elección del TTL y planificación de cambios
El TTL es el número de segundos que un resolvedor puede conservar una respuesta. Un TTL largo reduce las consultas y hace que el registro sea más resistente si tus servidores de nombres dejan de estar disponibles brevemente. Un TTL corto permite recuperarse rápido de un error. El enfoque sensato es variarlo según la fase.
| Fase | TTL sugerido | Por qué |
|---|---|---|
| Creación o prueba de un registro nuevo | 300 a 600 segundos | Las correcciones se ven rápido |
| Antes de un cambio planificado | Reduce el TTL con bastante antelación al cambio, al menos tanto como el TTL actual | Las cachés antiguas caducan antes de que hagas el cambio |
| El día del cambio | Manténlo corto | Puedes revertir |
| Registros estables | De 3600 segundos hasta un día | Menos consultas y menor exposición a caídas |
El punto clave de la planificación de cambios es que reducir un TTL no ayuda al instante. Las cachés que ya conservan el registro lo mantienen durante el TTL anterior. Si un registro tiene un TTL de 86400 segundos, redúcelo al menos un día antes del cambio. Después cambia el valor, espera, verifica y vuelve a aumentar el TTL.
Propagación y caché negativa
Los cambios de DNS no se extienden desde un único punto. No existe una difusión global. Lo que la gente llama propagación es simplemente el tiempo que tardan en caducar las cachés. Los servidores autoritativos responden con el nuevo valor en cuanto la zona se guarda y se carga, y cada resolvedor cambia cuando termina su copia en caché. Algunos resolvedores ignoran TTL muy bajos o conservan las respuestas un poco más, así que deja un margen.
Hay una segunda caché que es fácil olvidar: la caché negativa. Si un resolvedor preguntó por un nombre que aún no existía, recuerda la respuesta de «no encontrado», y la RFC 2308 establece que el tiempo se basa en el registro SOA (el menor entre el TTL del SOA y su campo mínimo). Si tu plataforma comprobó el registro unos minutos antes de que lo añadieras, el fallo puede permanecer en caché hasta que ese tiempo termine, aunque el registro ya exista.
Un ejemplo práctico
Imagina un dominio cuyo registro TXT de DKIM se publicó a las 10:00 con un TTL de 3600 segundos y un tiempo de caché negativa del SOA de 900 segundos. A las 10:05 la plataforma comprueba demasiado pronto y recibe «no encontrado», de modo que ese resolvedor guarda el fallo en caché hasta las 10:20 aproximadamente. A las 10:10 notas un error tipográfico, corriges la clave y la guardas. Los servidores autoritativos ya dan la nueva respuesta. Un resolvedor que guardó el primer registro a las 10:00 puede seguir sirviendo el antiguo hasta las 11:00. Uno que guardó «no encontrado» puede seguir sirviéndolo hasta las 10:20. Así, un resultado totalmente limpio en todos los resolvedores podría tardar hasta las 11:00, pero una comprobación que vaya directamente a los servidores autoritativos pasa a las 10:10. En este caso, usas el resultado autoritativo para confirmar que tu edición es correcta y luego esperas el mayor tiempo de caché, 60 minutos, antes de volver a pulsar el botón de verificación.
Cuando la plataforma reintenta las comprobaciones automáticamente, es posible que no tengas que hacer nada. Cuando solo comprueba al pulsar un botón, espera el mayor periodo de caché que hayas calculado. No vuelvas a cambiar el registro mientras esperas, porque cada cambio reinicia el reloj de las cachés que se actualizan.
Una tabla de diagnóstico por síntoma
| Síntoma | Causa más probable | Primera comprobación | Solución |
|---|---|---|---|
| La plataforma dice que no encuentra el registro DKIM | Nombre duplicado, zona equivocada o aún sin propagar | Ejecuta dig con el nombre exacto del selector en el servidor autoritativo | Corrige el campo de host o espera a las cachés |
| DKIM se verifica, pero la firma falla con un error de clave | Clave truncada o dividida con un espacio | Une las cadenas TXT y compáralas con el original | Vuelve a introducirla en fragmentos sin espacios |
| SPF devuelve permerror | Dos registros SPF o más de 10 consultas | Ejecuta dig TXT en el apex y cuenta los registros v=spf1 | Combina los registros, reduce las consultas |
| El registro SPF parece ignorado | Comilla literal o espacio inicial en el valor | Busca un valor que no empiece por v=spf1 | Elimina los caracteres sobrantes |
| El CNAME no se guarda | Existe otro registro en ese nombre, o el nombre es el apex | Lista todos los tipos de registro del nombre | Elimina el conflicto o usa un subdominio |
| El CNAME existe, pero la verificación falla | Proxy DNS activado o destino mal escrito | ¿dig devuelve el destino esperado? | Configura solo DNS, corrige el destino |
| Funciona en tu ordenador, pero falla en la plataforma | Cachés de resolvedores distintas | Consulta el servidor autoritativo y dos resolvedores públicos | Espera al TTL anterior |
| El registro existe, pero la comprobación sigue indicando que no se encuentra | Caché negativa | Revisa los valores del SOA y la hora de la primera comprobación | Espera el tiempo de caché negativa |
| El informe DMARC no muestra ninguna política | Registro en el nombre equivocado | Comprueba que el nombre empiece por _dmarc | Muévelo a _dmarc.tudominio |
Los problemas a nivel de encabezado, a diferencia de los de nivel de registro, son más fáciles de confirmar en el propio mensaje. Consulta cómo leer los encabezados de correo para saber qué significan los resultados de autenticación una vez que el DNS es correcto.
Una rutina práctica que puedes repetir
- Identifica. Anota el nombre y el tipo exactos que pide tu plataforma.
- Localiza. Encuentra los servidores de nombres activos con una consulta NS y confirma que estás editando esa zona.
- Introduce. Usa el nombre de host relativo, pega el valor sin añadir comillas y divide las cadenas largas solo si tu panel lo necesita.
- Vuelve a leer. Consulta el servidor autoritativo y compara el resultado con el original.
- Limpia. Elimina duplicados, selectores antiguos con el mismo nombre y tipos de registro en conflicto.
- Proxy desactivado. Confirma que los registros relacionados con el correo están en modo solo DNS.
- Espera con criterio. Calcula el mayor valor entre el TTL anterior y el tiempo de caché negativa.
- Verifica. Ejecuta la comprobación de la plataforma y envía un mensaje de prueba. Consulta tu cuenta de MigoSMTP o la documentación de la API para conocer los nombres y valores exactos de los registros que debes publicar.
Lista de comprobación antes de pedir ayuda
- El nombre del registro se leyó desde el servidor de nombres autoritativo y coincide exactamente con lo que pidió la plataforma.
- Ningún sufijo de dominio aparece dos veces en el nombre almacenado.
- El valor no tiene comillas pegadas, saltos de línea ni espacios dentro de las claves largas.
- Los valores TXT largos están completos al unir las cadenas.
- Solo existe un registro SPF en el nombre y el número de consultas está dentro del límite.
- Ningún CNAME comparte nombre con otro registro y ningún CNAME está en el apex.
- Todos los registros relacionados con el correo están en modo solo DNS, sin proxy.
- Has esperado el TTL anterior y el tiempo de caché negativa antes de volver a comprobar.
- La zona que editaste es la que señalan los registros NS.
¿Tienes un registro que no se verifica? Envíanos el nombre del registro, el valor exacto que publicaste y el resultado de una consulta dig a tu servidor de nombres autoritativo, y te ayudaremos a encontrar la diferencia.
Lecturas adicionales y fuentes
Preguntas frecuentes
¿Por qué mi registro DKIM indica que es demasiado largo?
Una única cadena de caracteres de DNS puede contener como máximo 255 bytes, y una clave pública RSA de 2048 bits en base64 es más larga que eso. El registro en sí puede contener varias cadenas, y los receptores las unen sin espacios. Algunos paneles dividen el valor por ti, otros te piden que introduzcas fragmentos entre comillas y otros rechazan directamente un valor largo. Comprueba cómo lo gestiona tu panel y verifica el resultado con una consulta TXT.
¿Debo poner comillas alrededor del valor TXT?
Depende del panel. Muchos formularios web añaden las comillas por ti, de modo que si añades las tuyas se genera un carácter de comilla literal en el valor y el registro no se interpreta correctamente. Los editores de archivos de zona y algunas herramientas de línea de comandos sí esperan comillas. Lee el registro con dig después de guardarlo y, si ves comillas duplicadas o escapadas, quita las tuyas.
¿Por qué mi registro terminó como selector._domainkey.example.com.example.com?
El panel añade tu dominio a lo que escribas en el campo de host. Si introduces el nombre completo, el dominio se añade dos veces. Escribe solo la parte anterior a tu dominio, como selector._domainkey, o sigue la indicación que muestre el panel. Un punto final suele indicar al panel que el nombre está completo, pero no todos los paneles lo interpretan así, así que haz la prueba con una consulta.
¿Puedo poner un CNAME en mi dominio raíz?
El DNS estándar no lo permite, porque un CNAME no puede compartir nombre con otros registros y el dominio raíz debe llevar registros SOA y NS. Algunos proveedores ofrecen una función de aplanamiento o de alias que devuelve registros de direcciones en la raíz. Úsala para el tráfico web si la necesitas, pero no como sustituto de los registros TXT y MX que el correo requiere en la raíz.
Tengo dos registros SPF. ¿De verdad es un problema?
Sí. Un dominio debe publicar un único registro SPF, y los receptores que encuentran más de uno devuelven un error permanente en lugar de elegir uno. Combina los mecanismos en un solo registro. Nuestra guía sobre varios proveedores en un mismo dominio explica cómo hacerlo sin superar el límite de consultas.
¿Qué TTL debo configurar?
Usa un TTL corto, de 300 a 3600 segundos, mientras creas o modificas registros, y uno más largo, de varias horas a un día, cuando todo esté estable. La cifra adecuada es un equilibrio entre la rapidez con la que puedes revertir un cambio y la carga que generas en tus servidores de nombres.
Corregí el registro, pero la comprobación sigue fallando. ¿Por qué?
O bien un resolvedor sigue conservando la respuesta antigua hasta que expire su TTL, o conserva en caché una respuesta de «no encontrado» hasta que termine el tiempo de caché negativa, o estás comprobando un nombre distinto del que consulta la plataforma. Consulta los servidores de nombres autoritativos para ver la realidad y luego espera a que se actualicen las cachés.
¿Por qué los CNAME de correo no deben pasar por proxy?
Un proxy DNS responde a las consultas con sus propias direcciones en lugar del destino real de tu registro. Una plataforma de correo necesita ver el destino del CNAME o la dirección real del servidor, por lo que un registro con proxy no supera la verificación y puede romper el seguimiento o la gestión de rebotes. Configura esos registros en «solo DNS».
¿En qué herramienta debo confiar: dig, nslookup o un verificador web?
Todas sirven si sabes qué consultan. dig y nslookup te permiten elegir el servidor, que es la clave para distinguir un problema de publicación de uno de caché. Los verificadores web suelen consultar desde una sola ubicación a través de un resolvedor público, así que una diferencia con tu resultado local normalmente solo significa cachés distintas.