← RFC Reference

Enrutamiento de DNS y Correo

Cómo DNS impulsa toda la ruta de entrega de correo electrónico — registros MX, prioridad y conmutación por error, respaldo A/AAAA, MX nulo, registros PTR y los registros DNS que cada dominio de envío necesita.

El Algoritmo de Enrutamiento de Correo

Cuando un servidor de envío necesita entregar un mensaje a user@example.com, sigue este algoritmo, definido en RFC 5321 Sección 5:

1. Consultar registros MX para example.com
2. Si existen registros MX, ordenar por prioridad (número más bajo = preferencia más alta)
3. Para cada nombre de host MX, resolver sus registros A y/o AAAA para obtener direcciones IP
4. Intentar conectarse al MX de mayor prioridad. Si falla, intentar el siguiente.
5. Si no existen registros MX (respuesta NODATA), recurrir al registro A/AAAA del dominio e intentar la entrega allí
6. Si el registro MX es un MX nulo (0 .), el dominio no acepta correo — generar una falla permanente
7. Si el dominio no existe en absoluto (NXDOMAIN), generar una falla permanente

Registros MX

El registro MX (Intercambiador de Correo) es el tipo de registro DNS principal para enrutamiento de correo. Asigna un dominio a uno o más servidores de correo con prioridades:

Cada registro tiene dos partes:

• Prioridad (valor de preferencia) — Se intentan primero los números más bajos. El servidor de envío siempre intenta el MX de menor prioridad primero.
• Intercambio (nombre de host) — El servidor de correo al que conectarse. Debe ser un nombre de host, nunca una dirección IP. El nombre de host debe tener un registro A o AAAA.

Prioridad y conmutación por error

En el ejemplo anterior, el remitente intenta mx1.example.com primero (prioridad 10). Si ese servidor es inaccesible, devuelve un error temporal 4xx, o la conexión agota el tiempo de espera, el remitente intenta mx2.example.com (prioridad 20), luego mx-backup.example.com (prioridad 30).

Si varios registros MX comparten la misma prioridad, el remitente debe aleatorizar entre ellos. Esto proporciona equilibrio de carga:

Aquí, los tres servidores tienen la misma prioridad. El servidor de envío elige uno al azar para cada intento de entrega, distribuyendo la carga entre los tres.

MX debe apuntar a un nombre de host, no a una IP

El campo de intercambio de un registro MX debe ser un nombre de host. No puede ser una dirección IP (RFC 5321 es explícito al respecto). El nombre de host en sí debe resolver a un registro A y/o AAAA. No debe ser un CNAME — aunque algunos resolutores toleran objetivos de MX que son CNAME, esto está técnicamente prohibido y causa problemas de interoperabilidad.

MX no debe apuntar a un CNAME

Esta es una configuración errónea común. Si mx1.example.com es un CNAME que apunta a mail.provider.com, algunos servidores de envío fallarán en la entrega. Siempre use registros A/AAAA para objetivos de MX.

Respaldo A/AAAA

Si un dominio no tiene registros MX en absoluto (ni siquiera un MX nulo), el servidor de envío recurre al registro A o AAAA del dominio e intenta entrega SMTP allí. Esto se llama la regla "MX implícito".

El servidor de envío intentará entregar a 198.51.100.50 en el puerto 25. Esto funciona, pero se considera mala práctica para cualquier dominio que envíe o reciba correo activamente. Siempre publique registros MX explícitos.

El respaldo solo se aplica cuando hay cero registros MX. Si existen registros MX pero todos los hosts MX son inaccesibles, el remitente no recurre al registro A — pone en cola el mensaje para reintentos.

MX Nulo: "Este Dominio No Acepta Correo"

RFC 7505 define el MX nulo — una forma de declarar explícitamente que un dominio no acepta correo electrónico:

Un punto único (.) como intercambio, con prioridad 0, significa "no intentar entrega". El servidor de envío debe generar inmediatamente una falla permanente (5.1.2 — sistema de destino incorrecto) en lugar de perder tiempo conectando.

Use MX nulo para:

• Dominios que solo envían correo electrónico y nunca lo reciben
• Dominios estacionados
• Dominios usados exclusivamente para alojamiento de sitios web

Sin un MX nulo, los remitentes recurrirán al registro A y perderán tiempo intentando conexiones que nunca tendrán éxito.

Registros PTR: DNS Inverso

Un registro PTR asigna una dirección IP nuevamente a un nombre de host. Es lo opuesto a un registro A:

Los registros PTR no forman parte del algoritmo de enrutamiento de MX, pero son críticos para la entregabilidad. La mayoría de los proveedores de buzones importantes verifican el registro PTR de la dirección IP del servidor que se conecta:

• La IP debe tener un registro PTR (PTR faltante = probablemente spam)
• El nombre de host PTR debe resolver nuevamente a la misma IP (DNS inverso confirmado hacia adelante, o FCrDNS)
• El nombre de host PTR no debe parecer "genérico" (p. ej., 198-51-100-42.dynamic.isp.com sugiere una conexión residencial)

Los registros PTR son administrados por el propietario del bloque de direcciones IP (generalmente su proveedor de alojamiento o ISP), no a través del DNS de su dominio. Es posible que deba comunicarse con su proveedor para establecer o cambiar registros PTR.

