Correo: registros DNS mixtos — la errata que mata la entrega (y la solución)

Qué significa realmente “registros DNS mixtos” (y por qué el correo sufre primero)

“Registros DNS mixtos” no es un término formal de un RFC. Es la forma SRE de decir: los datos DNS que publica tu dominio son internamente inconsistentes, están parcialmente migrados o son visiblemente variables entre resolutores. A veces es porque estás en medio de un corte. A veces es porque alguien pegó las guías de configuración de dos proveedores en la misma zona. A veces es porque tu DNS interno tiene sobrescrituras “útiles” que hacen que las pruebas pasen desde dentro de la oficina y fallen en todas partes fuera.

El correo es donde esto se rompe primero porque el enrutamiento y la confianza en el correo son una pila de consultas DNS, no una sola. El tráfico web normalmente se preocupa por A/AAAA y quizá CAA. El correo se preocupa por MX, luego A/AAAA para los destinos MX, además de registros TXT de SPF, registros TXT de DKIM, registros TXT de DMARC, reversa DNS para la IP que se conecta, y cada vez más MTA-STS o reportes TLS. Mezcla cualquiera de estas piezas incorrectamente y el sistema todavía “más o menos funciona” hasta que te encuentras con el gran proveedor que hace cumplir la parte que arruinaste.

Los tres patrones más comunes de “registro mixto”

• Enrutamiento dividido: múltiples hosts MX de diferentes proveedores presentes a la vez (o MX antiguo más MX nuevo), de modo que el correo entrante va al lugar equivocado algunas veces.
• Autorización dividida: SPF dice que el Proveedor A está autorizado, pero en realidad envías desde el Proveedor B (o tu propio MTA). O SPF es sintácticamente válido pero lógicamente roto (demasiadas búsquedas DNS, calificadores equivocados).
• Identidad dividida: claves DKIM de una plataforma, DMARC con una política que espera alineación que tu From/Return-Path real no satisface. Todo “se envía”, pero la capacidad de entrega se desploma.

Un patrón más merece mención especial: DNS de horizonte dividido—donde los resolutores internos devuelven respuestas diferentes al DNS público. Esto es excelente para servicios internos. Es un desastre para el correo salvo que seas disciplinado, porque los flujos de correo cruzan límites por definición.

Broma #1: La propagación DNS es el único lugar donde “consistencia eventual” significa “eventualmente sonará tu pager”.

Guía de diagnóstico rápido (comprueba primero / segundo / tercero)

Este es el flujo de trabajo de alta señal cuando la entrega falla y necesitas encontrar el cuello de botella rápido. No abras los paneles de control del proveedor primero. Empieza con la verdad pública.

Primero: ¿es determinístico el enrutamiento entrante?

1. Comprueba los registros MX desde múltiples resolutores (tu resolutor, uno público y los servidores de nombres autoritativos).
2. Resuelve las A/AAAA para cada destino MX—asegúrate de que existen, no apunten a IPs desmanteladas y no sean cadenas de CNAME hacia ningún sitio.
3. Busca “proveedores mixtos”: destinos MX antiguos aún presentes, prioridades equivocadas, o un MX en el apex apuntando a un hostname que ya no existe.

Segundo: ¿estás fallando en la autenticación de una forma que cause rechazos?

1. Valida la sintaxis de SPF y el conteo de búsquedas DNS. Si ves permerror, trátalo como roto.
2. Confirma que los selectores DKIM están publicados y coinciden con lo que usa tu remitente.
3. Verifica que DMARC exista, tenga una política sensata y no apunte a direcciones de reporte sin sentido.

Tercero: ¿la IP que se conecta parece legítima?

1. Verifica el PTR (DNS inverso) para tus IPs salientes.
2. Verifica el DNS inverso comprobado hacia adelante (FCrDNS): el hostname del PTR resuelve de vuelta a la misma IP.
3. Comprueba si tu IP saliente proviene inesperadamente de un pool nuevo (un cambio de red “útil”, NAT o un nuevo relé SaaS).

Regla de decisión

Si el entrante está mal enrutado: arregla MX primero. Si el entrante está bien pero aterrizas en spam o rebotas en grandes proveedores: arregla SPF/DKIM/DMARC y la identidad de la IP (PTR/HELO). No afeites DMARC mientras MX aún esté enviando la mitad del correo de tus clientes a un buzón abandonado en tu proveedor anterior.

