Récord MX

Un registro de intercambio de correo (registro MX) especifica el servidor de correo responsable de aceptar mensajes de correo electrónico en nombre de un nombre de dominio. Es un registro de recursos en el Sistema de Nombres de Dominio (DNS). Es posible configurar varios registros MX, normalmente apuntando a una matriz de servidores de correo para balanceo de carga y redundancia.

Resumen

Los registros de recursos son el elemento básico de información del Sistema de nombres de dominio (DNS). Un registro MX es uno de estos, y un dominio puede tener uno o más de estos configurados, como se muestra a continuación:

Domain TTL Class Type Priority Host
example.com. 1936 IN MX 10 onemail.example.com.
example.com. 1936 IN MX 10 twomail.example.com.

La información de carga útil característica de un registro MX es un valor de preferencia (arriba etiquetado como "Prioridad") y el nombre de dominio de un servidor de correo ("Host" arriba).

El campo de prioridad identifica qué servidor de correo debe preferirse; en este caso, los valores son 10, por lo que se espera que el correo fluya uniformemente a onemail.example.com y twomail. ejemplo.com - una configuración común. El nombre de host debe asignarse directamente a uno o más registros de dirección (A o AAAA) en el DNS y no debe apuntar a ningún registro CNAME.

Cuando se envía un mensaje de correo electrónico a través de Internet, el agente de transferencia de correo (MTA) remitente consulta el Sistema de nombres de dominio para los registros MX del nombre de dominio de cada destinatario. Esta consulta devuelve una lista de nombres de host de servidores de intercambio de correo que aceptan correo entrante para ese dominio y sus preferencias. El agente de envío luego intenta establecer una conexión SMTP, probando el host con la "Prioridad" valor primero. El sistema permite crear clústeres de alta disponibilidad de puertas de enlace de correo para un dominio si es necesario.

El mecanismo MX no otorga la capacidad de brindar servicio de correo en números de puerto alternativos, ni brinda la capacidad de distribuir la entrega de correo entre un conjunto de servidores de correo de prioridad desigual mediante la asignación de un valor de ponderación a cada uno.

Preferencia MX, distancia y prioridad

Según RFC 5321, los registros con el número más bajo son los preferidos. Esta redacción puede ser confusa, por lo que el número de preferencia a veces se denomina distancia: las distancias más pequeñas son más preferibles. Un RFC más antiguo, RFC 974, indica que cuando los números de preferencia son los mismos para dos servidores, tienen la misma prioridad, por lo tanto, esos dos términos se usan indistintamente.

Lo básico

En el caso más simple, un dominio puede tener solo un servidor de correo. Por ejemplo, si un MTA busca los registros MX para example.com y el servidor DNS respondió solo con mail.example.com con un número de preferencia de 50, entonces el MTA intentará entregar el correo al servidor indicado. En este caso, el número 50 podría haber sido cualquier número entero permitido por la especificación SMTP.

Cuando se devuelve más de un servidor para una consulta MX, primero se debe probar el servidor con el número de preferencia más bajo. Si hay más de un registro MX con el mismo número de preferencia, se deben probar todos antes de pasar a las entradas de menor prioridad. Un cliente SMTP debe poder probar (y reintentar) cada una de las direcciones relevantes en la lista en orden, hasta que un intento de entrega sea exitoso.

Distribución de carga

El enfoque estándar para distribuir una carga de correo entrante en una matriz de servidores es devolver el mismo número de preferencia para cada servidor del conjunto. Al determinar a qué servidor de igual preferencia enviar correo, "el remitente-SMTP DEBE aleatorizarlos para distribuir la carga entre múltiples intercambiadores de correo para una organización específica", a menos que haya una razón clara para favorecer uno.

Un enfoque alternativo es utilizar servidores multitarjeta, en los que un host devuelve varias direcciones IP. Este método coloca la carga sobre el DNS en lugar del remitente SMTP para realizar el equilibrio de carga, que en este caso presentará una lista de direcciones IP en un orden específico a los clientes que consultan el registro A del intercambiador de correo. Dado que el RFC requiere que el remitente SMTP use el orden dado en la consulta de registro A, el servidor DNS es libre de manipular con cuidado su equilibrio en función de cualquier método, incluido el DNS por turnos, la carga del servidor de correo o algún esquema de prioridad no revelado.

"Copia de seguridad" MX

Algunos dominios tendrán varios registros MX, uno de los cuales está diseñado como "copia de seguridad" - con un número de preferencia más alto para que normalmente no se elija como destino para la entrega de correo electrónico.

Sin embargo, en el caso de errores de los hosts con números más bajos (quizás debido a una interrupción de algún tipo), los servidores de envío de correo electrónico se enviarán a la "copia de seguridad" host - queue.example.com en el siguiente ejemplo:

Domain TTL Class Type Priority Host
example.com. 1936 IN MX 10 onemail.example.com.
example.com. 1936 IN MX 10 twomail.example.com.
ejemplo.com. 1936 IN MX 100 queue.example.com.

Si el servidor de respaldo tiene acceso directo a los buzones de correo de los usuarios, el correo procederá allí, pero de lo contrario probablemente se pondrá en cola en queue.example.com hasta que se resuelva la interrupción.

