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, que normalmente apuntan a una matriz de servidores de correo para equilibrar la carga y lograr redundancia.
Los registros de recursos son el elemento de información básico del Sistema de nombres de dominio (DNS). Un registro MX es uno de ellos y un dominio puede tener uno o más de ellos configurados, como se muestra a continuación:
Dominio TTL Clase Tipo Prioridad Host ejemplo.com. 1936 IN MX 10 onemail.ejemplo.com. ejemplo.com. 1936 IN MX 10 twomail.ejemplo.com. La información de carga útil característica de un registro MX [1] es un valor de preferencia (denominado arriba "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, ambos valores son 10, por lo que se esperaría que el correo fluyera de manera uniforme tanto a onemail.example.com como a twomail.example.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 . [2]
Cuando se envía un mensaje de correo electrónico a través de Internet, el agente de transferencia de correo (MTA) emisor consulta al Sistema de nombres de dominio 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. A continuación, el agente emisor intenta establecer una conexión SMTP, probando primero el host con el valor de "Prioridad" más bajo. El sistema permite crear clústeres de alta disponibilidad de puertas de enlace de correo para un dominio si es necesario. [3]
El mecanismo MX no otorga la capacidad de proporcionar servicio de correo en números de puerto alternativos , ni tampoco brinda la capacidad de distribuir la entrega de correo entre un conjunto de servidores de correo con prioridad desigual asignando un valor de ponderación a cada uno.
Según el RFC 5321, los registros con el número más bajo son los más preferidos. [4] Esta redacción puede ser confusa, por lo que a veces se hace referencia al número de preferencia como la distancia : las distancias más pequeñas son más preferibles. Un RFC más antiguo, el RFC 974, indica que cuando los números de preferencia son los mismos para dos servidores, tienen la misma prioridad , por lo que esos dos términos se usan indistintamente.
El número de preferencia es un campo sin signo [5] de 16 bits [5] [6] , por lo que los valores válidos varían de 0 a 65535.
En el caso más simple, un dominio puede tener solo un servidor de correo. Por ejemplo, si un MTA busca los registros MX de example.com y el servidor DNS responde 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, se debe probar primero 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 ellos antes de pasar a las entradas de menor prioridad. Un cliente SMTP debe poder probar (y volver a intentar) cada una de las direcciones relevantes de la lista en orden, hasta que se realice un intento de entrega. [4]
El método estándar para distribuir una carga de correo entrante entre una serie de servidores es devolver el mismo número de preferencia para cada servidor del conjunto. Al determinar a qué servidor de igual preferencia enviar el correo, "el SMTP del remitente DEBE aleatorizarlos para distribuir la carga entre varios intercambiadores de correo para una organización específica", a menos que exista una razón clara para favorecer a uno de ellos. [4]
Un enfoque alternativo es utilizar servidores multihomed , donde un host devuelve varias direcciones IP. [3] 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 consulten el registro A del intercambiador de correo. Dado que el RFC requiere que el remitente SMTP use el orden dado en la consulta del registro A, el servidor DNS es libre de manipular cuidadosamente su equilibrio basándose en cualquier método, incluyendo round robin DNS , carga del servidor de correo o algún esquema de prioridad no revelado.
Algunos dominios tendrán varios registros MX, uno de los cuales está destinado a ser un "respaldo" (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 entregarán al host de "respaldo": queue.example.com en el siguiente ejemplo:
Dominio TTL Clase Tipo Prioridad Host ejemplo.com. 1936 IN MX 10 onemail.ejemplo.com. ejemplo.com. 1936 IN MX 10 twomail.ejemplo.com. ejemplo.com. 1936 IN MX 100 cola.ejemplo.com. Si el servidor de respaldo tiene acceso directo a los buzones de correo de los usuarios, el correo se enviará allí, pero de lo contrario, probablemente quedará 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 fuera de línea, 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 recibir una notificación de que los servidores de un dominio que antes 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 cuando vuelvan a intentar la entrega. Por lo tanto, el retraso entre el momento en que los servidores de un dominio receptor se conectan y el momento en que finalmente se entregan los mensajes retrasados puede ser de minutos a días, según el programa de reintentos de los servidores de envío, y el dominio receptor no tiene visibilidad ni control sobre esto.
Los spammers pueden dirigir deliberadamente el correo a uno de los servidores MX de respaldo (a gran distancia) de un dominio, suponiendo que dicho servidor tendrá filtros antispam menos efectivos. Una técnica antispam llamada nolisting se basa en asumir este comportamiento.
El RFC SMTP [4] es ambiguo acerca de exactamente qué tipos de fallas de entrega deben resultar en un nuevo intento de 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 inesperadamente (lo que debe tratarse como un error 451, según la Sección 3.8 del RFC), la Sección 4.5.4.1 dice:
El remitente DEBE retrasar el reintento de un destino en particular luego de que un intento haya fallado.
Sin embargo, cuando el remitente vuelve a intentarlo, la RFC no dice si debe hacerlo al mismo servidor o a un registro MX más "distante". En la Sección 5.1, sí dice:
Cuando la búsqueda se realiza correctamente, la asignación puede dar como resultado una lista de direcciones de entrega alternativas en lugar de una única dirección, debido a la existencia de múltiples registros MX, multihoming o ambos. Para proporcionar una transmisión de correo confiable, el cliente SMTP DEBE poder probar (y volver a intentar) cada una de las direcciones relevantes de esta lista en orden, hasta que un intento de entrega tenga éxito.
Algunos servidores (como Sendmail y Postfix 2.1 o posterior), [7] intentarán utilizar el servidor MX más cercano después de algunos tipos de fallas de entrega temporales, como fallas de saludo. [8] Otros servidores (como qmail y Postfix 2.0 o anterior) solo utilizarán registros MX más distantes si no se pudo contactar en absoluto 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 la RFC no es específica.
En ausencia de un registro MX, los remitentes de correo electrónico intentarán la entrega al registro de dirección, por ejemplo, ejemplo.com.
Esto se basa en el RFC 5321 sec. 5.1, que establece:
El RFC 821 se publicó en 1982. Solo hace referencias pasajeras al DNS, porque en ese momento la transición de HOSTS.TXT al DNS aún no había comenzado. El 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 el RFC 897 y el RFC 921, la transición al DNS comenzó en 1983, pero no estaba previsto que HOSTS.TXT se eliminara gradualmente hasta fines de 1985 y no se eliminó por completo hasta fines de la década de 1990.
En enero de 1986, RFC 973 y RFC 974 dejaron obsoletos 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 [9] en cada host MX para ver si realmente admite SMTP y descartar la entrada MX si no lo hace. Sin embargo, RFC 1123 cambió esto para decir que no se debe verificar WKS .
Esto significa que SMTP había estado en uso durante al menos un año utilizando HOSTS.TXT, y luego un par de años más utilizando 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 simplemente utilizaba el registro A. En esas circunstancias, MX sin el respaldo a A no habría funcionado debido a la importante base instalada de servidores de correo que utilizan registros A. El uso inicial 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. [10]
Obsoletos:
Para cada MX, se debe emitir una consulta WKS para ver si el nombre de dominio que figura en la lista realmente admite el servicio de correo deseado. Los RR de MX que incluyan nombres de dominio que no admitan el servicio deben descartarse. Este paso es opcional, pero se recomienda encarecidamente.