Configurar Sophos Email Gateway con Exchange local

Con Exchange local, el flujo tiene dos rutas separadas: los mensajes entrantes llegan primero a los destinos MX regionales de Sophos y después se entregan a Exchange. Exchange envía los mensajes salientes mediante el smart host regional de Sophos. Configura y prueba ambas direcciones por separado.

Esta guía no se aplica a Microsoft 365 ni a la gestión automática de conectores de Sophos Mailflow. Un servidor Exchange local necesita conectores de recepción y envío propios; no reproduzcas conectores de Microsoft 365 para este fin.

Ruta rápida: registra la configuración actual y la reversión, configura el dominio en Sophos Fusion (antes Sophos Central) como Inbound and Outbound, restringe la recepción de Exchange a las IP regionales de entrega de Sophos, crea un Send Connector hacia el Outbound Relay Host copiado, rastrea ambas direcciones y solo entonces desactiva las rutas de filtrado antiguas.

Preparar los datos y la reversión

Antes de modificar nada, registra en el cambio:

el dominio de correo, por ejemplo example.org, y todos los destinatarios que se protegerán;
el destino Exchange accesible públicamente como FQDN o dirección IP, por ejemplo mail.example.org, y el puerto SMTP realmente utilizado;
las IP públicas de origen o redes CIDR usadas por Exchange al salir, por ejemplo la dirección de documentación reemplazable 192.0.2.25/32;
los destinos MX, las IP de entrega, el Outbound Relay Host y el dominio SPF regionales de Sophos desde las dependencias externas actuales del tenant;
los conectores de recepción y envío existentes, sus ámbitos y precedencia, y las reglas de firewall y NAT;
los valores MX y SPF actuales, incluidos los TTL.

Los valores de Sophos dependen de la región. Cópialos de tu propio tenant de Sophos Fusion y usa las listas actuales de IP de entrega de Gateway, registros MX, hosts de relay saliente y dominios SPF. El tenant también muestra el relay en Gateway Domains > dominio > Configure External Dependencies > Outbound Settings. Conserva los valores DNS y ajustes anteriores para revertir. Reduce el TTL DNS con antelación. Sophos indica que los cambios de conectores pueden tardar hasta 24 horas en propagarse; una prueba inmediata no demuestra la propagación completa.

Configurar el dominio y la ruta entrante

Preparar Sophos Gateway

En Sophos Fusion, ve a Global Settings > Products and Services > Email > Gateway Domains y añade o abre el dominio.
Introduce el dominio, la dirección del tráfico, el destino de entrega y su puerto SMTP. El flujo completo requiere Inbound and Outbound.
Selecciona Verify Domain Ownership, publica el valor TXT específico del dominio en la raíz DNS y selecciona Verify. Usa como nombre el mostrado o @.
Continúa solo cuando Sophos confirme la verificación. Un fallo suele indicar un valor TXT incorrecto o propagación DNS incompleta.
Añade o sincroniza los buzones que protegerá Sophos Email.

El destino de entrega es el endpoint Exchange accesible públicamente, no el nombre MX de Sophos. Su FQDN o IP y su puerto deben coincidir exactamente con el servicio SMTP publicado y el reenvío del firewall.

Restringir la recepción de Exchange

En el firewall y la ruta de recepción de Exchange, permite como orígenes de la ruta Sophos únicamente las IP regionales de entrega de Sophos. Obtén las direcciones exactas de las dependencias externas actuales del tenant. Omitir una puede impedir la entrega; añadir una red ajena o demasiado amplia debilita la protección frente al bypass.

En el Receive Connector de Exchange usado por Sophos, establece el enlace local en la IP local de Exchange y el puerto de escucha previstos; por separado, limita los rangos IP remotos únicamente a las IP regionales de entrega de Sophos y no uses 0.0.0.0/0. La recepción normal para destinatarios de dominios aceptados de Exchange es distinta del permiso de relay SMTP: no necesita relay general y este conector no debe recibirlo. Si varios Receive Connectors se solapan, determina antes del cambio cuál coincidirá con cada origen Sophos.

Primero comprueba que la ruta sea accesible sin retirar la protección anterior. Después sustituye en el proveedor DNS los registros MX por los destinos MX regionales de Sophos. Escritura, preferencia y región deben coincidir exactamente con los valores del tenant.

Configurar la ruta saliente mediante Sophos

Autorizar el origen saliente en Sophos

Abre el dominio en Gateway Domains y selecciona Edit.
En Configure Domain, confirma Inbound and Outbound.
En Outbound Gateway, selecciona Custom Gateway.
Añade al menos una IP pública o red CIDR desde la que Sophos verá realmente las conexiones salientes y guarda. Las IP privadas de Exchange tras NAT no son aquí el origen visible.
Abre Configure External Dependencies > Outbound Settings y copia el Outbound Relay Host regional.

Mantén los rangos de origen lo más estrechos posible. Un CIDR innecesariamente amplio puede autorizar sistemas ajenos; una IP NAT incorrecta provoca rechazos de relay.

Cambiar el Send Connector de Exchange

