Registro MX: ex­pli­ca­ción de la entrada DNS

El registro MX (Mail Exchange Record o MX record) es una entrada del Sistema de Nombres de Dominio (Domain Name System, DNS) que indica qué servidor de correo es el re­s­po­n­sa­ble de recibir los mensajes ele­c­tró­ni­cos de un dominio. Este registro garantiza que los correos entrantes se redirijan co­rre­c­ta­me­n­te al servidor adecuado.

Ex­pli­ca­ción del registro MX con un ejemplo

Los registros DNS están co­n­te­ni­dos en archivos de zona, que son simples archivos de texto que agrupan todos los registros re­fe­re­n­tes a la zona de la cual se ocupa el servidor en cuestión. Cuando un cliente realiza una solicitud, el servidor receptor obtiene la in­fo­r­ma­ción necesaria de este archivo. Los distintos tipos de registro tienen funciones di­fe­re­n­tes. La abre­via­tu­ra MX significa mail exchange (in­te­r­ca­m­bio de correo ele­c­tró­ni­co), lo que ya nos da una pista sobre la función del registro: mediante el registro MX, y según el DNS, el servidor de correo emisor (MTA) averigua en qué dominio se encuentra el servidor de correo ele­c­tró­ni­co adecuado.

No­r­ma­l­me­n­te, un mismo dominio funciona con varios se­r­vi­do­res: además del servidor web, que provee la página web, a menudo también un servidor FTP y uno o incluso varios se­r­vi­do­res de correo ele­c­tró­ni­co. A todos ellos se accede a través de distintos su­b­do­mi­nios. El registro MX se usa ex­clu­si­va­me­n­te para correo; web o FTP se resuelven con A/AAAA (o CNAME según el caso). De este proceso se encarga, en general, de forma au­to­má­ti­ca, el servidor de correo ele­c­tró­ni­co emisor.

Campos y sintaxis de los registros

Los registros DNS están co­m­pue­s­tos de varias in­fo­r­ma­cio­nes agrupadas en distintos campos. Además de indicar el servidor de correo ele­c­tró­ni­co de un dominio en concreto, se pueden añadir muchos otros detalles:

• <name>: el primer campo contiene el nombre del dominio.
• <ttl>: el time to live indica durante cuánto tiempo se garantiza la validez de la in­fo­r­ma­ción.
• <class>: este campo es­pe­ci­fi­ca la clase de red.
• <type>: el tipo de registro DNS es, en este caso, MX.
• <priority>: cuanto menor sea este valor, mayor es la prioridad del servidor de correo ele­c­tró­ni­co.
• <rdata>: resource data define el nombre del servidor de correo.

Los nombres de dominio toman en todos los tipos de registro la forma de Fully Qualified Domain Name (FQDN), lo que significa, bá­si­ca­me­n­te, que el contenido de cada campo acaba en un punto. Los FQDN forman, de hecho, una ruta entera, desde la unidad más pequeña (a la izquierda), hasta la más grande (a la derecha): el servidor raíz. El nivel más alto, sin embargo, se omite, por lo que el punto que lo precede marca el final del nombre.

El time to live indica por cuánto tiempo el so­li­ci­ta­n­te puede guardar y usar la in­fo­r­ma­ción en la memoria caché, para ga­ra­n­ti­zar que no se usen registros des­ac­tua­li­za­dos. Una vez tra­n­s­cu­rri­do el tiempo, el cliente debe solicitar de nuevo el registro al servidor de nombres. El TTL se da en segundos y, a menudo, no aparece en el registro en sí, sino que el tiempo se define al principio del archivo de zona y se aplica a la zona entera.

El campo class es opcional, ya que hoy en día la única red di­s­po­ni­ble es Internet. Cuando se in­tro­du­je­ron por primera vez los registros de recursos, sin embargo, las clases de red Hesiod (HS) y Chaosnet (CH) aún se uti­li­za­ban. Puesto que ya no es así, el campo puede, o bien quedar en blanco, o bien llenarse, sin excepción, con la abre­via­tu­ra IN, de Internet.