Hechos y contexto histórico que vale la pena conocer

• Los registros MX reemplazaron el “enrutamiento de correo por registro A” temprano en la historia del DNS, porque “simplemente conectar al dominio” no escalaba con múltiples hosts de correo y patrones de conmutación por error.
• Los registros TXT se convirtieron en el cajón de sastre del DNS en parte porque eran ampliamente soportados y flexibles; SPF originalmente tuvo su propio tipo RR pero TXT ganó en la práctica.
• El límite de 10 búsquedas DNS de SPF existe porque los receptores deben evaluarlo durante el tiempo SMTP, y la recursión sin límites sería un regalo DoS.
• DKIM fue diseñado para sobrevivir el reenvío mejor que SPF, porque firma el contenido del mensaje en lugar de la IP que se conecta—pero aún puede romperse con modificaciones como pies de página y cierto software de listas.
• DMARC introdujo la alineación: no basta con “pasar SPF.” SPF debe pasar para un dominio alineado con el From visible, o DKIM debe pasar y alinearse.
• Los valores TTL de DNS son orientativos; los resolutores pueden limitar, extender o comportarse de forma extraña bajo carga. TTL bajo no es un botón universal de “propagar más rápido”.
• Algunos receptores cachean respuestas negativas (NXDOMAIN) basándose en las reglas SOA / TTL negativo, lo que significa que un selector DKIM ausente por un momento puede perseguirte durante horas.
• La imposición de proveedores se endureció después de falsificaciones a gran escala; muchos grandes proveedores de bandejas ahora tratan la autenticación débil como una penalización de entregabilidad, no sólo como un “agradable de tener”.

Cómo usa realmente el correo el DNS: MX, SPF, DKIM, DMARC, PTR, TLSA y compañía

MX: adónde va el correo entrante (y cómo los registros mixtos dividen tu buzón)

Los registros MX son los directores de tráfico para el correo entrante. Cada registro MX apunta a un hostname, además de un valor de preferencia (prioridad). El número más bajo gana. Si múltiples registros MX comparten la misma preferencia, el remitente típicamente aleatoriza entre ellos.

Dónde falla:

• Dejas registros MX antiguos en su lugar “por seguridad”, creando una división aleatoria del correo entre dos proveedores.
• Apuntas un registro MX a un CNAME que funciona en algunos resolutores pero falla en otros (los objetivos MX deberían ser hostnames con A/AAAA; CNAME en objetivos MX está ampliamente desaconsejado y puede ser rechazado por remitentes estrictos).
• Añades IPv6 AAAA para un host MX que en realidad no acepta correo por IPv6, produciendo timeouts para remitentes que prefieren IPv6.

SPF: quién está autorizado a enviar (y por qué “pasa” no es lo mismo que “funciona”)

SPF es un registro TXT (comúnmente en el root del dominio) que le dice al receptor qué IPs/hosts están autorizados para enviar por ese dominio. Se evalúa contra el remitente del sobre SMTP (Return-Path / MAIL FROM) o, si está vacío, la identidad HELO/EHLO.

Modos de fallo de SPF que parecen “DNS mixto”:

• Múltiples registros TXT de SPF en el mismo nombre (dos cadenas v=spf1). Muchos receptores tratan esto como un error permanente.
• Migraciones superpuestas: include:_spf.oldvendor.example y include:_spf.newvendor.example ambos presentes, empujándote por encima del límite de búsquedas DNS.
• Hacks de prueba: alguien añade +all o ~all “temporalmente”, y se vuelve permanente, minando la aplicación y la entregabilidad.

DKIM: firmas criptográficas (y el typo en el selector que arruina tu semana)

DKIM publica una clave pública en DNS en selector._domainkey.example.com. Tu sistema saliente firma mensajes usando la clave privada e incluye el selector en la cabecera DKIM-Signature. Los receptores obtienen la clave pública y verifican la firma.

Patrones de registros mixtos:

• Rotas selectores pero no publicas el nuevo selector en todas partes (DNS multi-proveedor, o sólo el DNS interno actualizado).
• Publicas el selector en el subdominio equivocado (común al enviar como mail.example.com vs example.com).
• Rompes el formato del registro TXT (comillas, saltos de línea) de modo que algunas herramientas DNS lo muestran pero algunos receptores no lo parsean.

