Flujo de correo híbrido: enrutamiento entre Exchange Online y entorno local

El flujo de correo híbrido es la ruta SMTP entre una organización local de Exchange y Exchange Online. Permite que los buzones de ambos lados utilicen el mismo dominio SMTP y que los mensajes lleguen al lugar correcto. Para ello, Hybrid Configuration Wizard configura conectores y parámetros TLS (Transport routing in Exchange hybrid deployments, Hybrid Configuration Wizard).

El flujo de correo es solo una parte de Exchange Hybrid. La sincronización de directorios, libre/ocupado, OAuth y los movimientos de buzones utilizan otras rutas. Por ello, este artículo se limita deliberadamente a una única pregunta: ¿Qué saltos SMTP recorre un mensaje concreto y qué decisión se toma en cada salto?

La pila de protocolos es clara: DNS nombra los destinos accesibles públicamente, SMTP a través de TCP 25 transporta el mensaje, TLS protege e identifica la conexión, y los conectores de Exchange determinan qué extremo se utiliza para cada dominio. Los objetos de destinatario proporcionan la dirección de enrutamiento; Message Trace y los registros de seguimiento locales muestran posteriormente qué hizo cada organización con el mensaje (Transport routing in Exchange hybrid deployments, Hybrid deployment prerequisites).

El modelo básico: dos organizaciones de Exchange, un espacio de direcciones

Un entorno híbrido tiene al menos dos organizaciones de transporte. La organización local de Exchange conoce los buzones locales y los objetos de buzón remoto. Exchange Online conoce los buzones en la nube y las representaciones sincronizadas de destinatarios locales. Ambos lados pueden utilizar el mismo dominio principal, como example.com (Exchange hybrid deployments).

Para que un mensaje no termine en el lugar equivocado, cada lado necesita una indicación de la ubicación real del destinatario. Para un buzón en la nube, el objeto de buzón remoto local contiene una dirección de enrutamiento remoto en el dominio de coexistencia, normalmente tenant.mail.onmicrosoft.com. A la inversa, Exchange Online conoce los destinatarios locales sincronizados como objetos habilitados para correo (Enable-RemoteMailbox).

El flujo normal es sencillo:

1. La primera organización de Exchange acepta el mensaje.
2. Resuelve el destinatario en su directorio.
3. El objeto de destinatario indica si el buzón está localmente o en el otro lado.
4. El conector híbrido adecuado envía mediante SMTP/TLS a la otra organización.
5. Allí se vuelve a resolver el destinatario y se entrega el mensaje.

Los expertos comprueban además si las reglas de transporte modifican la ruta, si se ha intercalado una puerta de enlace y qué prioridad de dominio o conector explica el siguiente salto elegido.

La ruta estándar sin transporte centralizado de Internet

En el modelo descentralizado habitual, cada lado envía su propio correo de Internet. Un buzón local utiliza la organización de transporte local de Exchange para el correo saliente de Internet. Un buzón en la nube envía a través de Exchange Online Protection. Solo los mensajes entre buzones locales y en la nube pasan por los conectores híbridos (Transport routing in Exchange hybrid deployments).

El correo de Internet entrante sigue el MX publicado. Si el MX apunta a Exchange Online, EOP acepta primero el mensaje. Para un buzón en la nube, Exchange Online entrega localmente; para un destinatario local sincronizado, utiliza el conector saliente híbrido. Si, por el contrario, el MX apunta al entorno local o a una puerta de enlace anterior, la primera decisión de destinatario se toma allí.

Este modelo mantiene cortas las rutas de Internet, pero genera varias IP de salida y ubicaciones de filtrado posibles. SPF, DKIM, DMARC, las listas de permitidos y las reglas de socios deben tener en cuenta ambas rutas de salida. No es un error del modelo híbrido, sino una consecuencia de la entrega distribuida.

Clasificar conscientemente Centralized Mail Transport

Centralized Mail Transport, CMT, modifica exactamente esta ruta saliente. Los mensajes desde buzones de Exchange Online hacia Internet se envían primero a la organización local de Exchange. Solo allí salen de la organización. Esto permite que el lado local siga utilizando reglas de transporte centralizadas, dispositivos o IP de salida fijas (Transport routing in Exchange hybrid deployments).

La ventaja es un control común de salida. El coste son saltos y dependencias adicionales. Si falla el transporte local o su conexión a Internet, esto también afecta ahora al correo saliente de la nube. Cambian la latencia, la ubicación de la cola, la IP de salida y el lugar del último filtrado.

Para administradores avanzados, la decisión no es por tanto «activar o desactivar CMT», sino: ¿Qué política concreta requiere el salto local, qué capacidad debe soportar y cómo se enruta en caso de fallo? Los expertos documentan además la protección contra bucles, los requisitos TLS, la prioridad de conectores y la prueba de que cada mensaje previsto realmente sigue la ruta centralizada.

Con ello queda concluido el tema de CMT. La autenticación de clientes de Outlook o Hybrid Modern Authentication no pertenece aquí, porque no selecciona ningún salto SMTP.

Cómo reconocen los conectores al extremo remoto

