La decisión: conservar el buzón, cambiar el MX
Cambiar de correo y cambiar de protección son dos proyectos distintos. El primero traslada los buzones, el historial, las agendas y las cuentas de los teléfonos. El segundo solo afecta al recorrido del correo entrante.
Ese recorrido cabe en un registro DNS: el MX, que indica a los servidores remitentes dónde entregar el correo de su dominio. Cuando designa la pasarela, esta recibe, analiza y después entrega el mensaje al servidor de buzones. Esto es válido para:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange instalado en sus oficinas o alojado;
- cualquier otro servidor de correo que reciba por SMTP;
- Klytic Mail, que es solo un caso entre otros, no un requisito previo.
Esta guía trata el caso en que se conserva el buzón. Si también cambia de servidor, las guías migrar desde Microsoft 365 y migrar desde Google Workspace describen ese otro proyecto.
Quién modifica qué
| Ajuste | Dónde | Quién |
|---|
| Registro MX del dominio | Zona DNS, en el registrador o el proveedor de DNS | La persona que gestiona el DNS, o el proveedor que tiene delegada esa gestión |
| Declaración de la pasarela en el correo | Consola de administración de Microsoft 365, de Google Workspace o del servidor | El administrador del correo |
| SPF, DKIM y DMARC | Zona DNS | El gestor del DNS, tras inventariar los servidores que envían en nombre del dominio |
| Dominios y servidor de entrega | Pasarela | El proveedor de la pasarela, que prepara la configuración |
El principio en Microsoft 365
La documentación de Microsoft sobre el filtrado por un servicio de terceros es clara: el MX del dominio debe designar ese servicio, que después entrega a Exchange Online. Microsoft recomienda un conector de entrada de tipo «partner», que puede rechazar el correo que llega sin pasar por el servicio. También recomienda activar el filtrado mejorado para conectores, para que su propio análisis evalúe al remitente real y no la dirección de la pasarela. Desaconseja limitarse a omitir su filtrado para las direcciones del servicio de terceros.
El principio en Google Workspace
Google describe una «pasarela de correo entrante»: el MX designa la pasarela y después el administrador declara sus direcciones IP en la consola. Gmail las utiliza para encontrar la dirección real del remitente en los encabezados, de la que dependen SPF y su evaluación del spam. También se puede rechazar el correo que no procede de la pasarela. Google precisa que no aplica la política DMARC del remitente al correo recibido a través de una pasarela declarada: ese control corresponde entonces a la pasarela.
Esta guía no reproduce las pantallas de estas consolas, que cambian. Siga la página oficial citada al pie en el momento de hacer el ajuste.
Varios servidores detrás de una sola pasarela
Caso frecuente en un grupo: la sociedad matriz en Microsoft 365, una filial en Google Workspace y una tercera en un servidor heredado. Una sola pasarela puede situarse delante de las tres.
El principio es un enrutamiento por dominio. El MX de cada dominio apunta a la pasarela. Para cada dominio, la pasarela conoce el servidor al que debe entregar el correo tras el análisis. El análisis es común; el destino cambia.
Ventaja: una misma política de filtrado, o configuraciones distintas según el dominio, y la lectura de todas las decisiones en un mismo lugar. Punto que preparar: un dominio cuyos buzones estuvieran repartidos entre dos servidores exige saber, dirección por dirección, dónde entregar. Este caso se estudia antes del cambio.
Lo que cambia y lo que no cambia
No cambia: las direcciones, los buzones, el historial, el programa de correo, el webmail, los teléfonos. El filtro integrado del correo sigue funcionando. Los permisos y los recursos compartidos internos siguen siendo los de la plataforma.
Cambia:
- El primer servidor que recibe el correo. Es él quien ve la conexión de origen y comprueba la autenticación del remitente.
- El servidor de buzones ya no ve directamente al remitente, sino la pasarela. De ahí la declaración descrita más arriba.
- Los mensajes llevan los encabezados de decisión de la pasarela: un administrador puede leer en ellos por qué un mensaje se ha entregado o se ha apartado.
- Si la pasarela también retransmite el correo saliente, el registro SPF del dominio debe autorizarla y la firma DKIM debe publicarse para ella. El sentido de estos mecanismos se explica en SPF, DKIM y DMARC.
El día en que también cambie de servidor de buzones, la pasarela puede mantenerse: solo cambia su servidor de entrega. La guía migrar un correo sin interrupción sigue siendo la referencia para ese día, también para SPF, DKIM y DMARC.
La puesta en marcha, por orden
- Inventario: dominios, servidor de buzones de cada uno, aplicaciones que envían correo en nombre del dominio.
- Preparación de la pasarela por su proveedor: dominios aceptados, servidor de entrega, reglas iniciales.
- Declaración de la pasarela en el correo (conector de entrada o pasarela de entrada), si la plataforma lo prevé.
- Reducción previa del TTL del MX y después modificación del MX. Durante el tiempo de caché del DNS, una parte de los remitentes sigue entregando directamente al servidor de buzones: es normal.
- Control: un mensaje enviado desde una dirección externa debe llegar con los encabezados de decisión de la pasarela.
- Supervisión de la cuarentena los primeros días, para liberar los falsos positivos y ajustar las reglas.
La vuelta atrás es sencilla: restablecer el MX anterior. Se prepara como en una migración, con una persona autorizada para decidirla.
Lo que la pasarela no hace
Ve el correo que la atraviesa, y solo ese. No ve los mensajes intercambiados entre dos buzones de una misma plataforma que no salen de ella, ni los archivos compartidos en un espacio de almacenamiento en línea, ni los inicios de sesión de los usuarios.
Por tanto, no sustituye a los ajustes internos de Microsoft 365 o de Google Workspace: permisos, doble autenticación, alertas de inicio de sesión, reglas de reenvío automático. Una cuenta robada sigue siendo ante todo un asunto del correo. La guía spam, phishing, malware y cuenta comprometida deslinda cada caso.
Por último, un remitente que conozca la dirección técnica del servidor de buzones puede intentar entregarle directamente, sin pasar por el MX. Esa es la razón del bloqueo que proponen Microsoft (conector partner) y Google (rechazo del correo que no pasa por la pasarela).
Preguntas frecuentes
¿Hay que avisar a los usuarios?
Sus direcciones no cambian. En cambio, avíseles de que podrán recibir avisos de cuarentena: véase Cuarentena, falsos positivos y notificaciones.
¿Hay que desactivar el filtro de Microsoft 365 o de Google?
No. Microsoft recomienda mantener su análisis activo y configurarlo para que vea al remitente real, en lugar de omitirlo.
¿Cuánto tiempo lleva el cambio?
El cambio de MX en sí surte efecto al ritmo de la caché del DNS. La preparación depende del número de dominios y de servidores. Para Klytic MTA, véase la sección siguiente.
¿Cambia una pasarela situada delante la entregabilidad de nuestros envíos?
Solo si también retransmite el correo saliente. En ese caso, SPF y DKIM deben tenerla en cuenta: véase SPF, DKIM y DMARC.
¿Por qué no cambiar simplemente de correo?
Es otra decisión, con otros criterios. Se trata en elegir un correo profesional europeo.
Dónde se sitúa Klytic
Klytic MTA se sitúa delante del correo que usted tiene: Microsoft 365, Google Workspace, Exchange, Klytic Mail o cualquier otro servidor. No requiere un buzón de Klytic.
- Puesta en servicio: generalmente de 24 a 48 horas. Klytic prepara la configuración; usted modifica el registro MX de su dominio, o Klytic lo hace por usted. La declaración de la pasarela en la consola de Microsoft 365 o de Google Workspace la realiza el administrador de ese correo, y se prepara con Klytic durante la puesta en servicio.
- Despliegue: nube de Klytic, instancia dedicada o servidores del cliente. Para necesidades particulares, se pueden diseñar otras arquitecturas con Klytic, por ejemplo un filtrado en la nube y un relé instalado en sus oficinas, o varias regiones.
- Ofertas: Esencial y Avanzado. La oferta Esencial cubre la autenticación, el antispam, el antivirus, el phishing, los dominios similares, la cuarentena, la firma DKIM de los envíos y la recuperación antes del envío. La oferta Avanzado añade el fraude financiero, la protección en el clic, la consola DMARC y la exportación de los registros a un SIEM.
- Prueba: 30 días gratuitos, sin cambiar de correo.
Klytic MTA no gestiona los permisos ni las cuentas de su correo actual, ni promete equivalencia con las herramientas de seguridad integradas en Microsoft 365 o en Google Workspace: se añade delante de ellas.
Esta página describe un principio. Las consolas de Microsoft y de Google evolucionan: su documentación oficial es la que prevalece para el procedimiento.
Fuentes
Consultadas en octubre de 2026.
- Microsoft Learn, «Manage mail flow using a third-party cloud service with Exchange Online» (Administrar el flujo de correo con un servicio en la nube de terceros con Exchange Online): el MX debe designar el servicio de terceros; conector de entrada de tipo partner; filtrado mejorado para conectores en lugar de omitir el filtrado. learn.microsoft.com
- Ayuda de Google Workspace, «Set up an inbound mail gateway» (Configurar una pasarela de correo entrante): MX hacia la pasarela, declaración de sus direcciones IP, posible rechazo del correo que no pasa por la pasarela; Gmail no aplica la política DMARC del remitente al correo recibido a través de la pasarela. knowledge.workspace.google.com
- RFC 5321, SMTP: los hosts intermedios suelen designarse mediante el registro MX del DNS. rfc-editor.org
- Klytic, página Klytic MTA: módulos de las ofertas Esencial y Avanzado, opciones, modos de despliegue, puesta en servicio mediante el MX. klytic.com