DMARC: política, alineación, reportes (y cómo “none” puede aún ayudar)

DMARC se publica en _dmarc.example.com y le dice a los receptores qué hacer cuando SPF/DKIM no se alinean con el dominio From visible. También proporciona direcciones de reporte para recibir feedback agregado y forense (donde esté soportado).

Patrones de registros mixtos:

• DMARC existe en example.com pero en realidad estás enviando desde sub.example.com sin su propio DMARC, o confías en el comportamiento del dominio organizacional sin entenderlo.
• La política DMARC está establecida en p=reject antes de que DKIM firme de forma consistente en todas las fuentes salientes.
• Existen múltiples registros DMARC (sucede), y los receptores lo tratan como inválido.

PTR y FCrDNS: la comprobación de “¿pareces un servidor de correo real?”

El DNS inverso (PTR) mapea una IP a un hostname. Muchos receptores valoran mucho la corrección del PTR, especialmente para MTAs auto-hospedados. Incluso para relés SaaS, un cambio repentino en la identidad de la IP saliente puede hundir la entregabilidad. FCrDNS añade una segunda comprobación: el nombre PTR debe resolver de vuelta a la misma IP.

MTA-STS y TLSA: no son obligatorios en todas partes, pero cada vez más relevantes

MTA-STS usa un registro TXT DNS (_mta-sts.example.com) y un host de política HTTPS (mta-sts.example.com) para indicar que el SMTP entrante debe usar TLS y para fijar hosts MX esperados. TLSA (DANE) usa DNSSEC para publicar restricciones de certificado TLS. No son requisitos “día uno” para muchas organizaciones, pero si los despliegas añaden más formas en que el DNS mixto puede romper el correo.

Broma #2: La buena noticia sobre el correo es que es un protocolo maduro. La mala noticia es que es un protocolo maduro.

Un recordatorio de fiabilidad, parafraseado de una voz notable en operaciones: idea parafraseada: optimiza para recuperación y aprendizaje rápidos, porque las fallas son inevitables en sistemas complejos — John Allspaw.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas tareas están pensadas para ejecutarse desde cualquier caja Linux con herramientas DNS comunes instaladas. Ejecútalas desde al menos dos redes si puedes (LAN corporativa + una VM en la nube), porque “funciona desde aquí” es la trampa.

Tarea 1: Consultar MX desde tu resolutor por defecto

cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Qué significa: El DNS público (tal como lo ve tu resolutor) dice que el correo va a dos hosts, preferencia 10 y luego 20.

Decisión: Si esperabas un proveedor y ves dos conjuntos no relacionados (antiguo y nuevo), detente y limpia. MX mixto no es “redundancia extra” a menos que controles ambos sistemas y sepas exactamente cómo interactúan.

Tarea 2: Consultar MX desde un resolutor público específico

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.oldmail.example.
example.com.     300 IN MX 20 mx2.oldmail.example.

Qué significa: Diferente resolutor, diferente verdad. Estás en medio de propagación o tienes respuestas autoritativas inconsistentes (o un problema DNSSEC que causa comportamiento de retroceso).

Decisión: Antes de cambiar más, consulta los servidores de nombres autoritativos. Si ellos son consistentes, espera; si son inconsistentes, arregla la ruta de publicación de la zona.

Tarea 3: Consultar directamente los servidores de nombres autoritativos

cr0x@server:~$ dig +short NS example.com
ns1.dns-host.example.
ns2.dns-host.example.

cr0x@server:~$ dig @ns1.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

cr0x@server:~$ dig @ns2.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Qué significa: Los servidores autoritativos coinciden en los nuevos MX.

Decisión: Si los resolutores públicos discrepan, estás esperando la expiración de caché. Comunica eso claramente: “Algunos remitentes seguirán golpeando el MX antiguo hasta que expire el TTL.” Si los servidores autoritativos discrepan, tienes un problema de sincronización/publicación de zona y la propagación no te salvará.

Tarea 4: Confirmar que los objetivos MX resuelven a A/AAAA

cr0x@server:~$ dig mx1.newmail.example A +noall +answer
mx1.newmail.example. 300 IN A 203.0.113.10

cr0x@server:~$ dig mx1.newmail.example AAAA +noall +answer

Qué significa: IPv4 existe, IPv6 no (respuesta AAAA vacía).

