Correo corporativo
Registros MX: cómo apuntar el correo sin romper la operación
Orden de prioridad MX, TTL y errores típicos al migrar de un proveedor de correo a otro.
11 min de lectura · Actualizado 2026-07-22
Cómo funcionan los registros MX
MX (Mail Exchange) indica qué servidores reciben correo para @tudominio.com. Cada registro tiene prioridad (pref) y hostname destino. Menor número = mayor preferencia: MX 10 mail.tudominio.com se intenta antes que MX 20 backup.proveedor.com.
El hostname MX debe resolver a A/AAAA records; un MX apuntando a un CNAME puro viola RFC y algunos servidores lo rechazan. Google Workspace usa aspmx.l.google.com; Microsoft 365 usa algo como tudominio-com.mail.protection.outlook.com.
Puedes tener varios MX del mismo proveedor con distintas prioridades para redundancia. No mezcles MX de dos proveedores activos con la misma prioridad esperando «balanceo»: el correo irá al primer servidor que responda, no se reparte 50/50.
Consulta MX actuales con dig MX tudominio.com o /toolbox/dns-suite antes de cualquier cambio. Captura pantalla del estado previo para rollback.
Plan de migración sin pérdida de correo
48 horas antes: baja TTL de registros MX y relacionados (A del mail server) a 300 segundos. Crea buzones en el proveedor nuevo sin tocar MX aún. Configura SPF/DKIM/DMARC para el nuevo emisor en paralelo.
Ventana de cambio: actualiza MX al nuevo proveedor. Mantén el proveedor anterior activo al menos 48–72 horas (dual delivery si el plan lo permite, o reenvío temporal desde el viejo al nuevo). Monitorea /toolbox/dns-propagation en resolvers Google, Cloudflare y OpenDNS.
Valida recepción enviando desde Gmail externo a [email protected] y respondiendo desde el buzón nuevo. Prueba envío saliente con /toolbox/mail-tester. Solo entonces cancela el servicio anterior.
Error clásico: cambiar MX el viernes tarde sin equipo de guardia. Mitad de resolvers entrega al servidor viejo ya apagado = bounce permanente y pérdida de leads.
Errores típicos y cómo evitarlos
MX apuntando a IP en lugar de hostname: algunos paneles permiten MX 10 203.0.113.5 — funciona en casos limitados pero rompe si la IP cambia. Usa hostname estable del proveedor.
Olvidar MX secundario: si solo publicas MX 10 y el host cae, el correo rebota. Google y Microsoft publican varios MX; imítalo o acepta el riesgo documentado.
Conflicto apex CNAME + MX: si migraste la web a CDN con CNAME en @ y el DNS no soporta ALIAS, puedes haber roto MX/TXT. Ver guía cname-apex-errores. MX y SPF deben seguir en el apex.
Registro MX duplicado en dos paneles DNS (registrador y Cloudflare activos a la vez) genera respuestas inconsistentes. Un solo authoritative DNS activo.
MX y autenticación saliente
MX define recepción; no autoriza envío. Cambiar MX a Microsoft no elimina la necesidad de SPF include:spf.protection.outlook.com. Tras migración, muchos envían bien desde M365 pero fallan en DMARC porque el SPF del hosting viejo sigue en DNS sin el include nuevo.
Autodiscover (Outlook) y SRV records son complementarios en M365; Google usa MX únicamente para routing básico. Sigue las instrucciones exactas del proveedor destino — copiar MX de un blog genérico sin verificar tenant ID rompe recepción.
Subdominios: correo en @tudominio.com usa MX del apex. Si recibes en soporte.tudominio.com, necesitas MX específico en ese subdominio o wildcard policy documentada.
Tras migración, ejecuta /toolbox/email-deliverability para validar MX, SPF, DKIM y DMARC en conjunto. MX correcto con SPF viejo sigue generando spam en salida.
Checklist post-migración
□ MX resuelve globalmente (/toolbox/dns-propagation). □ Recepción externa OK (Gmail → tudominio). □ Envío OK (Mail Tester ≥ 8/10, SPF/DKIM pass). □ DKIM selectores activos en admin del proveedor. □ DMARC rua recibiendo reportes. □ Autodiscover/CalDAV si usas clientes móviles. □ TTL restaurado a 3600+ tras estabilizar.
Monitoriza cola de rebotes y tickets «no recibí tu correo» la primera semana. Bounces 550 5.1.1 indican buzón inexistente; 550 5.7.1 suelen ser filtros o auth.
Documenta MX finales, proveedor, fecha de corte y contacto de escalación en runbook interno. Facilita auditorías y evita que un consultor futuro «optimice DNS» borrando MX críticos.
Si la migración incluye cientos de buzones o integración ERP, considera acompañamiento de ingeniería en hosting administrado para ventana controlada y rollback planificado.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.