Registros MX para cold email: cómo recibir respuestas sin romper el dominio

Cuando alguien responde a usuario@empresa.com, el servidor remitente consulta DNS para localizar los Mail Exchangers del dominio. RFC 5321 define esa resolución: si existen varios MX, los ordena por preferencia y favorece el número más bajo. El registro dirige correo entrante; no contiene el buzón ni decide por sí solo si ese buzón existe.

MX tampoco autoriza el envío. SPF declara fuentes permitidas, DKIM firma mensajes y DMARC evalúa alineación y política. Puedes tener autenticación correcta y un MX roto; el dominio enviará, pero las respuestas pueden rebotar o llegar a otro proveedor. También puedes recibir bien y fallar autenticación al salir. Son recorridos distintos.

Por eso un check genérico que muestra un MX verde no termina la auditoría. Hay que confirmar que apunta al proveedor esperado, que ese proveedor reconoce el dominio y el mailbox, y que una respuesta real aparece después en sender y CRM. DNS explica la ruta. La prueba end to end confirma la operación.

La documentación actual de Google Workspace indica `smtp.google.com` como valor MX, prioridad 1, para el dominio raíz —normalmente `@` o campo vacío según el registrador—. Google advierte que otros MX antiguos o incorrectos pueden impedir que el correo funcione como se espera y que el formato exacto, incluido un punto final, depende del proveedor DNS.

Publicar el registro no basta. El administrador debe verificar propiedad del dominio y activar Gmail desde la consola. Google señala que el cambio puede tardar hasta 72 horas en ser reconocido y ofrece Admin Toolbox Dig para observar los MX publicados. Esa ventana es un máximo documentado, no una invitación a lanzar antes de comprobar.

No copies un screenshot de otra cuenta ni una guía vieja si la consola te muestra otra instrucción aplicable. Registra dominio, proveedor, host, prioridad, destino, hora del cambio y cuenta administrativa. El objetivo no es memorizar un hostname; es poder demostrar qué configuración pidió el proveedor para ese dominio y cuándo quedó activa.

Microsoft 365 usa un destino con formato `<MX token>.mail.protection.outlook.com`. El token se obtiene en el centro de administración para el dominio concreto; no debe inventarse a partir del nombre comercial. Microsoft documenta TTL de 3600 y una prioridad menor que cualquier MX alternativo para que Exchange Online sea el destino preferido.

La advertencia operativa es directa: cuando actualizas el MX, todo correo nuevo dirigido al dominio empieza a llegar a Microsoft 365. Por eso Microsoft pide crear usuarios y mailboxes antes del cambio. El correo histórico permanece en el proveedor anterior salvo que se ejecute una migración separada.

Después de confirmar flujo hacia Exchange Online, Microsoft recomienda retirar los MX que apuntan al sistema anterior. Mantener ambos sin un diseño explícito no divide usuarios de manera inteligente. La preferencia define el orden de servidores; no dice que ventas vaya a Microsoft y soporte al proveedor viejo.

En MX, un número menor expresa mayor preferencia. Un registro con prioridad 1 se intenta antes que otro con 10. Si varios destinos comparten prioridad y no existe otra razón para elegir, RFC 5321 pide que el emisor distribuya la selección. Eso puede servir en una arquitectura coordinada, no para improvisar dos proveedores que desconocen los mismos mailboxes.

El MX secundario suele actuar cuando el preferido no está disponible; no es una copia automática del correo. Si el proveedor alternativo acepta un mensaje para una cuenta que no conoce o aplica otra política, el resultado puede ser rebote, cola o entrega en un lugar que el equipo no monitorea. Más registros no siempre significan más resiliencia.

Antes de borrar o añadir, clasifica cada MX: proveedor actual, legado, gateway de seguridad, ruta híbrida o desconocido. Un gateway puede ser intencional. Un registro legado puede ser riesgo. Si no sabes por qué existe, no lo retires durante una campaña activa; asigna dueño, confirma el flujo y prepara rollback.

Primero, haz un inventario de dominios, alias y mailboxes. Para cada uno conserva proveedor actual, destino MX observado, configuración esperada, usuarios, catch-all si existe, grupos, reenvíos, sender conectado y campañas abiertas. Añade quién controla DNS y quién puede activar el servicio nuevo. El momento de descubrir que nadie tiene acceso al registrador no debería ser después del corte.