Decisión: Está bien si no sirves IPv6. Lo que no quieres es una AAAA rota que apunte a una IP donde el puerto 25 está cerrado, porque algunos remitentes preferirán IPv6 y se quedarán en timeout.

Tarea 5: Detectar rarezas de “CNAME en objetivo MX”

cr0x@server:~$ dig mx1.newmail.example CNAME +noall +answer
mx1.newmail.example. 300 IN CNAME vendor-lb.mailhost.example.

Qué significa: El objetivo MX es un CNAME.

Decisión: Si lo controlas y es conocido-bueno con tus receptores, puedes sobrevivir. Si estás solucionando entregabilidad, elimina esta variable: usa los hostnames recomendados por el proveedor que resuelvan directamente a A/AAAA.

Tarea 6: Comprobar presencia y conteo del registro SPF

cr0x@server:~$ dig example.com TXT +noall +answer
example.com. 300 IN TXT "v=spf1 include:_spf.newvendor.example -all"
example.com. 300 IN TXT "v=spf1 include:_spf.oldvendor.example -all"

Qué significa: Dos registros SPF. Eso no es “dos fuentes de verdad”, es “ruleta permerror”.

Decisión: Únelos en un solo registro v=spf1. Si realmente necesitas ambos proveedores durante la migración, combina los includes en una sola cadena y mantenlo bajo los límites de búsquedas.

Tarea 7: Evaluar SPF contra una IP conocida de envío

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=Two or more type TXT records found

Qué significa: La evaluación SPF falla permanentemente por múltiples registros.

Decisión: Arregla SPF ahora. Muchos receptores tratan permerror como fail o como una fuerte señal negativa.

Tarea 8: Comprobar explosión de búsquedas DNS en SPF

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=SPF Permanent Error: too many DNS lookups

Qué significa: Tus includes/redirects exceden el límite de SPF.

Decisión: Aplana SPF (con cuidado), elimina includes no usados, o consolida emisores detrás de un único relé con una huella SPF estable.

Tarea 9: Obtener la clave pública DKIM para un selector que crees que está en uso

cr0x@server:~$ dig s1._domainkey.example.com TXT +noall +answer
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: El selector existe y devuelve una clave pública.

Decisión: Si los mensajes fallan DKIM, el problema probablemente sea la configuración de firmado (selector equivocado, dominio equivocado, problemas de canonicalización del cuerpo/headers) o modificación intermedia de los mensajes.

Tarea 10: Capturar el typo/missing del selector DKIM

cr0x@server:~$ dig s2._domainkey.example.com TXT +noall +answer

Qué significa: No hay registro TXT para el selector s2.

Decisión: Publica s2 o reconfigura el remitente para usar el selector publicado. Si estás en rotación, publica tanto el selector viejo como el nuevo hasta que el correo antiguo se drene y todos los remitentes estén actualizados.

Tarea 11: Comprobar corrección del registro DMARC

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

Qué significa: DMARC existe, la política es quarantine, y la alineación estricta está habilitada.

Decisión: La alineación estricta está bien solo si eres disciplinado respecto a los dominios From y el firmado. Si tienes muchos sistemas enviando correo, la alineación estricta puede volverse en tu contra. Considera alineación relajada durante la limpieza, luego aprieta después.

Tarea 12: Detectar múltiples registros DMARC

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Qué significa: Dos registros DMARC. Los receptores pueden tratar esto como inválido e ignorar DMARC por completo.

Decisión: Publica exactamente un registro DMARC en _dmarc. Fusiona las etiquetas en una sola política.

Tarea 13: Verificar DNS inverso (PTR) para la IP saliente

cr0x@server:~$ dig -x 203.0.113.55 +noall +answer
55.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Qué significa: La IP tiene PTR apuntando a mailout.example.com.

Decisión: Asegúrate de que ese hostname también resuelva hacia adelante a la misma IP (FCrDNS). Si el PTR falta o es genérico, arréglalo con tu ISP/proveedor cloud; a menudo no es negociable para una buena entrega.

Tarea 14: Verificar forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ dig mailout.example.com A +noall +answer
mailout.example.com. 300 IN A 203.0.113.55

Qué significa: El forward coincide con el reverse. Esta es la línea base aburrida que muchos receptores esperan.