Registros DNS que Todo Dominio de Envío Necesita

Aquí está el conjunto completo de registros DNS para un dominio que envía correo a través de un servicio como Mailer To Go:

Para un dominio que envía pero no recibe correo (p. ej., un subdominio usado para correo transaccional):

Consideraciones de TTL

Los registros DNS tienen un Time To Live (TTL) que controla cuánto tiempo los resolutores los almacenan en caché. Para registros relacionados con correo:

• Registros MX: 1 hora (3600) es típico. Los TTL más bajos permiten conmutación por error más rápida pero aumentan la carga de consultas DNS.
• Registros SPF/DKIM/DMARC: 1 hora es común. Use TTL más cortos (300 segundos) durante la configuración inicial o cambios, luego aumente.
• Registros A/AAAA para hosts MX: 5 minutos a 1 hora. Más cortos si necesita cambios rápidos de IP.

Al realizar cambios de DNS, reduzca el TTL antes del cambio (espere a que expire el TTL antiguo), realice el cambio, verifique, luego aumente el TTL nuevamente al valor operacional.

DNSSEC y Correo

DNSSEC (Extensiones de Seguridad DNS) agrega firmas criptográficas a registros DNS, evitando la suplantación y el envenenamiento de caché. Para correo electrónico, DNSSEC es particularmente importante porque:

• Autentica registros MX — un atacante no puede redirigir correo a un servidor fraudulento envenenando DNS
• Es requerido para DANE (Autenticación Basada en DNS de Entidades Nombradas), que vincula certificados TLS a DNS
• Autentica registros SPF, clave pública DKIM y registros DMARC

Sin DNSSEC, un atacante de red puede falsificar respuestas DNS y redirigir o interceptar correo. La adopción de DNSSEC para dominios de correo está aumentando pero aún no es universal.

Registros SRV para Envío de Correo

RFC 6186 define registros SRV que los clientes de correo pueden usar para descubrir automáticamente servidores de envío e IMAP/POP:

Se utilizan para autoconfiguración de clientes de correo — cuando un usuario escribe su dirección de correo electrónico, el cliente consulta registros SRV para encontrar el servidor, puerto y protocolo correctos. Esto es separado del enrutamiento de servidor a servidor basado en MX.

Qué Puede Salir Mal

Registros MX faltantes

Sin registros MX, los remitentes recurren a su registro A. Si su servidor web no está ejecutando un servidor SMTP en el puerto 25, la entrega de correo falla después del tiempo de espera. Siempre publique registros MX explícitos, o un MX nulo si no acepta correo.

MX apuntando a un CNAME

Como se señaló anteriormente, esto es técnicamente inválido. Algunos remitentes seguirán el CNAME; otros fallarán. Use registros A/AAAA para todos los nombres de host de destino de MX.

Referencias MX circulares

Si example.com tiene un MX apuntando a mail.example.com, y mail.example.com tiene su propio MX apuntando de vuelta a example.com, el correo puede hacer bucle. Los objetivos de MX deben ser nombres de host hoja con registros A/AAAA únicamente.

Registro PTR faltante

Su IP de envío no tiene DNS inverso, o se resuelve a un nombre de host genérico del ISP. Los principales proveedores de buzones (Gmail, Microsoft, Yahoo) aplazarán o rechazarán su correo. Asegúrese de que sus IPs de envío tengan registros PTR que se resuelvan hacia adelante a la misma IP.

Tiempo de espera de DNS durante la entrega

Si los servidores DNS del dominio del destinatario son lentos o inaccesibles, el servidor de envío no puede resolver registros MX. El mensaje se pone en cola para reintentos. Los fallos de DNS persistentes eventualmente resultan en un rebote (generalmente después de 4-5 días). No hay nada que pueda hacer como remitente — este es un problema de infraestructura del destinatario.

Registro SPF excede el límite de UDP de DNS

Las respuestas de DNS sobre UDP se limitan a 512 bytes (o 4096 con EDNS0). Un registro SPF muy largo con muchas directivas include: puede truncarse. El resolutor recurre a TCP, que agrega latencia y puede fallar si el servidor DNS no admite TCP. Mantenga su registro SPF conciso.

Depuración de DNS para Correo

Comandos esenciales para diagnosticar problemas de enrutamiento de correo:

Puntos Clave

• Los registros MX son el mecanismo principal para enrutamiento de correo. Se intentan primero los números de prioridad más bajos.
• Si no existen registros MX, los remitentes recurren al registro A/AAAA. Publique registros MX explícitos (o MX nulo) para evitar ambigüedad.
• Los objetivos de MX deben ser nombres de host con registros A/AAAA — nunca IPs, nunca CNAME.
• Los registros PTR (DNS inverso) no son parte del enrutamiento pero son esenciales para la entregabilidad. Cada IP de envío necesita un PTR que coincida con un registro A hacia adelante.
• Un dominio de envío completo necesita registros MX (o MX nulo), SPF, DKIM y DMARC como mínimo.
• Use dig para verificar cada registro DNS antes y después de cambios.

Lectura Adicional

Related RFCs