Un registro de intercambiador 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 serie de servidores de correo para equilibrio de carga y 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 estos, y un dominio puede tener uno o más de estos configurados, como se muestra a continuación:
Dominio TTL Clase Tipo Prioridad Host ejemplo.com. 1936 EN MX 10 onemail.ejemplo.com. ejemplo.com. 1936 EN MX 10 doscorreo.ejemplo.com. La información de carga útil característica de un registro MX [1] es un valor de preferencia (arriba denominado "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 esperaría que el correo fluya uniformemente 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) que lo envía consulta el sistema de nombres de dominio para obtener 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. Luego, el agente remitente intenta establecer una conexión SMTP, probando primero el host con el valor de "Prioridad" más bajo. El sistema permite crear grupos de puertas de enlace de correo de alta disponibilidad 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 brinda la capacidad de distribuir la entrega de correo entre un conjunto de servidores de correo de prioridad desigual asignando un valor de ponderación a cada uno.
Según RFC 5321, los registros con el número más bajo son los más preferidos. [4] Esta redacción puede resultar 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 que esos dos términos se usan indistintamente.
El número de preferencia es un campo [5] [5] [6] de 16 bits sin signo , por lo que los valores válidos oscilan entre 0 y 65535.
En el caso más sencillo, un dominio puede tener un solo servidor de correo. Por ejemplo, si un MTA busca los registros MX de ejemplo.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, se debe probar primero el servidor con el número de preferencia más pequeño. Si hay más de un registro MX con el mismo número de preferencia, se deben probar todos antes de pasar a 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 el intento de entrega tenga éxito. [4]
El enfoque 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 correo, "el SMTP del remitente DEBE distribuirlos aleatoriamente 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. [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 consultan el registro A del intercambiador de correo. Dado que el RFC requiere que el remitente SMTP utilice 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, incluido el DNS por turnos , la 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á pensado 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 entregarán al host "de respaldo": queue.example.com en el siguiente ejemplo:
Dominio TTL Clase Tipo Prioridad Host ejemplo.com. 1936 EN MX 10 onemail.ejemplo.com. ejemplo.com. 1936 EN MX 10 doscorreo.ejemplo.com. ejemplo.com. 1936 EN MX 100 cola.ejemplo.com. Si el servidor de respaldo tiene acceso directo a los buzones de correo de los usuarios, el correo continuará 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 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 ser notificados de que los servidores de un dominio previamente 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 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, dependiendo del programa de reintentos de los servidores emisores, y el dominio receptor no tiene visibilidad ni control sobre esto.
Los spammers pueden dirigir deliberadamente el correo primero a uno de los servidores MX de respaldo (de alta distancia) de un dominio, asumiendo que dicho servidor tendrá filtros antispam menos efectivos. Una técnica antispam llamada nolisting se basa en asumir este comportamiento.
El SMTP RFC [4] es ambiguo acerca de exactamente qué tipos de fallas en la 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 después de que un intento haya fallado.
Sin embargo, cuando el remitente vuelve a intentarlo, el RFC no dice nada sobre si debe ser en el mismo servidor o en un registro MX más "distante". Dice, en la Sección 5.1:
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 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 intentar) cada una de las direcciones relevantes en esta lista en orden, hasta que el intento de entrega tenga éxito.
Algunos servidores (como Sendmail y Postfix 2.1 o posterior), [7] intentarán acceder al siguiente servidor MX más lejano después de algunos tipos de fallas de entrega temporales, como fallas de saludo. [8] Otros servidores (como qmail y Postfix 2.0 o anteriores) 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.
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 RFC 5321 sec. 5.1, que establece:
RFC 821 se publicó en 1982. Sólo hace referencias pasajeras al DNS, porque en ese momento la transición de HOSTS.TXT al DNS aún no había comenzado. RFC 883, la primera descripción del DNS, se publicó más de un año después, a finales 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 no estaba previsto que HOSTS.TXT fuera eliminado hasta finales de 1985 y no se eliminó por completo hasta finales de los años 1990.
En enero de 1986, RFC 973 y RFC 974 desaprobaron 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 en realidad es compatible con SMTP y, si no, descarta la entrada MX. 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 usando HOSTS.TXT, y luego un par de años más usando 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 usaba el registro A. Dadas las circunstancias, MX sin recurrir 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 enumerado realmente admite el servicio de correo deseado. Los RR MX que enumeran nombres de dominio que no admiten el servicio deben descartarse. Este paso es opcional, pero se recomienda encarecidamente.