En cuanto al campo de priority, se trata de una pa­r­ti­cu­la­ri­dad de los registros MX. Muchos ad­mi­ni­s­tra­do­res, sobre todo en proyectos grandes, hacen funcionar varios se­r­vi­do­res de correo ele­c­tró­ni­co pa­ra­le­la­me­n­te, para así evitar fallos o posibles so­bre­ca­r­gas que deriven en in­te­rru­p­cio­nes ine­s­pe­ra­das de la co­mu­ni­ca­ción. El reparto de correos, en estos casos, no es igua­li­ta­rio, sino que deben es­ta­ble­ce­r­se prio­ri­da­des. El servidor con el número más bajo tiene la mayor prioridad y, por lo tanto, a él se dirige el primer intento. Si no está di­s­po­ni­ble, se escogerá el siguiente servidor con el menor valor.

Por último, el campo rdata contiene el nombre del servidor de correo ele­c­tró­ni­co, que también aparece en forma de Fully Qualified Domain Name (FQDN). En el registro se disponen todos los campos, uno tras otro, en una misma línea. El registro no acaba con ningún símbolo concreto, basta con un salto de línea.

Ejemplo de MX record

Como ejemplo, tomamos el servidor ficticio de correo ele­c­tró­ni­co example.com, con el cual te­n­dría­mos una dirección de correo como user@example.com. El servidor web del emisor enviaría, por lo tanto, una solicitud DNS al dominio example.com. En el archivo de zona del servidor de nombres, los registros co­rre­s­po­n­die­n­tes tendrían esta es­tru­c­tu­ra:

$TTL 1200
example.com.	IN	A		93.184.216.34
example.com.	IN	MX	10	mail1.example.com.
example.com.	IN	MX	10	mail2.example.com.
example.com.	IN	MX	50	mail3.example.com.

Como se puede ver, la caducidad de la in­fo­r­ma­ción se aplica a la zona entera, de forma que el campo puede omitirse luego en cada uno de los registros. En este ejemplo hemos puesto en primer lugar un registro A, que enlaza el dominio con una dirección IP. A co­n­ti­nua­ción aparecen tres registros MX que, como se observa, solo se di­fe­re­n­cian en sus su­b­do­mi­nios.

Los dos primeros se­r­vi­do­res de correo tienen, en el ejemplo, el mismo nivel de prioridad (10), lo cual significa que las tareas se reparten igua­li­ta­ria­me­n­te entre ambos. Al tercer servidor se recurre solo cuando los primeros no pueden hacerse cargo de ellas (a causa de un fallo, por ejemplo).

Aspectos de seguridad al co­n­fi­gu­rar registros MX

Al crear registros MX es im­po­r­ta­n­te prestar atención a la seguridad y evitar errores. Los registros MX nunca deben apuntar di­re­c­ta­me­n­te a di­re­c­cio­nes IP, sino siempre a nombres de dominio completos (FQDN) que, a su vez, se resuelvan mediante registros A o AAAA. Tampoco está permitido usar un CNAME como destino de un registro MX, ya que esta práctica co­n­tra­vie­ne los es­tá­n­da­res DNS y puede provocar problemas de entrega. Los se­r­vi­do­res de correo de destino deben poder re­so­l­ve­r­se co­rre­c­ta­me­n­te mediante DNS y ser ac­ce­si­bles; de lo contrario, pueden pro­du­ci­r­se mensajes de error o pérdida de correos ele­c­tró­ni­cos.

Para prevenir el spam y el spoofing, es re­co­me­n­da­ble co­n­fi­gu­rar también registros SPF, DKIM y DMARC que ga­ra­n­ti­cen la au­te­n­ti­ci­dad del dominio remitente. Estos son me­ca­ni­s­mos de seguridad para el correo ele­c­tró­ni­co:

