Un registro MX indica qué nombres de servidor reciben correo para un dominio. No transporta mensajes ni autentica al remitente: publica una preferencia de entrega que otros servidores consultan antes de conectar con el receptor.
El valor de un MX debe ser normalmente un nombre de host, como mail.example.com, y ese nombre necesita resolver mediante A o AAAA. La dirección no se escribe como un literal IP en el campo del intercambiador.
Preferencia y varios receptores
Cada MX tiene una preferencia numérica. En la convención habitual, el valor más bajo se intenta antes y los valores mayores sirven como alternativas. Varios receptores pueden aportar redundancia, aunque el servidor secundario debe estar preparado para aceptar y retener mensajes para el dominio.
La preferencia no es un porcentaje ni una distribución exacta de carga. Los servidores emisores pueden aplicar políticas de reintento diferentes y un receptor con prioridad baja sigue necesitando configuración correcta.
El nombre del MX debe resolver
Si el MX apunta a mail.example.com, ese nombre debe publicar una dirección accesible y el servidor debe aceptar SMTP para el dominio. Un error en A, AAAA, firewall o certificado puede hacer que el MX parezca correcto y el correo no llegue.
Evita apuntar el MX a un alias CNAME si la política del proveedor o el comportamiento de los servidores receptores no lo admite. Usa el nombre de destino recomendado por el servicio de correo y comprueba su documentación.
Recibir no es lo mismo que enviar
MX trata de recepción. El servidor que envía puede usar otro nombre y otra infraestructura. SPF publica qué sistemas están autorizados a enviar; DKIM firma mensajes; DMARC aplica una política y relaciona dominios. Ninguno de esos mecanismos se sustituye por un MX.
Un dominio puede recibir correo en un proveedor y enviar desde otro, siempre que sus registros y políticas estén coordinados. Cambiar MX sin revisar el envío puede dejar mensajes salientes sin autenticación o con una identidad incoherente.
TTL y migración de correo
Los resolvers conservan respuestas MX durante el TTL. Durante una migración, algunos emisores seguirán usando el receptor anterior mientras otros consulten el nuevo. Mantén ambos servicios preparados durante una ventana razonable y planifica cómo copiar o reenviar mensajes que lleguen al sistema antiguo.
Antes del cambio, inventaría buzones, alias, listas, filtros, aplicaciones y credenciales. Después prueba recepción desde dominios externos y envío a varios proveedores. El cambio DNS no migra mensajes almacenados ni crea automáticamente las cuentas.
Errores de configuración comunes
Una prioridad invertida, un nombre mal escrito, un MX sin A o AAAA, un receptor que no acepta el dominio y la eliminación accidental de todos los MX son fallos frecuentes. También puede publicarse un MX en un subdominio cuando el correo utiliza el dominio raíz.
Qué comprobar antes de migrar el correo
Consulta la zona autoritativa, verifica nombres y preferencias, comprueba que los receptores responden y revisa SPF, DKIM y DMARC por separado. Conserva el valor anterior y define una vuelta atrás. MX dirige la entrega; la disponibilidad, el contenido de los buzones y la autenticación requieren controles adicionales.
El camino desde el dominio hasta el receptor
Un servidor emisor consulta los MX del dominio destinatario y obtiene nombres de intercambiadores con sus preferencias. Después resuelve esos nombres mediante A o AAAA y trata de entregar el mensaje por SMTP. Una respuesta MX válida no garantiza que el destino acepte el mensaje ni que el buzón exista.
Si dos MX tienen la misma preferencia, el emisor puede elegir cualquiera. Si uno tiene un número menor, normalmente se intentará antes, pero los reintentos y decisiones concretas dependen del servidor emisor.
Redundancia que debe estar operativa
Un segundo MX solo aporta valor si puede aceptar correo temporalmente, almacenar la cola y entregarla después. Publicar un host alternativo que rechaza mensajes puede retrasar la entrega o generar avisos. Prueba ambos destinos y documenta cómo se sincronizan cuentas, filtros y políticas.
Qué sucede durante una migración
Reduce TTL con antelación y mantén preparado el sistema antiguo mientras las cachés expiran. Copia buzones, alias y reglas por separado: cambiar MX no mueve mensajes ni contraseñas. Después comprueba envío y recepción desde varios proveedores, además de SPF, DKIM y DMARC, que son controles independientes.
Prioridad no sustituye a la disponibilidad
El receptor de preferencia menor se intenta normalmente antes, pero debe tener capacidad, buzones, filtros y políticas equivalentes. Si el secundario acepta mensajes y luego no puede entregarlos, la redundancia se convierte en una cola difícil de rastrear. Prueba rechazos temporales y permanentes, no solo una entrega correcta.
Separar entrega y autenticación
Un MX puede dirigir el correo a un proveedor mientras DKIM se firma en otro sistema o SPF autoriza varias fuentes. Coordina los nombres usados por cada servicio y comprueba que el dominio visible, el Return-Path y la firma no se han desalineado durante la migración. El MX sigue siendo únicamente una indicación de recepción.
Validación final del correo
Lista receptores, preferencias, A/AAAA, puertos, buzones, alias, filtros y políticas de autenticación. Mantén una ventana de coexistencia y monitoriza rebotes. El TTL facilita planificar el cambio, pero no controla las cachés de todos los emisores.