Decisión: Si el forward no coincide, arregla el PTR o el registro A. No lo dejes “suficientemente cerca.” Los sistemas de correo no son precisamente relajados.

Tarea 15: Comprobar DNS de horizonte dividido (público vs interno)

cr0x@server:~$ dig @10.0.0.53 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.internal.example.

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.newmail.example.

Qué significa: El DNS interno devuelve un MX diferente al DNS público.

Decisión: A menos que tengas una arquitectura muy específica y bien probada, unifícalos. Como mínimo, asegúrate de que los clientes internos que envían correo externamente no usen identidades internas que rompan SPF/DKIM/DMARC y confundan el enrutamiento de correo.

Tarea 16: Confirmar TTL de DNS y pistas de cacheo negativo

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.dns-host.example. hostmaster.example.com. 2026010401 3600 900 1209600 300

Qué significa: El SOA muestra el serial de la zona y el último campo (minimum) a menudo influye en el comportamiento de cacheo negativo.

Decisión: Si publicaste brevemente un selector DKIM ausente (NXDOMAIN), algunos resolutores pueden recordar ese fallo. Planifica despliegues clave con solapamiento y evita implementaciones donde “el registro desaparece por un minuto”.

Tarea 17: Inspeccionar los resultados de autenticación de un mensaje real (desde las cabeceras)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|DMARC" -n message.eml | head
12:Authentication-Results: mx.google.com; spf=fail (google.com: domain of bounce@example.com does not designate 203.0.113.55 as permitted sender) smtp.mailfrom=bounce@example.com; dkim=pass header.i=@example.com; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com
33:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; ...

Qué significa: DKIM pasa, SPF falla, DMARC falla. Eso puede suceder si DKIM se alinea pero DMARC aún falla debido a desalineación o porque la evaluación del receptor difiere de tu expectativa.

Decisión: Enfócate en la alineación: asegúrate de que el dominio d= de DKIM y/o el dominio mailfrom de SPF se alineen con el From visible. Si DMARC es estricto y tu mailfrom es un dominio de rebotes de terceros, puede que necesites return-path personalizado o una configuración de envío distinta.

Tarea 18: Confirmar que tu MX acepta realmente conexiones SMTP (realidad de red)

cr0x@server:~$ nc -vz mx1.newmail.example 25
Connection to mx1.newmail.example 25 port [tcp/smtp] succeeded!

Qué significa: El puerto 25 es accesible.

Decisión: Si esto falla desde Internet público pero funciona internamente, tienes problemas de firewall o enrutamiento—no es un problema de DNS. No sigas editando registros TXT para arreglar un puerto cerrado.

Tres micro-historias corporativas desde el frente

Micro-historia #1: El incidente causado por una suposición equivocada

La compañía tenía dos marcas bajo un mismo holding. El equipo de marketing decidió unificar el correo saliente para que las campañas vinieran de una sola plataforma. El documento de incorporación del proveedor de correo decía: “Añade estos includes de SPF y las claves DKIM.” Hasta ahí, normal.

La suposición equivocada llegó en silencio: alguien creyó que SPF se evaluaba contra el dominio From visible. Actualizaron el SPF de brandA.com para incluir al proveedor y lo dieron por hecho. En realidad, el correo transaccional usaba bounces.brandA-mail.com como remitente del sobre, porque otro sistema manejaba los return-paths. El SPF de ese dominio todavía apuntaba al relé antiguo.

La entrega no falló universalmente. Falló para ciertos receptores de alta señal que ponderaban SPF fuertemente para ese flujo. El helpdesk recibió tickets de “algunos clientes no reciben restablecimientos de contraseña”—siempre la peor categoría, porque los usuarios no distinguen entre “correo de marketing” y “mi cuenta está rota”.

La depuración llevó más tiempo del debido porque las pruebas se hicieron desde un proveedor de buzón y una red. El equipo finalmente miró las cabeceras Authentication-Results, vio SPF fallando en el remitente del sobre, y se dio cuenta de que habían autenticado el dominio equivocado.

La solución fue aburrida: publicar SPF y DKIM para el dominio real de rebotes, alinear DMARC con el From visible y estandarizar el manejo de return-path entre sistemas. También lo anotaron, en letras grandes, qué dominios se usaban para qué. La producción ama las letras grandes.

Micro-historia #2: La optimización que salió mal