• SPF garantiza que solo los se­r­vi­do­res au­to­ri­za­dos puedan enviar correos en nombre de un dominio.
• DKIM asegura que los mensajes estén firmados di­gi­ta­l­me­n­te y pro­te­gi­dos contra ma­ni­pu­la­cio­nes.
• DMARC indica a los se­r­vi­do­res re­ce­p­to­res cómo deben tratar los mensajes que no superen la au­te­n­ti­ca­ción.

Co­n­fi­gu­rar registros MX

Si quieres gestionar tu co­mu­ni­ca­ción de correo ele­c­tró­ni­co em­pre­sa­rial a través de Google Workspace o Microsoft 365, es obli­ga­to­rio co­n­fi­gu­rar co­rre­c­ta­me­n­te el registro MX en la zona DNS de tu dominio. Solo así podrás ga­ra­n­ti­zar que los correos entrantes se entreguen de forma fiable en los se­r­vi­do­res de correo del proveedor co­rre­s­po­n­die­n­te.

Co­n­fi­gu­rar un registro MX en Google Workspace

Si quieres recibir correos ele­c­tró­ni­cos a través de la he­rra­mie­n­ta de co­la­bo­ra­ción Google Workspace, debes añadir el servidor oficial de Google como registro MX en la zona DNS de tu dominio. Para ello, sigue estos pasos:

1. Elimina todos los registros MX exi­s­te­n­tes.

2. Añade el siguiente registro MX para el servidor de correo de Google:

@	IN	MX	1	smtp.google.com.

3. Inicia sesión en la consola de ad­mi­ni­s­tra­ción de Google con tu cuenta de ad­mi­ni­s­tra­dor y, desde la co­n­fi­gu­ra­ción de la cuenta, accede a tus dominios. Activa Gmail en el dominio cuyo registro MX quieras ac­tua­li­zar.

Ten en cuenta que la pro­pa­ga­ción del registro MX puede tardar hasta 72 horas en co­m­ple­tar­se.

Co­n­fi­gu­rar un registro MX en Microsoft 365

Con Microsoft 365 también puedes co­n­fi­gu­rar fá­ci­l­me­n­te un registro MX para que los correos dirigidos a usuarios de tu dominio se envíen a los se­r­vi­do­res de Microsoft 365. El pro­ce­di­mie­n­to es similar al ya descrito:

1. Elimina todos los registros MX exi­s­te­n­tes.
2. Inicia sesión en el Centro de ad­mi­ni­s­tra­ción de Microsoft 365. Haz clic en “Ver todo” -> “Co­n­fi­gu­ra­ción” -> “Dominios”. Allí en­co­n­tra­rás el registro MX que debes utilizar.
3. Copia el registro MX, créalo en tu proveedor de hosting y guarda los cambios.

Cómo consultar un registro MX

Para realizar un llamado “MX record check”, es decir, para consultar el registro MX, se puede recurrir a di­fe­re­n­tes servicios web. Uno de los más prácticos y fáciles de usar es Public DNS de Google. En su página de inicio se introduce el dominio cuyos registros MX se quiere consultar y, en la página siguiente, se cambia el tipo de registro por defecto de A a MX. Las opciones de EDNS Client Subnet y de DNSSEC pueden dejarse como están. La primera sirve para acelerar la tra­n­s­mi­sión de in­fo­r­ma­cio­nes DNS, mientras que la segunda garantiza que las in­fo­r­ma­cio­nes no han sido ma­ni­pu­la­das por terceros con fines de­li­c­ti­vos.

Close

En el ejemplo de búsqueda, en el apartado “Answer” se ide­n­ti­fi­ca el servidor de correo. El FQDN mediante el cual se puede acceder a este servidor aparece en el campo “Data”, donde también se indica la prioridad: en este caso, el registro mostrado tiene una prioridad de 10. En el campo “Type” figura el número 15, que co­rre­s­po­n­de a un registro MX. Esto se debe a que la Internet Assigned Numbers Authority (IANA) ha asignado un valor numérico a cada tipo de registro DNS, numerando así las di­fe­re­n­tes clases de entradas.