Configurar Sophos Firewall MTA con Microsoft 365
Sophos Firewall puede funcionar en MTA mode como gateway de correo independiente delante de Microsoft 365. Los mensajes entrantes llegan primero al firewall y se entregan después a Exchange Online Protection. Exchange Online devuelve los mensajes salientes al firewall mediante un conector para que los analice y los reenvíe a Internet.
Este diseño es posible, pero no es automáticamente la mejor arquitectura. Sophos Central Email, Microsoft Defender for Office 365 y Mail Protection en el propio dispositivo se solapan parcialmente. Antes del cambio debe definirse qué sistema se responsabiliza de spam, malware, cuarentena, TLS, DKIM y diagnóstico.
⚠️ Una autorización de relay demasiado amplia puede convertir el firewall en un open relay. Antes de cambiar el registro MX se mantienen disponibles una sesión de administrador local, el flujo actual y una vía de recuperación probada. La transición productiva solo se realiza cuando una prueba de relay no autorizado se rechaza de forma fiable.
Dibujar primero el flujo de correo bidireccional
La ruta entrante es Internet → Sophos Firewall MTA → Exchange Online Protection → buzón de Microsoft 365. El registro MX público apunta a la dirección SMTP pública del firewall. A continuación, la política SMTP route and scan entrega al destino específico del tenant, por ejemplo example-com.mail.protection.outlook.com.
La ruta saliente es Exchange Online → conector de Microsoft 365 → Sophos Firewall MTA → Internet. El firewall solo debe aceptar relay desde las redes actuales de Exchange Online Protection. HELO, certificado, IP de origen pública, PTR/rDNS, SPF, DKIM y DMARC deben corresponder a esta ruta.
Configurar Mail Protection en MTA mode explica los fundamentos de MTA, los campos de política, la cuarentena y los logs. Este artículo se centra en la conexión con Microsoft 365.
Valores de ejemplo y requisitos
El ejemplo utiliza el dominio example.com, el FQDN del firewall mail.example.com, la dirección de documentación 192.0.2.25 y el destino del tenant example-com.mail.protection.outlook.com. Se sustituyen por el dominio real, una dirección pública fija y el destino Microsoft correcto. 192.0.2.25 pertenece a TEST-NET y no se utiliza en producción.
TCP 25 debe funcionar desde Internet al firewall, desde el firewall a Microsoft 365 y desde el firewall a servidores de correo externos. También se necesitan una licencia Email Protection adecuada, compatibilidad MTA del modelo, un certificado de confianza pública, acceso DNS controlado y permisos para Exchange Admin Center y el DNS autoritativo.
Las redes de Exchange Online Protection cambian. No se copian de un ejemplo estático, sino que se mantienen a partir de la lista de endpoints de Microsoft 365 actual enlazada por Sophos. Para este flujo son especialmente relevantes los endpoints SMTP en TCP 25. Se documentan el responsable y el intervalo de revisión de los objetos host.
Conectar Microsoft 365 y SFOS en ocho pasos
- Registrar el MX, SPF, conectores, headers, IP de origen pública y vía de recuperación actuales.
- Preparar MTA mode, la regla MTA automática, el certificado y el análisis saliente en SFOS.
- Crear objetos IP host separados para los rangos EOP actuales.
- Permitir
SMTP RelaydesdeWAN, limitar Host-based relay a los objetos EOP y bloquear las demás fuentes. - Crear una política SMTP route and scan para el dominio protegido y el destino Microsoft del tenant.
- Crear en Exchange Online un conector de Microsoft 365 hacia la dirección pública del firewall.
- Cambiar MX y SPF durante una ventana de mantenimiento.
- Validar tráfico entrante, saliente y relay rechazado mediante headers, Mail logs, spool y trazas de Microsoft.
Preparar Sophos Firewall
MTA mode, regla automática y certificado
En Email > General settings se activa MTA mode. SFOS crea Auto added firewall policy for MTA para SMTP y SMTPS. La regla no se modifica y permanece arriba, tal como recomienda Sophos. Si falta con MTA mode activo, no se crea una sustitución Any-to-Any; primero se comprueban el modo, la configuración y la vía de soporte.
En SMTP settings, SMTP hostname recibe el nombre de dominio previsto. En SMTP TLS configuration se selecciona un certificado de confianza pública y Allow invalid certificate permanece desactivado. Scan outgoing mails debe estar activo si también se analizarán los mensajes procedentes de Exchange Online.
Permitir el relay desde fuentes EOP
En Hosts and services > IP host se crea un objeto con nombre comprensible para cada rango IPv4 EOP actual, por ejemplo con el prefijo O365_EOP_. Los rangos no se agrupan en una red mayor. Cuando Microsoft modifique la lista, las redes se añaden o eliminan mediante un cambio controlado y se vuelven a probar.
En Administration > Device access se activa SMTP Relay para WAN. Como el selector de zona por sí solo es demasiado amplio, se restringe en Email > Relay settings > Host-based relay:
- Allow relay from hosts/networks: solo los objetos EOP mantenidos;
- Block relay from hosts/networks: Any.
Sophos evalúa una coincidencia Allow antes del Block solapado. Por ello, la lista Allow no debe contener redes amplias de proveedores, cloud ni Any. Upstream host controla una relación de destino distinta y no sustituye esta comprobación de origen.
Para el correo entrante normal desde Internet, el procedimiento de Sophos configura Upstream host > Allow relay from hosts/networks como Any. Esto permite a hosts SMTP externos entregar a los dominios protegidos; no es la misma autorización que el Host-based relay saliente. Si ya existe un gateway externo definido delante de SFOS, la lista Upstream se limita a sus redes de origen reales.
Política route and scan para la entrega a Microsoft
En Email > Address group se crea el dominio protegido como Email address/domain. Después se añade en Email > Policies and exceptions > Add a policy > SMTP route and scan una política con:
- el grupo de direcciones en Protected domain;
- Global action: Accept;
- Route by: DNS host y el destino Microsoft específico del tenant;
- opciones de protección contra spam, malware, archivos y datos elegidas conscientemente.
El host de routing no es el MX público de example.com una vez que este apunta al firewall. De lo contrario, el firewall se entrega a sí mismo y crea un bucle. El destino Microsoft real se registra antes de cambiar el MX y se comprueba que SFOS lo resuelva correctamente.
Crear el conector de Exchange Online
En Exchange Admin Center se crea en Mail flow > Connectors un conector From: Office 365 y To: Partner organization. Para enviar todo el correo saliente a través de SFOS, su condición de destino se aplica a todos los dominios destinatarios (*). Un subconjunto limitado debe corresponder al diseño documentado. Como smarthost se utiliza la IP pública o el FQDN mail.example.com del firewall.
Se exige TLS para el conector. La ayuda de Sophos muestra también una opción compatible que acepta cualquier certificado digital, incluidos certificados autofirmados. Para producción es más robusto un certificado de confianza pública cuya identidad coincida con el FQDN y que se valide con una prueba real del conector.
La validación del conector puede fallar antes del cambio DNS. Por tanto, no sustituye la posterior prueba de extremo a extremo ni la prueba negativa de relay. Después de guardar, Microsoft Message Trace debe confirmar que los mensajes salientes utilizan realmente el conector y el firewall previstos.
Cambiar MX y SPF de forma controlada
El MX público solo apunta a mail.example.com cuando están listos la política del firewall, el relay EOP, el destino interno de Microsoft y el conector. La TTL se reduce antes de la ventana de mantenimiento. El antiguo destino MX permanece disponible para el rollback documentado, pero no en paralelo si los remitentes pudieran evitar aleatoriamente el nuevo control.
El registro SPF debe autorizar Exchange Online y la identidad remitente pública del firewall. Sophos muestra v=spf1 include:spf.protection.outlook.com mx -all como ejemplo sencillo. No se sustituye el registro actual sin analizarlo: primero se identifican los remitentes existentes, los subdominios, las cadenas include y el límite de consultas DNS. DKIM y DMARC se vuelven a comprobar en headers reales.
Validar la ruta completa
Desde un sistema de prueba externo ayudan estas comprobaciones de solo lectura:
dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
Los nombres de ejemplo se sustituyen por los reales. DNS, TCP y TLS no demuestran la entrega. Se prueba al menos un mensaje externo a Microsoft 365, uno saliente desde Microsoft 365, un destinatario no válido y un intento de relay desde una IP no autorizada.
En SFOS se correlacionan Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log y smtpd_error.log con el mismo momento. En Microsoft, Message Trace y el estado del conector muestran si EOP aceptó el mensaje o lo envió por el conector. Servicios y logs de Sophos Firewall clasifica los archivos de log.
Delimitar errores según el síntoma
El correo externo no llega a Microsoft 365
Comprobar primero MX, dirección pública, TCP 25, SMTP Relay desde WAN, regla MTA automática y Mail logs. Si SFOS acepta el mensaje pero no lo entrega, revisar la resolución DNS del destino del tenant, la política route and scan, TLS y el spool.
El correo saliente evita el firewall
Comprobar scope, prioridad y Message Trace del conector en Exchange Admin Center. Solo cuando la traza muestra el firewall como smarthost se evalúan el relay, la política y la dirección pública de SFOS. Para varios enlaces WAN, consultar la sección correspondiente de Mail Protection en MTA mode.
El relay se rechaza o estaría permitido con demasiada amplitud
Comparar la IP EOP real con la lista actual de Microsoft y los objetos SFOS. Una red EOP permitida debe figurar en Allow relay from hosts/networks; las demás fuentes terminan en Block relay from hosts/networks: Any. Una autorización cloud o WAN amplia no es una solución.
TLS o la validación del conector fallan
Comprobar por separado FQDN, DNS público, nombre del certificado, cadena completa, vigencia y STARTTLS. Un openssl s_client correcto confirma el endpoint del firewall, pero no el scope del conector ni la entrega completa. Allow invalid certificate no se utiliza como solución permanente.
Se produce un bucle de correo
Comparar el MX público y el destino de la política SMTP route and scan. Si ambos apuntan a mail.example.com, la política debe usar el destino Microsoft del tenant. Hasta que el routing sea inequívoco se restaura la ruta anterior documentada.
Realizar un rollback seguro
Primero se desactiva el conector de Exchange Online o se restaura su estado anterior. Después se reponen MX y SPF y se verifica su resolución pública. Solo cuando las pruebas entrante y saliente vuelven a funcionar por la ruta antigua se eliminan de SFOS la política piloto, los objetos EOP y las entradas de relay.
Los mensajes del spool o la cuarentena no se eliminan a ciegas. Forman parte de la transición y solo se tratan tras comprobar remitente, destinatario y ruta prevista.
Lista de comprobación operativa
- Están definidas las responsabilidades de SFOS, Microsoft 365 y otros gateways.
- MX, SPF, conector y flujo anteriores están documentados como recuperación.
- Los objetos EOP proceden de la lista actual de Microsoft y tienen responsable.
SMTP Relaysolo es utilizable mediante entradas Host-based relay limitadas; las fuentes no autorizadas se rechazan.- La política route and scan apunta al destino Microsoft del tenant y no vuelve al MX público.
- Conector, certificado, DNS, MX, SPF, DKIM y DMARC se han validado con mensajes reales.
- Se han superado pruebas entrante, saliente, de destinatario inválido y de relay no autorizado.
- Mail logs, spool, cuarentena y Microsoft Message Trace pueden correlacionarse por tiempo.
- Las redes EOP y la caducidad del certificado se revisan periódicamente.