Una vez elegida la ruta, cada lado debe poder confiar en el extremo remoto. Hybrid Configuration Wizard crea conectores de envío/recepción locales y conectores entrantes/salientes adecuados en Exchange Online. El transporte se realiza mediante SMTP en TCP 25 y utiliza TLS (Hybrid deployment prerequisites, Hybrid mail flow).

El conector de envío local determina el destino y los requisitos TLS para el dominio de coexistencia. El conector saliente de la nube describe la organización local como destino. En sentido contrario, el conector de recepción o entrante acepta el tráfico según condiciones documentadas, entre ellas la identidad del certificado y el origen.

El certificado cumple una función concreta: identifica el extremo SMTP durante el protocolo de enlace TLS. Subject o Subject Alternative Name, los parámetros del conector, la cadena de certificados presentada y el nombre de host real deben coincidir. No basta con que haya un certificado válido en el almacén de certificados si el servicio de transporte presenta otro.

Por ello, los expertos verifican ambos sentidos por separado. El sentido A puede funcionar mientras que el sentido B falla debido a otro conector, destino DNS o nombre de certificado.

Enrutamiento de destinatarios y dominios compartidos

Un conector funcional aún no indica qué mensajes lo utilizan. Esta decisión comienza con el objeto de destinatario. Un buzón remoto local apunta a la nube. Un objeto de buzón local sincronizado en Exchange Online apunta de vuelta a la organización local.

Los dominios aceptados también determinan si una organización es responsable de todos los destinatarios de un dominio o puede reenviar destinatarios desconocidos. En dominios compartidos, una configuración Internal Relay solo es segura si el siguiente salto conoce o rechaza correctamente a los destinatarios desconocidos (Accepted domains in Exchange Online, Accepted domains in Exchange Server).

Por tanto, un objeto de buzón remoto desactualizado puede provocar un enrutamiento incorrecto a pesar de que TLS esté en buen estado. A la inversa, una Target Address correcta no ayuda si el conector de nube está desactivado. El diagnóstico relaciona el objeto y el transporte, en lugar de considerar solo un lado.

Para los expertos, son importantes los reenvíos, los contactos de correo, la expansión de grupos de distribución y las reglas de transporte. Pueden modificar la dirección original del destinatario o generar destinatarios adicionales. Cada mensaje resultante recibe su propia decisión de enrutamiento.

Puertas de enlace de correo antes o después de Exchange Online

Muchas organizaciones complementan Hybrid con una Secure Email Gateway o una plataforma de filtrado en la nube. Esto añade al menos un salto SMTP adicional. La ruta debe dibujarse por separado para los mensajes entrantes y salientes (Manage mail flow using a third-party cloud service).

Si la puerta de enlace está antes de Exchange Online, el MX apunta a la puerta de enlace. Entonces EOP ve primero su IP de origen. Enhanced Filtering for Connectors puede incluir la información del remitente original en la evaluación de filtrado de Microsoft si el conector y las IP omitidas están correctamente configurados (Enhanced Filtering for Connectors).

Para la salida, debe estar claro si Exchange Online envía directamente, a través de la puerta de enlace o, con CMT, primero localmente y después a través de la puerta de enlace. Varias rutas permitidas pueden eludir políticas y generar firmas DKIM, IP de salida y registros diferentes.

El control experto consiste en un gráfico de rutas permitidas: cada flecha indica iniciador, destino, puerto, comprobación TLS, dominios permitidos, tarea de filtrado, propietario de la cola y fuente de registros. Un nombre de puerta de enlace sin estos datos aún no constituye una arquitectura.

Seguir un mensaje de extremo a extremo

La solución de problemas comienza con un mensaje de prueba cuyo remitente, destinatario y hora se conocen. Primero se comprueba la ruta pública y, después, los eventos de cada lado de Exchange implicado.

Resolve-DnsName -Type MX example.com
Test-NetConnection mail.example.com -Port 25

dig MX example.com
nc -vz mail.example.com 25

Resolve-DnsName y dig muestran el destino MX publicado. Test-NetConnection y nc comprueban si TCP 25 es accesible desde el punto de medición. Esto todavía no demuestra que la comprobación de TLS o del conector haya tenido éxito.

A continuación se realiza el protocolo de enlace SMTP. OpenSSL puede utilizarse en ambas plataformas de administración.

