Un dominio, dos correos: split delivery sin falsas promesas

Una empresa lleva años trabajando con Google Workspace. Gmail es conocido, las cuentas están ordenadas y trasladar toda la organización aportaría poco valor al negocio. En algún momento aparece, sin embargo, un equipo que necesita realmente Exchange Online: una empresa adquirida ya utiliza Microsoft 365, un departamento depende de una aplicación que exige un buzón de Exchange o una unidad independiente necesita integrarse estrechamente con Outlook y Teams.

La primera idea parece sencilla: mantener el dominio en Google y reenviar a Microsoft los mensajes de ese equipo. Es técnicamente posible y una solución bien diseñada puede funcionar durante años. Sin embargo, entre «el mensaje ha llegado» y «tenemos un correo fiable» existen varias capas importantes: routing en ambos sentidos, prevención de bucles, autenticación del remitente, filtrado de spam, alias, monitorización y responsabilidad ante incidentes.

Este modelo se llama split delivery. Conviene entenderlo antes de convertirlo en una pieza permanente de la infraestructura de la empresa.

Qué se divide exactamente

Con split delivery, un único dominio de correo —por ejemplo, empresa.es— tiene usuarios en dos sistemas. Algunos buzones se encuentran en Google Workspace y otros en Exchange Online. Para clientes y colaboradores, todos siguen utilizando direcciones del mismo dominio corporativo.

Esto no significa que cada mensaje llegue a dos buzones. Eso sería dual delivery. Tampoco hablamos de una regla de reenvío creada por un usuario. Split delivery funciona en la capa de transporte: el sistema reconoce al destinatario y elige el servidor responsable de su buzón.

La diferencia importa. En un diseño correcto, cada persona tiene un solo buzón como fuente de verdad. El historial, las respuestas, las reglas, la retención y las búsquedas no quedan repartidos entre Gmail y Outlook.

Google documenta split delivery como un escenario compatible para organizaciones donde parte de los usuarios trabaja en Gmail y otra parte en un sistema distinto. La condición es razonable: cada destinatario debe tener buzón en un sistema, no en los dos. Los detalles aparecen en la documentación de Google Workspace.

El recorrido de un mensaje

El modelo más claro tiene un único punto de entrada principal. El registro MX del dominio continúa apuntando a Google Workspace. Cada mensaje procedente de internet llega primero a Google, pasa los controles iniciales y después se entrega en Gmail o se dirige a Exchange Online.

El esquema contiene dos recorridos que deben estar previstos:

1. Google dirige a Exchange Online el correo del grupo de destinatarios seleccionado.
2. Microsoft devuelve a Google, mediante un connector, los mensajes destinados al resto de usuarios del dominio.

El segundo recorrido se olvida con frecuencia. Exchange debe saber que no posee todos los buzones del dominio. En este modelo el dominio se configura en Microsoft 365 como Internal Relay, y los mensajes para destinatarios que no existen localmente viajan a Google a través de un connector controlado. Microsoft describe estos mecanismos en su escenario de convivencia para un grupo reducido.

Sin esa ruta de retorno, el correo de internet puede parecer completamente sano mientras un mensaje enviado desde Outlook a un compañero que usa Gmail termina en un aviso de no entrega. Es el ejemplo clásico de una configuración que «superó las pruebas» porque solo se comprobó una dirección.

Cuándo tiene sentido este modelo

Split delivery funciona bien cuando la división responde a una necesidad real y no a una preferencia temporal por una interfaz.

Adquisición o fusión de empresas

Una organización utiliza Google Workspace y la otra Microsoft 365. Migrar de inmediato todos los buzones aumenta el riesgo y consume la atención del equipo durante un periodo de integración que ya es exigente. Un dominio compartido y un routing controlado permiten ordenar cuentas, datos y procesos por etapas.

Una unidad que trabaja en el ecosistema Microsoft

Un departamento independiente puede necesitar funciones de Exchange Online, integración con software sectorial, calendarios avanzados o políticas disponibles en el entorno Microsoft. El resto de la organización no tiene por qué abandonar Gmail como consecuencia.