Segundo prepara destino y datos antes de mover la ruta: dominio verificado, usuarios creados, mailboxes licenciados, alias y grupos necesarios, autenticación y acceso del sender. Define una ventana con volumen reducido y sin launches. Exporta estado de secuencias, supresiones y replies pendientes. Si una campaña no puede pausarse por inbox, ya encontraste otra deuda operativa.

Tercero cambia los MX según el proveedor, observa resolvers públicos y prueba recepción. Mantén acceso al sistema anterior durante la ventana de transición para detectar correo que llegue por cachés o rutas todavía vigentes. Define criterios de rollback —por ejemplo, rechazo sostenido o mailboxes críticos sin recepción— y una persona autorizada para ejecutarlo.

Usa una cuenta externa controlada para enviar a cada tipo de mailbox: persona, alias, grupo y dirección usada por el sender. Incluye un identificador único en asunto y cuerpo. Verifica hora, destinatario, carpeta, headers y proveedor que recibió. Una prueba desde otra cuenta del mismo tenant puede seguir una ruta interna y ocultar el problema de MX público.

Después responde desde el mailbox migrado. Confirma que el mensaje aparece en Instantly, Smartlead u otra plataforma, se atribuye a la campaña y contacto correctos, detiene el follow-up y actualiza CRM una sola vez. Si llega a Gmail o Outlook pero no al sender, MX ya hizo su trabajo; ahora debes revisar OAuth, IMAP, API, threading o webhooks.

Repite desde más de una red o proveedor externo cuando el cambio sea crítico y conserva timestamp. No necesitas enviar pruebas a prospectos. Un dominio puede resolver distinto temporalmente por caché, así que la evidencia debe cubrir la ruta real sin convertir clientes en monitores involuntarios.

El primero es configurar MX en `www` cuando los correos usan el dominio raíz. El segundo es apuntar a una IP o CNAME improvisado en vez del hostname que entrega el proveedor; RFC 5321 espera que el destino MX sea un nombre que resuelva a direcciones del servidor. El tercero es copiar el MX de Microsoft sin el token del tenant.

Otro error es mezclar old provider y new provider con prioridades distintas esperando una migración por porcentaje. También aparece el dominio activado sin mailboxes, el alias olvidado, el grupo que rechaza externos y el sender que conserva una conexión al buzón anterior. Todos pueden producir respuestas ausentes mientras el envío continúa.

No culpes al copy cuando el reply rate cae justo después de un cambio DNS. Primero compara mensajes reales en el buzón, eventos del sender y registros CRM. Tampoco concluyas que MX determina inbox placement: spam, autenticación, reputación y contenido se evalúan en otras capas. Un diagnóstico útil separa recepción propia de entrega al prospecto.

Conserva expected_mx y observed_mx, proveedor, prioridad, checked_at y último test inbound exitoso. Por mailbox añade provider account ID, estado de licencia, último mensaje recibido, último sync del sender y reply_sync_lag. Una captura mensual no basta durante un cutover; la frecuencia debe seguir el riesgo y la ventana de cambio.

Alerta cuando el MX observado deja de coincidir con el esperado, un dominio activo publica destinos desconocidos o la prueba externa no llega. Separa esa alerta de una ausencia normal de respuestas humanas. El DNS puede verificarse de forma determinística; el interés del mercado no llega bajo calendario.

Relaciona incidentes con campañas y oportunidades abiertas. Si una ruta falló durante seis horas, identifica qué inboxes enviaron, qué follow-ups quedaron programados y qué conversaciones requieren revisión manual. La métrica técnica útil no es cuántas veces consultaste DNS, sino cuánto tiempo tardaste en detectar, contener y recuperar mensajes.

Un MX correcto parece una tarea básica. Precisamente por eso suele quedar fuera del QA después de la configuración inicial. Pero un sistema outbound depende de recibir bajas, objeciones, referencias e interés. Si el camino de regreso está roto, la automatización sigue enviando con una seguridad bastante ficticia.

picos.Ai trata DNS, buzón, sender y CRM como una sola cadena observable. Documentamos el estado esperado, probamos desde cuentas externas, verificamos stop conditions y dejamos alertas por dominio e inbox. No prometemos que un registro MX mejore la bandeja principal; prometemos no confundir recepción con autenticación ni un check verde con una conversación recuperable.

Si vas a mover dominios entre Google Workspace, Microsoft 365 u otro proveedor, usa el enlace Hablemos al final de esta página. Podemos inventariar la flota, preparar el cutover y probar cada reply antes de reactivar volumen. El mejor momento para descubrir un MX equivocado es con un mensaje controlado, no con la primera respuesta positiva de la semana.