En Exchange crea un Send Connector SMTP para destinatarios de Internet, selecciona Route mail through smart hosts e introduce con Add el Outbound Relay Host copiado. Cada control tiene un fin distinto: los espacios de direcciones determinan los dominios destinatarios que se enrutan; los servidores de transporte de origen son los servidores Exchange que alojan el conector: los mensajes seleccionados para él se enrutan a uno de estos servidores, que establece la entrega al smart host; el coste desempata espacios coincidentes igual de específicos; y la opción de conector con ámbito limita su disponibilidad en la topología Exchange al sitio de Active Directory, no el enrutamiento de destinatarios. Sigue Microsoft para Exchange 2019, Exchange 2016 o Exchange 2013.

Durante la aceptación y el cambio, desactiva todo Send Connector de filtrado antiguo cuyos espacios de direcciones se solapen con los del conector Sophos, con independencia de su lista de servidores de origen; conserva su configuración documentada, no una ruta competidora activa, para revertir. Si un piloto debe mantener ambos activos, asígnales espacios de direcciones realmente no solapados. Las listas de servidores de origen separadas no distribuyen los mensajes según el servidor Exchange donde se originaron y no proporcionan un aislamiento seguro. No dependas solo del coste: Exchange evalúa primero la especificidad del espacio de direcciones. Tras validar, mantén desactivado o elimina el conector antiguo solapado.

Comprobar SPF, DKIM y ambas direcciones

Cuando Sophos entregue correo saliente, actualiza el único registro TXT SPF con el valor regional de la lista Sophos enlazada. Un reemplazo solo para Sophos tiene exactamente la forma v=spf1 include:<spf-domain> -all. En funcionamiento paralelo, conserva todos los mecanismos autorizados existentes e inserta include:<spf-domain> antes del único all final, por ejemplo v=spf1 include:old.example include:<spf-domain> -all. Sustituye <spf-domain> por el valor regional; nunca publiques el placeholder, un segundo all final ni otro registro SPF. Elige -all solo si tienes la certeza de que todos los remitentes reales están representados; en caso contrario usa ~all. La elección depende de la cobertura de remitentes, no de que Sophos sea la única ruta. Comprueba DKIM por separado.

Usa asuntos únicos para las pruebas y registra remitente, destinatario y hora:

Entrante: envía desde un dominio externo a un buzón protegido. En Sophos Fusion, el mensaje debe aparecer en Reports > Message History, después en el seguimiento de Exchange y en el buzón destino.
Saliente: envía desde un buzón protegido a un dominio externo. Establece la dirección de Message History en outbound, revisa la entrada y confirma la aceptación externa y el seguimiento de Exchange.
Bypass y relay: una entrega directa a Exchange desde un origen no autorizado y un intento de relay hacia un dominio ajeno no deben aceptarse por la ruta Sophos restringida.

Una entrada en un solo sistema no demuestra el éxito extremo a extremo. Correlaciona el seguimiento de Exchange, el historial Sophos y el resultado del destinatario mediante marcas de tiempo y Message-ID.

Solucionar problemas de forma metódica

El mensaje entrante no aparece en Sophos: comprueba destinos MX, preferencia, propagación DNS y región. Un MX antiguo puede seguir evitando el gateway.
Visible en Sophos, pero no en Exchange: comprueba destino y puerto, firewall/NAT, IP regionales de entrega Sophos, ámbito del Receive Connector y colas de Exchange. Descarta también un buzón ausente de Sophos.
El mensaje saliente queda en Exchange: comprueba resolución DNS y alcance del Outbound Relay Host, Send Connector elegido, servidores de origen y colas de Exchange.
Relay rechazado: identifica la IP pública de origen que ve Sophos y compárala con los valores IP/CIDR de Custom Gateway. No amplíes el rango indiscriminadamente.
Fallo TLS: comprueba nombres del smart host y destino, cadena, validez y coincidencia del certificado, y negociación TLS admitida por ambos lados. No desactives TLS permanentemente para ocultar el problema.
Algunos mensajes usan la ruta antigua o forman un bucle: comprueba solapamiento de espacios de Send Connectors, costes/precedencia y conectores de filtrado antiguos. MX antiguos o relays anteriores también pueden crear bucles.

Después de cada corrección, repite la prueba de la dirección afectada y compara nuevas marcas de tiempo. Si el flujo sigue ausente, recopila Message-ID, intervalo, estado del conector, error de cola y entrada coincidente de Sophos Message History para escalar.

Revertir de forma segura

Revierte solo la dirección que falla. Para incidencias entrantes, restaura los valores MX anteriores guardados y mantén activa la ruta de recepción anterior hasta que se propague DNS. Para incidencias salientes, primero restaura los mecanismos de remitente anteriores guardados integrándolos en el único registro SPF del dominio, conserva temporalmente include:<spf-domain> y ten en cuenta la propagación DNS según el plan de cambios. Después reactiva el Send Connector anterior conocido y desactiva inequívocamente el nuevo Sophos Send Connector para evitar rutas competidoras.

Retira los cambios de firewall y Receive Connector solo cuando la ruta de entrada restaurada funcione de forma demostrable. Elimina include:<spf-domain> del único registro SPF del dominio solo después de validar la ruta de salida restaurada, conservando los mecanismos de remitente restablecidos. Después vuelve a probar ambas direcciones, revisa las dos colas y documenta las cachés DNS restantes. Así una reversión parcial no se convierte en open relay ni en una segunda ruta de envío sin control.