Una migración por fases

Trasladar a todos los usuarios en una sola noche no siempre es sensato. Split delivery permite migrar grupos, observar el resultado y mejorar el proceso antes de la siguiente fase. En este caso conviene fijar desde el principio la fecha final de la convivencia. Los diseños provisionales tienden a hacerse permanentes por accidente.

Requisitos contractuales u organizativos

Un proyecto, un socio o una unidad regulada puede exigir un entorno determinado. Dividir el correo permite aislar esa parte sin reconstruir toda la empresa, siempre que la retención, la auditoría y la protección de datos se hayan diseñado conscientemente.

Si el único requisito es utilizar la aplicación Outlook, la respuesta es distinta. Outlook puede trabajar con una cuenta de Google, por lo que abrir una segunda plataforma de correo puede ser innecesario. Microsoft describe cómo añadir Gmail a Outlook como una función normal del cliente.

«He enviado una prueba desde mi cuenta personal» no es suficiente

El correo corporativo recorre varios caminos. Un mensaje desde una dirección externa hacia un usuario de Exchange puede llegar correctamente mientras la comunicación entre personas del mismo dominio está rota.

Antes de ponerlo en producción hay que comprobar, como mínimo:

1. internet → buzón Google,
2. internet → buzón Microsoft,
3. Google → Microsoft dentro del mismo dominio,
4. Microsoft → Google dentro del mismo dominio,
5. Google y Microsoft → destinatarios externos,
6. respuestas que vuelven a ambos entornos.

Los alias, grupos, copias ocultas, respuestas automáticas, mensajes enviados por aplicaciones corporativas, invitaciones de calendario y archivos sujetos a políticas de seguridad también forman parte del plan de pruebas. Una prueba correcta confirma algo más que la presencia del mensaje en la bandeja. Revisamos las cabeceras, los resultados SPF, DKIM y DMARC, el connector utilizado, el tiempo de entrega y si el mensaje pasó por el filtro previsto.

El descuido más habitual: el tráfico interno

Google diferencia el correo que llega de internet de los mensajes enviados dentro de la organización. Una regla que cubre solo el tráfico entrante puede entregar correctamente los mensajes de los clientes y fallar cuando una persona de Gmail escribe a una compañera en Exchange Online.

Microsoft presenta el problema inverso. Si el dominio se marca como autoritativo, Exchange supone que conoce a todos sus destinatarios. Una dirección que solo existe en Google puede tratarse entonces como inválida. Internal Relay y un connector de retorno resuelven el problema, siempre que las reglas no capturen los buzones locales de Microsoft.

Por eso split delivery no se diseña como un único reenvío. Es un circuito cerrado en el que ambos sistemas deben saber cuándo entregar localmente y cuándo pasar el mensaje al siguiente sistema.

Un bucle entre dos nubes

Cuando Google necesita enviar un mensaje a Microsoft, no puede consultar simplemente el MX público del dominio. Ese MX vuelve a apuntar a Google, de modo que el mensaje regresaría al punto de partida.

La ruta debe conducir a un endpoint concreto de Exchange Online asignado al tenant o a una dirección técnica controlada. En sentido contrario, el connector de Microsoft debe enviar a Google únicamente los destinatarios que no existen localmente en Exchange.

Antes del lanzamiento conviene definir límites de saltos, añadir cabeceras de diagnóstico útiles y alertar ante crecimientos anómalos del volumen de mensajes. Un bucle de correo no siempre produce una caída espectacular. Puede manifestarse como retrasos, respuestas automáticas repetidas o una cola que crece en silencio.

Una persona, un buzón

Mantener activos Gmail y Exchange para la misma persona puede parecer más seguro: al menos habrá dos copias. En el trabajo diario aparecen pronto dos historiales, estados de lectura distintos, reglas incoherentes, dos respuestas de ausencia y dudas sobre qué sistema envió una contestación.

La cuenta de Google puede seguir siendo necesaria para Drive, documentos o inicio de sesión. Eso no obliga a que continúe almacenando el correo. La propiedad del buzón debe ser inequívoca y el directorio de usuarios, alias y grupos tiene que reflejar la división.