Una organización de rápido crecimiento migró DNS a un proveedor que soportaba “enrutamiento inteligente” y checks automatizados de salud. Redujeron TTLs en toda la zona porque querían “conmutación instantánea” durante incidentes. Sonó razonable en una reunión.

Luego migraron el correo entrante. Durante el corte, su automatización siguió cambiando los registros MX porque uno de los nuevos hosts MX fallaba el chequeo TCP de forma intermitente. Algunos resolutores cachéaron el MX “antiguo”, algunos el “nuevo” y algunos la versión de hace cinco minutos. El correo entrante se volvió probabilístico.

Se puso peor: el TTL bajo incrementó el volumen de consultas y expuso un segundo problema—límite de tasa en el proveedor autoritativo durante un pico. Los receptores empezaron a ver SERVFAIL ocasionalmente. Esos remitentes pusieron en cola y reintentaron (el correo es paciente), pero creó un patrón ondulado de entregas retrasadas que parecía un bug de aplicación.

La lección post-incidente no fue “nunca bajes el TTL”. Fue: no uses DNS como equilibrador de carga impulsado por checks de salud para correo a menos que entiendas completamente el ecosistema receptor. Los remitentes SMTP ya tienen lógica de reintentos. Tu trabajo es enrutamiento estable e identidad estable, no cambios elegantes.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Un equipo distinto tenía un plan de migración que parecía casi demasiado conservador: documentaron cada fuente de envío (sistema de tickets, CRM, alertas de monitorización, correo de producto, marketing). Para cada una anotaron dominio From, dominio remitente del sobre, selector DKIM y IP/relé saliente.

También ejecutaban una “comprobación de deriva DNS” semanal: extraer los registros de la zona desde la API autoritativa, comparar con una plantilla conocida-buena y alertar sobre diferencias. No era glamoroso. Nadie recibió una promoción porque un cronjob no se ejecutó. Pero evitó sorpresas.

Cuando migraron a un nuevo relé saliente, la comprobación de deriva alertó de que un compañero había añadido un segundo registro SPF en lugar de editar el existente. Nunca llegó a producción porque el cambio falló una puerta de preflight.

La migración aún tuvo contratiempos normales—algunas cachés retuvieron el MX antiguo más tiempo del esperado—pero el correo no se dividió entre proveedores y DMARC no empezó a rechazar envíos legítimos de repente. La práctica “aburrida” no era sobrecarga; era cinturón de seguridad.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: Algunos remitentes rebotan con “host not found”, otros entregan bien

Causa raíz: Visibilidad MX inconsistente entre resolutores (ventana de propagación, caches obsoletos o respuestas autoritativas inconsistentes). A veces conjuntos NS mixtos durante cambios de registrador.

Solución: Consulta NS autoritativos directamente; asegúrate de que ambos NS sirvan serial y registros idénticos. Evita cambiar NS y MX simultáneamente salvo que te guste el estrés. Aumenta TTL antes de migraciones planificadas, no durante ellas.

2) Síntoma: El correo entrante cae aleatoriamente en el proveedor antiguo

Causa raíz: Registros MX antiguos aún publicados, a menudo con preferencia igual o todavía más baja que los nuevos.

Solución: Publica solo el conjunto MX previsto. Si necesitas entrega dual, hazlo intencionalmente con una capa de enrutamiento controlada, no dejando basura en DNS.

3) Síntoma: SPF muestra “permerror” en las cabeceras

Causa raíz: Múltiples registros TXT SPF, o límite de búsquedas SPF excedido por demasiados includes/redirects.

Solución: Consolida a un solo registro SPF. Reduce includes, elimina proveedores no usados y mantén el conteo de búsquedas por debajo de 10.

4) Síntoma: “selector no encontrado” de DKIM aparece de forma intermitente

Causa raíz: Selector publicado en una vista DNS pero no en otra (horizonte dividido), o registro actualizado en un NS autoritativo pero no en otro, o una rotación de claves que eliminó el selector antiguo demasiado pronto.

Solución: Publica selectores de forma consistente en todos los servidores autoritativos. Durante rotación, solapa selectores antiguos y nuevos. No “limpies” hasta verificar que todos los remitentes se movieron.

5) Síntoma: DMARC rechaza correo legítimo tras un cambio de proveedor