En ausencia de este tipo de acuerdo, cuando todos los servidores de correo de un dominio están desconectados, los servidores de envío deben poner en cola los mensajes destinados a ese dominio para volver a intentarlo más tarde. Sin embargo, estos servidores de envío no tienen forma de ser notificados de que los servidores de un dominio que anteriormente estaba fuera de línea ahora están disponibles, por lo que recurren a un programa de sondeo y solo descubrirán que el dominio está disponible la próxima vez que intenten realizar la entrega. Por lo tanto, la demora entre el momento en que los servidores de un dominio receptor se conectan y el momento en que finalmente se entregan los mensajes demorados puede ser de minutos a días, según el cronograma de reintentos de los servidores de envío, y el dominio receptor no tiene visibilidad ni control sobre este.

Los spammers

Los spammers pueden dirigir deliberadamente el correo a uno de los servidores MX de respaldo (alta distancia) de un dominio primero, suponiendo que dicho servidor tendrá filtros antispam menos efectivos. Una técnica antispam llamada nolisting se basa en asumir este comportamiento.

Manejo de fallas en la entrega

El SMTP RFC es ambiguo acerca de exactamente qué tipos de fallas en la entrega deben resultar en volver a intentar la entrega a través de registros MX más distantes (aquellos con valores de preferencia más altos).

Cuando los servidores indican fallas temporales, ya sea enviando explícitamente un error 4xx o finalizando la conexión de forma inesperada (que debe tratarse como un error 451, de acuerdo con la Sección 3.8 del RFC), la Sección 4.5.4.1 dice:

El remitente debe retrasar la reiniciación de un destino particular después de que un intento haya fracasado.

Sin embargo, cuando el remitente vuelve a intentarlo, el RFC no dice si debe ser al mismo servidor o a uno más "distante" Récord MX. Sí dice, en la Sección 5.1:

Cuando la búsqueda tiene éxito, la asignación puede resultar en una lista de direcciones de entrega alternativas en lugar de una sola dirección, debido a múltiples registros MX, multihoming o ambos. Para proporcionar una transmisión de correo confiable, el cliente SMTP DEBE poder probar (y volver a entrar) cada una de las direcciones pertinentes de esta lista en orden, hasta que un intento de entrega tenga éxito.

Algunos servidores (como Sendmail y Postfix 2.1 o posterior), intentarán con el siguiente servidor MX después de algunos tipos de fallas de entrega temporales, como fallas de saludo. Otros servidores (como qmail y Postfix 2.0 o anterior) solo usarán registros MX más distantes si no se pudo contactar a los servidores especificados en los registros MX de distancia más corta. A pesar de la diferencia, ambos comportamientos son válidos, ya que el RFC no es específico.

Alternativa al registro de dirección

A falta de un registro MX, los remitentes de correo electrónico intentarán enviar el correo electrónico al registro de dirección, p. ejemplo.com.

Esto se basa en RFC 5321 sec. 5.1, que establece:

• Los clientes SMTP deben buscar un registro MX;
• Siy sólo si) no registro MX para el dominio está presente, tratar el dominio como si tuviera un registro MX con el dominio dado como el nombre de host de destino y un valor de preferencia de 0
• Perform Consultas A o AAAA según sea necesario para determinar la dirección IP del nombre de host de destino

Antecedentes históricos

RFC 821 se publicó en 1982. Solo hace referencias de paso a DNS, porque en ese momento aún no había comenzado la transición de HOSTS.TXT a DNS. RFC 883, la primera descripción del DNS, se publicó más de un año después, a fines de 1983. Describía los registros MD y MF experimentales y poco utilizados. Según RFC 897 y RFC 921, la transición a DNS comenzó en 1983, pero HOSTS.TXT no estaba programado para eliminarse gradualmente hasta finales de 1985 y no se eliminó por completo hasta finales de la década de 1990.

En enero de 1986, RFC 973 y RFC 974 dejaron en desuso los registros MD y MF, los reemplazaron con MX y definieron la búsqueda MX con respaldo a A. RFC 974 recomienda que los clientes realicen una búsqueda WKS en cada host MX para ver si en realidad es compatible con SMTP y descarta la entrada MX si no lo es. Sin embargo, RFC 1123 cambió esto para decir que WKS no debe verificarse.

Esto significa que SMTP estuvo en uso durante al menos un año con HOSTS.TXT y luego otro par de años con A, MD y MF, antes de que apareciera MX. MD y MF eran difíciles de usar, por lo que la mayoría de la gente solo usaba el registro A. Bajo las circunstancias, MX sin respaldo a A no habría funcionado debido a la base sustancial instalada de servidores de correo que usan registros A. El uso temprano de MX fue para identificar puertas de enlace a otras redes, pero no se generalizó hasta que el DNS estuvo bien establecido a principios de la década de 1990.

Documentos de normas

• RFC 1035 (1987), Nombres de dominio - Implementación y Especificación
• RFC 1912 (1996), DNS comunes Errores operativos y de configuración
• RFC 5321 (2008), Protocolo de transferencia de correo simple
• RFC 7505 (2015), Un "Null MX" No hay registro de recursos de servicio para dominios que acepten sin correo

Obsoletos:

• RFC 2821 (2001), Protocolo de transferencia de correo simple (obsoleto por RFC-5321)
• RFC 974 (1986), Mail Routing y el sistema de dominio (obsoleted by RFC-5321)