La misma regla se aplica al archivo. Dos copias en dos bandejas no sustituyen una política de retención ni un backup. Durante una auditoría o un incidente, la empresa debe saber dónde se conserva el historial completo y quién puede protegerlo.

SPF, DKIM y DMARC con dos remitentes

Con split delivery, Google y Microsoft pueden enviar mensajes usando el mismo dominio. Un destinatario externo necesita verificar que ambos orígenes son legítimos.

El dominio debe publicar un único registro SPF que incluya los dos sistemas, por ejemplo:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Google incluye exactamente esta combinación en su guía de configuración SPF. No se deben crear dos registros SPF separados, porque el resultado es un error de validación.

DKIM se activa por separado en cada proveedor. Google firma el correo con su selector y Exchange Online utiliza los selectores de Microsoft. DMARC sigue siendo una política común para el dominio. Sus informes resultan especialmente útiles después del lanzamiento: muestran si ambos entornos autentican correctamente y si ha aparecido alguna fuente de envío desconocida.

Es mejor endurecer la política por fases. Primero recogemos informes y comprobamos el alignment; después pasamos de p=none hacia cuarentena o rechazo. DKIM puede configurarse con las instrucciones oficiales de Google Workspace y Microsoft 365.

Dos filtros de seguridad y una posible vía alternativa

Un mensaje destinado a Exchange puede pasar primero por la protección de Gmail y después por Exchange Online Protection. Dos capas resultan tranquilizadoras, pero pueden clasificar de manera distinta el phishing, los adjuntos y los enlaces. El administrador necesita saber qué plataforma detuvo el mensaje y dónde investigarlo.

Existe otro riesgo menos evidente. El endpoint público de protección de Exchange Online continúa accesible aunque el MX del dominio apunte a Google. Un remitente puede intentar entregar directamente a Microsoft y evitar el primer filtro. La ruta Google → Microsoft debería usar por ello un connector dedicado, exigir TLS y aplicar condiciones que identifiquen el origen de confianza. Los connectors de Microsoft pueden limitarse mediante certificado, dominio o rangos IP, como explica su documentación de flujo seguro.

Dónde puede desaparecer realmente un mensaje

Entre el remitente y el buzón no existe un único punto mágico llamado «correo». El recorrido es una cadena de servicios, y cada uno puede retrasar, rechazar o reclasificar el mensaje.

Los puntos débiles habituales incluyen:

• un MX desactualizado o un destino de ruta incorrecto,
• una dirección ausente de la regla de destinatarios,
• un certificado que no cumple las condiciones del connector,
• un mensaje retenido por el segundo filtro antispam,
• un alias o grupo presente en un solo directorio,
• una regla de transporte que crea un bucle,
• un buzón sin licencia o con el límite superado,
• ninguna persona responsable de la alerta de cola.

La fiabilidad nace de la visibilidad. El modelo operativo necesita logs de ambos proveedores, Message Trace en Microsoft 365, Email Log Search en Google, informes DMARC y mensajes sintéticos enviados periódicamente por las rutas críticas. Una alerta sin responsable aporta poco valor; cada recorrido fallido debe tener un procedimiento de respuesta definido.

¿Es un servicio de correo de respaldo en otro proveedor?

No. Cuando el MX apunta a Google, Google continúa siendo el primer punto de entrada para todo el dominio. Una caída o una regla incorrecta de Google puede afectar también a los destinatarios de Exchange Online.

SMTP pone mensajes en cola y reintenta después de una indisponibilidad temporal del siguiente servidor. Esto reduce el impacto de incidencias breves, pero no es una estrategia de continuidad. Microsoft indica que los mensajes que un connector no puede entregar se reintentan durante un periodo limitado, actualmente hasta 24 horas. Después, el remitente puede recibir un aviso de no entrega.

Añadir un MX secundario de menor prioridad no lo arregla automáticamente. El servidor alternativo tendría que gestionar de forma segura a todos los destinatarios y dirigirlos a la plataforma correcta. Sin un diseño completo, un supuesto «MX de respaldo» crea una nueva forma de evitar filtros y otra oportunidad para los bucles.