Causa raíz: Alineación rota—el nuevo proveedor usa un dominio de rebotes distinto, o DKIM firma con un dominio que no se alinea con el From, especialmente bajo alineación estricta.

Solución: Configura return-path/envelope sender personalizado cuando sea posible. Asegura que DKIM d= se alinee con From. Considera alineación relajada durante la migración y luego vuelve a endurecer.

6) Síntoma: Correo a un proveedor importante se retrasa horas

Causa raíz: El receptor no puede alcanzar tu MX de forma consistente (preferencia IPv6 a una AAAA rota, bloqueos de firewall, greylisting + fallos de autenticación), o DNS intermitentemente SERVFAIL por problemas autoritativos.

Solución: Valida la ruta IPv6 si publicas AAAA. Comprueba la accesibilidad al puerto 25 desde fuera. Estabiliza el DNS autoritativo y evita registros que fluctúen.

7) Síntoma: Pasas SPF pero aun así caes en spam

Causa raíz: SPF pasa en un dominio no alineado (o solo la identidad HELO pasa). DMARC falla o falta. O la reputación de IP y PTR/HELO son débiles.

Solución: Implementa DKIM y DMARC con alineación. Arregla PTR/FCrDNS. Asegura que el HELO/EHLO saliente sea estable y significativo.

8) Síntoma: Todo parece correcto en tu oficina, falla para los clientes

Causa raíz: DNS de horizonte dividido devolviendo respuestas MX/SPF/DKIM internas, o el egress interno usa una IP NAT distinta a las pruebas externas.

Solución: Prueba desde redes externas. Elimina sobrescrituras internas para identidades de correo públicas. Documenta y monitoriza tus IPs de salida.

Listas de verificación / plan paso a paso

Paso a paso: Arreglar un outage de correo por DNS mixto de forma segura

1. Congela cambios. Deja de editar registros al azar mientras aún estás adivinando. Captura el estado actual de la zona (MX, TXT, A/AAAA, NS, SOA).
2. Establece la verdad autoritativa. Consulta cada NS autoritativo directamente para MX, TXT SPF, selectores DKIM, DMARC. Si discrepan, arregla eso primero.
3. Haz el entrante determinístico. Publica solo el conjunto MX previsto. Verifica que los objetivos MX resuelvan y acepten SMTP.
4. Arregla SPF a un registro. Fusiona includes; verifica el conteo de búsquedas; asegúrate de autorizar todas las fuentes salientes legítimas (o enrótalas por un relé).
5. Arregla selectores DKIM. Asegúrate de que cada remitente firme y que el selector exista en DNS público. Solapa selectores viejo/nuevo durante rotación.
6. Ajusta DMARC a la realidad. Comienza con p=none si es necesario, luego pasa a quarantine y reject una vez que la alineación esté probada en todas las fuentes.
7. Verifica identidad IP. PTR + FCrDNS; asegura que HELO/EHLO sea estable y coincida con el dominio PTR cuando proceda.
8. Prueba desde múltiples puntos. Usa al menos una VM externa y un ISP de consumo si es posible.
9. Espera caches inteligentemente. Rastrea TTLs; comunica ventanas de convergencia esperadas a interesados. No prometas recuperación instantánea si el TTL es 1 hora y los resolutores principales son pegajosos.
10. Cierra el ciclo con cabeceras reales. Valida Authentication-Results desde receptores representativos. Si no puedes ver cabeceras, estás depurando a ciegas.

Lista de prevención: Evitar que el DNS se convierta en generador de outages de correo

• Un solo responsable para la superficie DNS del correo. No “todos pueden editar TXT porque es fácil.” Lo fácil es cómo obtienes múltiples registros SPF.
• Inventario de todos los sistemas emisores. Para cada uno: dominio From, dominio remitente del sobre, selector DKIM, IP/relé saliente y si soporta return-path personalizado.
• Gestión de cambios para DNS. Revisión en staging, aprobación por pares y plan de rollback que no implique clics frenéticos en una consola web.
• Monitorea respuestas DNS desde múltiples resolutores. Alerta si MX/SPF/DMARC/DKIM cambian inesperadamente, o si los NS autoritativos discrepan.
• Playbook de rotación de claves. Publica el selector nuevo primero, luego cambia el firmado, luego retira el selector antiguo después.
• No sobre-optimices el TTL. Usa el TTL como herramienta de planificación. Bájalos antes de cambios planificados y súbelos después para estabilidad.
• Documenta los cutovers de proveedores. Especialmente donde hay dos proveedores involucrados (antiguo + nuevo). Las entradas DNS “temporales” deben tener fecha de expiración y un responsable.

