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 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. Debe usarse la entrada obligatoria de Exchange Online para *.mail.protection.outlook.com y *.mx.microsoft en TCP 25 (ID de endpoint 10 en la instancia Worldwide), no el conjunto mucho mayor de todas las direcciones de Exchange Online. Para otra instancia cloud de Microsoft se utiliza su lista correspondiente. 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 SMTP actual de esa entrada de Microsoft, por ejemplo con el prefijo O365_EOP_. Los rangos no se agrupan en una red mayor. Si SMTP se publica o enruta mediante IPv6, también deben cubrirse los rangos IPv6 indicados; de lo contrario, hay que impedir que una ruta IPv6 involuntaria eluda la comprobación IPv4. 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 define por separado las redes desde las que se aceptan mensajes entrantes para los dominios protegidos; esta autorización no concede a esas fuentes un relay saliente sin restricciones.
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 abre Mail flow > Connectors > Add a connector y se seleccionan Connection from: Office 365 y Connection to: Partner organization. En Use of connector, se elige Only when email messages are sent to these domains y se introduce * para encaminar todo el correo saliente a través de SFOS. Una lista de dominios limitada de forma deliberada debe corresponder al diseño documentado. En Routing, se selecciona Route email through these smart hosts y se usa la IP pública o el FQDN mail.example.com del firewall. Estos campos siguen el procedimiento actual de Sophos para Microsoft 365.
En Security restrictions se activa Always use Transport Layer Security (TLS) to secure the connection (recommended). A continuación, el procedimiento de Sophos selecciona Any digital certificate, including self-signed certificates. Esta opción exige TLS, pero no comprueba una CA de confianza ni el nombre. Para producción se sigue la documentación de conectores de Microsoft: se selecciona Issued by a trusted certificate authority (CA) y también se exige el nombre de sujeto o SAN mail.example.com. Debe sustituirse por el FQDN real del firewall y validarse con una prueba 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 cada origen que envía realmente a Internet. Sophos muestra v=spf1 include:spf.protection.outlook.com mx -all como ejemplo sencillo: mx autoriza las direcciones de los hosts MX, mientras que include:spf.protection.outlook.com sigue siendo necesario si Exchange Online también envía directamente a Internet para este dominio. Si todo el correo externo sale invariablemente por SFOS, no se autoriza por costumbre una ruta directa de Microsoft que no se utiliza. El registro existente nunca se sustituye sin analizarlo: primero se identifican otros servicios de envío, subdominios, cadenas include y el límite SPF documentado por Microsoft de diez mecanismos que originan consultas DNS. Después, los headers reales deben confirmar que SPF se valida para la última IP remitente observada y que DKIM y DMARC siguen alineados.
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
El rollback restaura el estado anterior documentado, no un valor predeterminado supuesto. Primero se restablecen exactamente el estado de activación, el alcance, el routing y los ajustes TLS anteriores del conector de Exchange Online; solo se desactiva si se creó para este cambio. Después se restauran los destinos y prioridades MX registrados y el valor TXT SPF anterior completo. Se comprueba que el DNS autoritativo y varios resolvers públicos devuelvan los valores anteriores.
La política piloto, los objetos EOP y las entradas de relay se mantienen hasta que las pruebas entrante y saliente vuelvan a funcionar por la ruta antigua y haya vencido la TTL DNS anterior. Después solo se eliminan los elementos creados para este cambio; los objetos preexistentes o compartidos no se modifican.
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.