← RFC Reference

RFC 1035 – Nombres de Dominio: Implementación y Especificación

Por qué existe este RFC

RFC 1035, publicado en 1987 junto con RFC 1034, define los detalles de implementación del Sistema de Nombres de Dominio. Aunque DNS es una infraestructura de propósito general, es absolutamente crítico para el correo electrónico. Cada entrega de correo comienza con una búsqueda DNS — el servidor emisor debe descubrir qué servidores aceptan correo para el dominio del destinatario.

RFC 1035 define los tipos de registros, formatos de consulta y estructuras de respuesta que hacen esto posible. Para correo electrónico, cuatro tipos de registros son los más importantes: MX (enrutamiento de intercambio de correo), A (direcciones IPv4), AAAA (direcciones IPv6, definidas posteriormente en RFC 3596), y TXT (registros de texto utilizados para políticas SPF, claves DKIM, DMARC y más).

Sin RFC 1035, no habría una forma estándar de asignar un nombre de dominio a los servidores que manejan su correo. Cada mecanismo de autenticación y enrutamiento en el correo electrónico moderno depende de él.

Cómo funciona

Cuando un MTA emisor necesita entregar un mensaje a usuario@ejemplo.com, sigue una secuencia específica de búsqueda DNS:

1. Consultar registros MX para ejemplo.com. La respuesta contiene uno o más intercambiadores de correo, cada uno con un valor de prioridad (menor = preferido).
2. Ordenar por prioridad. Si múltiples registros MX comparten la misma prioridad, el emisor randomiza entre ellos para equilibrio de carga.
3. Resolver el nombre de host MX a una dirección IP usando consultas A (IPv4) o AAAA (IPv6).
4. Conectarse al servidor de correo en la dirección IP resuelta en el puerto 25 e iniciar la sesión SMTP.
5. Si el MX preferido no es alcanzable, intentar con el siguiente de menor prioridad, y así sucesivamente.
6. Si no existen registros MX, recurrir al registro A/AAAA del dominio mismo (según RFC 5321).

Detalles técnicos clave

Registros MX — Enrutamiento de correo

El registro MX es la piedra angular del enrutamiento de correo electrónico. Asigna un dominio al nombre de host de sus servidores de correo, con un valor de preferencia que determina el orden en que se intentan:

El destino MX debe ser un nombre de host, nunca una dirección IP. El MTA emisor luego resuelve ese nombre de host a una IP mediante consultas A/AAAA. Un registro MX que apunta a un CNAME está técnicamente prohibido por la especificación, aunque algunos resolutores lo toleran.

Registros A y AAAA — Resolución de IP

Una vez que se conoce el nombre de host MX, los registros A proporcionan direcciones IPv4 y los registros AAAA proporcionan direcciones IPv6:

Si un nombre de host MX se resuelve tanto en registros A como AAAA, el MTA emisor elige basándose en su propia configuración y conectividad. La mayoría de los MTA modernos prefieren IPv6 cuando está disponible, retrocediendo a IPv4.

Registros TXT — Autenticación de correo electrónico

Los registros TXT fueron originalmente un mecanismo genérico para adjuntar datos de texto a un nombre de dominio. La autenticación de correo electrónico los ha adoptado extensamente:

Los registros TXT se limitan a 255 bytes por cadena, pero un único registro puede contener múltiples cadenas que se concatenan. Los registros SPF que exceden 255 bytes deben dividirse de esta manera.

MX nulo — RFC 7505

Un dominio que no acepta correo electrónico puede publicar un registro Null MX — un MX con prioridad de 0 que apunta a "." (la raíz). Esto indica a los servidores emisores que no intenten la entrega, evitando retrasos y rechazos:

TTL y almacenamiento en caché

Cada registro DNS tiene un TTL (tiempo de vida) que controla cuánto tiempo los resolutores almacenan en caché el resultado. Para registros MX, los TTL típicos varían de 300 a 3600 segundos. Los TTL más bajos permiten una conmutación por error más rápida pero aumentan el volumen de consultas DNS. Durante migraciones, reduce el TTL bien de antemano para que los registros almacenados en caché expiren antes de que el cambio sea efectivo.

Ejemplo de búsqueda DNS

Una secuencia completa de búsqueda DNS para entregar a usuario@ejemplo.com:

Errores comunes

• Apuntar un registro MX a una dirección IP. Los registros MX deben apuntar a un nombre de host, no a una IP. MX 10 198.51.100.25 es inválido y causará fallos de entrega.
• Apuntar un registro MX a un CNAME. El destino MX debe resolver directamente a registros A/AAAA. Un MX que apunta a un CNAME está prohibido por la especificación y causa comportamiento impredecible en diferentes resolutores.
• DNS inverso (PTR) faltante para IPs de servidor de correo. Aunque no está definido por RFC 1035, la mayoría de servidores receptores verifican que la dirección IP de tu servidor de correo tenga un registro PTR que se resuelva nuevamente a la misma IP. Los registros PTR faltantes o desajustados activan filtros de spam.
• Olvidar actualizar DNS después de migrar proveedores de correo. Si cambias de servicios de correo electrónico pero dejas los antiguos registros MX en su lugar, el correo va al proveedor antiguo. Siempre verifica los registros MX después de la migración.
• Configurar TTL demasiado alto antes de una migración. Si tus registros MX tienen un TTL de 24 horas y cambias de proveedor, algunos servidores continuarán entregando al destino antiguo durante hasta 24 horas. Reduce el TTL a 300 segundos por lo menos 48 horas antes del cambio.
• Exceder el límite de 10 búsquedas para SPF. La evaluación de SPF sigue directivas include: y redirect=, cada una generando consultas DNS adicionales. Más de 10 búsquedas causa un error permanente de SPF. Mantén tu registro SPF plano.
• Sin registro MX y sin registro A. Si un dominio no tiene registros MX ni alternativa A/AAAA, el correo a ese dominio no es entregable. Publica registros MX explícitos o como mínimo un registro A.

Impacto en la entregabilidad

• Los registros MX se verifican primero. Si tus registros MX faltan, están mal configurados o apuntan a servidores no alcanzables, ningún correo te llega. Este es el requisito de entregabilidad más fundamental.
• SPF, DKIM y DMARC viven todos en DNS. Cada verificación de autenticación de correo electrónico comienza con una búsqueda de registro TXT. Si tu DNS es lento, no confiable o mal configurado, la autenticación falla y tus mensajes se marcan o se rechazan.
• DNS inverso afecta la reputación del emisor. Los servidores de correo con DNS directo e inverso configurado adecuadamente son más confiables para los servidores receptores. Los registros PTR desajustados o faltantes son una señal fuerte de spam.
• Los retrasos de propagación de DNS afectan migraciones. Al cambiar proveedores de correo electrónico, el almacenamiento en caché de DNS significa que la transición nunca es instantánea. Planifica un período en el que tanto los sistemas antiguo como nuevo deban aceptar correo.
• IPv6 requiere registros AAAA y PTR coincidentes. Si envías desde direcciones IPv6, necesitas registros AAAA para tus nombres de host emisores y registros PTR para las direcciones IPv6. La configuración incompleta de DNS para IPv6 causa fallos de entrega a proveedores que prefieren IPv6.

Related RFCs