Preguntas frecuentes

1) ¿Qué cuenta exactamente como “registros DNS mixtos” para correo?

Cualquier combinación donde el enrutamiento de correo o los datos de autenticación sean inconsistentes: dos conjuntos MX de diferentes proveedores, múltiples registros SPF, DMARC duplicado, selectores DKIM faltantes, o DNS interno/público devolviendo respuestas distintas.

2) ¿Puedo mantener MX antiguo y nuevo durante una migración “por si acaso”?

Puedes, pero normalmente no deberías. Crea enrutamiento no determinístico a menos que controles ambos extremos y tengas un plan para deduplicación, visibilidad de usuario y soporte. La mayoría de las organizaciones quieren entrega determinística a un único sistema de buzón.

3) ¿Por qué el correo sigue yendo al proveedor antiguo incluso después de actualizar MX?

Porque los sistemas remitentes cachean DNS. Algunos cachean más tiempo que tu TTL. Algunos también reintentan contra destinos MX previamente resueltos para mensajes en cola. Eso es normal. Tu trabajo es asegurar que las respuestas autoritativas sean correctas y estables.

4) ¿Tener dos registros SPF siempre es incorrecto?

Sí, para efectos prácticos. La especificación SPF espera un único registro de política. Muchos receptores tratan múltiples cadenas v=spf1 como un error permanente.

5) Si DKIM pasa, ¿sigo necesitando SPF?

Para la entregabilidad moderna, quieres ambos. DKIM suele ser la señal más robusta bajo reenvío, pero SPF aún importa, y DMARC puede pasar vía cualquiera de los dos—siempre que haya alineación.

6) ¿Qué es la alineación DMARC, en términos sencillos?

Significa que el dominio autenticado (por SPF mailfrom o por DKIM d=) coincide con el dominio From visible, ya sea exactamente (estricto) o dentro del mismo dominio organizacional (relajado).

7) ¿Cómo rompen los setups de DNS de horizonte dividido el correo?

Si los resolutores internos devuelven MX/SPF/DKIM/DMARC distintos al Internet público, las pruebas internas pueden pasar mientras los remitentes externos fallan. Además, las apps internas pueden enviar con identidades que no validan externamente.

8) ¿Debo publicar registros AAAA para mis hosts MX?

Sólo si realmente aceptas SMTP sobre IPv6 de manera fiable (conectividad, firewall, configuración TLS, monitorización). Publicar AAAA sin preparación operativa crea timeouts y retrasos para remitentes que prefieren IPv6.

9) ¿Qué tan estricto debería ser DMARC?

Empieza con p=none para observar, luego pasa a quarantine, luego a reject una vez que hayas verificado que todas las fuentes legítimas se alinean y firman. Aplicar sin inventario es cómo bloqueas tu propio correo.

10) ¿Cuál es el indicador más rápido de que DNS es el culpable?

Diferentes resolutores devolviendo respuestas MX o TXT distintas para el mismo nombre. Si los servidores de nombres autoritativos discrepan, casi seguro es un problema de publicación DNS y no del servidor de correo.

Conclusión: siguientes pasos que puedes hacer hoy

Si recuerdas una cosa: el correo se rompe cuando el DNS cuenta dos historias a la vez. Tu trabajo es hacer que cuente una historia aburrida y correcta—de forma consistente, desde cualquier resolutor, siempre.

1. Ejecuta consultas MX/SPF/DKIM/DMARC contra los servidores de nombres autoritativos y al menos un resolutor público. Guarda las salidas.
2. Haz el MX determinístico: elimina entradas de proveedores legados y verifica que los objetivos MX resuelvan y acepten SMTP.
3. Reduce la entropía de autenticación: un registro SPF, selectores DKIM publicados que coincidan con el firmado real, un DMARC con la política que refleje tu madurez actual.
4. Verifica la identidad saliente: PTR + correspondencia hacia adelante, HELO estable y sin cambios de IP de salida inesperados.
5. Escribe tu inventario de envío y pon una puerta de cambio antes de editar DNS. El tú del futuro no sentirá nostalgia por los “arreglos rápidos”.