openssl s_client -starttls smtp -connect mail.example.com:25 `
  -servername mail.example.com -showcerts

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com -showcerts

openssl s_client muestra la cadena de certificados, los nombres y la negociación TLS. Para un diálogo de prueba completo y autorizado es adecuado swaks. Los mensajes de producción no se prueban con remitentes inventados libremente; la identidad de prueba y la ruta esperada se establecen de antemano.

En Exchange Online, Get-MessageTraceV2 proporciona los eventos de la nube. Localmente, Get-MessageTrackingLog muestra el procesamiento en servidores Exchange y Get-Queue muestra los siguientes saltos en espera. Las marcas de tiempo se llevan a una zona horaria común; Internet Message ID y Network Message ID ayudan a vincular los segmentos (Message Trace FAQ, Message tracking).

Patrones de error típicos sin cambios de tema

Un error TLS se trata primero como un problema de transporte: ¿Qué host se conectó, qué certificado presentó y qué condición de conector esperaba el extremo remoto? La sincronización de destinatarios solo es relevante si el mensaje se enruta incorrectamente después de haber sido aceptado correctamente.

En cambio, un NDR por destinatario desconocido lleva primero al objeto de destinatario y al tipo de dominio aceptado. Solo si el objeto es correcto se comprueba si la ruta elegida lo transporta al lado correcto.

Una cola en espera requiere el siguiente salto, la hora de reintento y LastError. El puerto abierto del host de destino solo ayuda como siguiente prueba. Un bucle se manifiesta mediante cabeceras Received repetidas, saltos o eventos de seguimiento y suele producirse cuando ambos lados reenvían mutuamente destinatarios desconocidos (RFC 5321: Trace information and loop detection).

Una conexión que funciona solo en un sentido no es una contradicción. Los sentidos opuestos utilizan emisores, conectores y comprobaciones de certificados diferentes. Se registran y prueban por separado.

Seguridad, operación y cambios

SMTP híbrido abre una ruta de transporte deliberadamente permitida. Esta ruta debe limitarse a sistemas de origen y destino, certificados y dominios documentados. Los relés abiertos, los rangos de IP excesivamente amplios o los conectores que clasifican cualquier mensaje como confiable contradicen este modelo.

Los cambios de certificados se planifican como cambios de enrutamiento. Antes de la expiración, se comprueban el certificado nuevo, la asignación de servicio, la cadena presentada y la expectativa del conector en ambos lados. Después se realizan mensajes de prueba en ambas direcciones y se dispone de un plan de reversión controlado.

Para la operación continua se supervisan, como mínimo, los conectores híbridos, la expiración de certificados, el crecimiento de las colas, los errores de Message Trace, los destinos DNS y el estado de las puertas de enlace. Con Centralized Mail Transport se añade la capacidad de la ruta de salida local.

Copia de seguridad y reconstrucción de la ruta de correo

Los mensajes SMTP permanecen durante una interrupción en las colas de los sistemas responsables respectivos. Una copia de seguridad de configuración no restaura estos mensajes en espera. Por ello, la configuración y el estado de transporte se consideran por separado.

La reconstrucción incluye los parámetros de conectores de ambos lados, dominios aceptados y remotos, reglas de transporte, entradas DNS públicas, certificados con claves privadas, configuración de la puerta de enlace y la selección de HCW. Los secretos se almacenan de forma protegida; las exportaciones legibles documentan la estructura y las dependencias.

Tras una reconstrucción, no se prueba solo un puerto. Un mensaje marcado recorre la ruta esperada en cada dirección. Message Trace, los registros de seguimiento locales, los registros de la puerta de enlace y el buzón de destino confirman cada salto. Solo esta aceptación de extremo a extremo demuestra que el enrutamiento y el filtrado vuelven a ser correctos.

Evolución técnica y trade-offs

Hybrid Configuration Wizard automatizó, a lo largo de varias generaciones de Exchange, la conexión con Exchange Online. El transporte siguió siendo SMTP/TLS, mientras los conectores de nube, los certificados compatibles y las opciones de enrutamiento continuaron evolucionando (Hybrid Configuration Wizard).

El transporte directo de Internet mantiene las rutas cortas y utiliza cada plataforma allí donde se encuentra el buzón. Centralized Mail Transport centraliza el control, pero hace que el correo en la nube dependa de la salida local. Una puerta de enlace de terceros añade filtrado o cifrado especializado, pero aumenta el número de saltos y fuentes de registros. La elección correcta se deriva de un requisito demostrable, no del deseo de que en el diagrama todo pase por la misma caja.

Fuentes

• Microsoft Learn – Transport routing in Exchange hybrid deployments
• Microsoft Learn – Exchange hybrid deployments
• Microsoft Learn – Hybrid Configuration Wizard
• Microsoft Learn – Hybrid deployment prerequisites
• Microsoft Learn – Hybrid mail flow
• Microsoft Learn – Enable-RemoteMailbox
• Microsoft Learn – Set up connectors to route mail
• Microsoft Learn – Connectors on Exchange servers
• Microsoft Learn – Accepted domains in Exchange Online
• Microsoft Learn – Accepted domains in Exchange Server
• Microsoft Learn – Manage mail flow using a third-party cloud service
• Microsoft Learn – Enhanced Filtering for Connectors
• Microsoft Learn – Trace an email message
• Microsoft Learn – Message Trace FAQ
• Microsoft Learn – Message tracking
• Microsoft Learn – Queues in Exchange Server
• Microsoft Learn – Get-MessageTraceV2
• Microsoft Learn – Get-MessageTrackingLog
• Microsoft Learn – Get-Queue
• Microsoft Learn – Resolve-DnsName
• BIND 9 – dig manual
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc(1)
• OpenSSL – s_client
• Swaks – SMTP test tool
• RFC 5321 – Trace information and loop detection