Calendarios, grupos y procesos también forman parte del diseño

El correo puede funcionar perfectamente y los usuarios seguir percibiendo la división. La disponibilidad free/busy entre plataformas, la reserva de salas, la delegación de buzones, los grupos de distribución, los contactos corporativos y las invitaciones de calendario no siempre cruzan la frontera con la misma naturalidad que un correo normal.

En su guía para un piloto reducido, Microsoft señala que la información free/busy no está disponible automáticamente para usuarios del otro sistema. Una arquitectura permanente necesita por tanto una decisión clara sobre las funciones de colaboración, la propiedad del directorio y la sincronización de cambios de personal.

La baja de una persona también afecta a los dos entornos. Eliminar una cuenta en un panel puede dejar un alias, una regla de routing o acceso activo en el otro. El proceso de salida debe cerrar buzón, licencia, grupos, delegaciones y reglas de transporte como una sola tarea controlada.

«Para siempre» significa mantenimiento continuo

Split delivery puede ser una arquitectura definitiva, pero no una configuración sin responsable. Los proveedores cambian sus interfaces, los certificados se renuevan, los equipos aparecen y desaparecen, y nuevas aplicaciones empiezan a enviar correo desde el dominio corporativo.

Un modelo mínimo de mantenimiento incluye:

• una lista actualizada de buzones y de los sistemas que los gestionan,
• revisión de reglas de routing y connectors después de cambios importantes,
• pruebas automáticas de las direcciones críticas,
• monitorización de colas, retrasos y volumen de rechazos,
• seguimiento de SPF, DKIM e informes DMARC,
• un procedimiento de fallo probado,
• responsables identificados en ambos lados de la integración.

Así el servicio deja de depender de la persona que recuerda «dónde se configuró aquel reenvío». Se convierte en un sistema normal y observable.

Cuándo es mejor elegir una sola plataforma

La división no siempre compensa su coste. Si el requisito es únicamente una aplicación de escritorio preferida, conectar Google con Outlook es más sencillo. Si la mayoría de los procesos de la empresa se trasladan a Teams y Exchange, una migración completa a Microsoft 365 puede resultar más barata a largo plazo. Del mismo modo, una organización centrada en Google Meet, Drive y Gmail puede concluir que mantener una isla de Exchange aporta poco valor.

Antes de decidir conviene responder a cinco preguntas:

1. ¿El grupo separado necesita funciones de servidor de Exchange o solo el cliente Outlook?
2. ¿La convivencia tiene fecha final o es la arquitectura definitiva?
3. ¿Quién es responsable del routing, la autenticación y la monitorización?
4. ¿Cómo deben funcionar calendarios, grupos, retención y respuesta a incidentes?
5. ¿Cuánto cuesta la complejidad adicional frente a una migración?

Con respuestas concretas, split delivery puede resolver una necesidad real sin transformar toda la organización. Si las respuestas son «ya lo veremos», la división probablemente se convertirá en una deuda operativa difícil de diagnosticar.

Dos nubes pueden colaborar, pero necesitan un solo diseño

Google Workspace y Microsoft 365 pueden atender simultáneamente el mismo dominio de correo. La clave es tratarlo como una integración entre dos sistemas críticos: un propietario de buzón por usuario, rutas en ambos sentidos, connectors protegidos, SPF/DKIM/DMARC correctos y monitorización de todo el recorrido.

El mejor split delivery es invisible para los usuarios. Los mensajes llegan, las respuestas vuelven y el equipo de IT puede averiguar rápidamente qué ocurrió por el camino. Ese resultado nace del diseño y el mantenimiento, no de una única regla de reenvío.

Si estás valorando la convivencia de Google Workspace y Microsoft 365, o necesitas ordenar una división que ya funciona, nuestro servicio de Socio IT puede revisar el flujo de correo, la seguridad del dominio y los procedimientos operativos, y diseñar después un modelo adaptado a los procesos reales de la organización.