Configurar Sophos Firewall Mail Protection en modo MTA

Sophos Firewall no solo puede permitir el tráfico de correo como una conexión de firewall normal, sino también trabajar en modo MTA como Mail Transfer Agent entre Internet y el servidor de correo interno. El firewall acepta conexiones SMTP, analiza los mensajes con Mail Protection y después los entrega al servidor de correo definido.

Hoy recomendamos Mail Protection en el firewall solo para casos especiales planificados de forma consciente, por ejemplo cuando un Exchange local u otro servidor de correo interno debe protegerse directamente a través del firewall. Para Microsoft 365, Google Workspace y la mayoría de entornos modernos de correo en la nube, Sophos Central Email suele ser la mejor solución. Central Email está más cerca del servicio de correo real, se integra de forma más limpia con buzones cloud, reduce la complejidad en el conjunto de reglas del firewall y evita muchos temas clásicos de MTA como cambios MX, spools locales, cuestiones de relay y análisis de errores en el firewall.

Otro punto práctico: en comparación con Sophos Central Email, Email Protection en el firewall parece desde hace tiempo una función para entornos existentes, relevante sobre todo para servidores de correo on-premises ya instalados. Quien planifique hoy un proyecto nuevo debería comprobar primero si un cloud mail gateway es la arquitectura más limpia.

La solución es técnicamente potente, pero también propensa a errores si DNS, registro MX, TLS, relay, verificación de usuarios, policies y logs no se planifican correctamente. Un MTA mal configurado puede bloquear emails legítimos, retrasar el mailflow o, en el peor caso, ser entendido como relay.

Este artículo explica la configuración práctica de Sophos Firewall Mail Protection en modo MTA. No sustituye una planificación de Sophos Central Email. Para muchos entornos Microsoft 365 o Google Workspace, un cloud mail gateway suele ser más adecuado. Pero si se opera un Exchange local, un servidor de correo híbrido o una ruta SMTP basada deliberadamente en el firewall, hace falta un plan operativo claro.

Cuándo tiene sentido Mail Protection en el firewall

Mail Protection en Sophos Firewall tiene sentido sobre todo cuando el tráfico SMTP debe pasar deliberadamente por el firewall y este debe hacer más que simplemente reenviar el puerto 25.

Escenarios típicos:

Los emails entrantes deben aceptarse y analizarse primero en el firewall.
Un servidor de correo interno no debe ser accesible directamente desde Internet.
El análisis de spam, malware, tipos de archivo o contenido debe aplicarse antes de la entrega.
Los emails salientes deben enviarse de forma controlada a través del firewall o de un smarthost.
La cuarentena, el mail spool y los logs SMTP deben poder rastrearse en el firewall.

No toda configuración de correo debería pasar por el firewall. Si Sophos Central Email, Microsoft Defender for Office 365 u otro cloud mail gateway ya gestiona todo el mailflow, no se debería intercalar además Mail Protection en el firewall sin documentar exactamente el flujo de correo. Las pasarelas duplicadas generan rápidamente responsabilidades poco claras en cuarentena, cabeceras, SPF/DKIM/DMARC, TLS y troubleshooting.

Diferenciar modo MTA, Legacy mode y SMTP Relay

En Sophos Firewall hay que separar claramente tres cosas:

Función	Finalidad	Uso típico
MTA mode	El firewall acepta correo, lo analiza y lo entrega	Mailflow SMTP entrante o saliente con policies
Legacy mode	procesamiento de correo antiguo basado en proxy	Entornos existentes que se migran o se mantienen deliberadamente
SMTP Relay como servicio local	sistemas internos envían a través del firewall	Impresoras, escáneres, aplicaciones o sistemas de monitoring

El MTA mode es el modo objetivo normal para escenarios modernos de Mail Protection en el firewall. El servicio local SMTP Relay, en cambio, es un tema de Device Access. Solo debería ser accesible desde redes internas definidas. Una autorización demasiado amplia puede favorecer el abuso del relay. El endurecimiento de servicios locales se describe en Proteger el acceso a Sophos Firewall: configurar correctamente Device Access.

Requisitos

Antes de la configuración deben aclararse estos puntos:

Sophos Firewall con Email Protection válida o bundle adecuado.
No todos los modelos admiten MTA mode. XGS 87 y XGS 88 son appliances sin soporte de MTA mode.
Se conocen la zona DNS pública y el registro MX.
El servidor de correo interno, el puerto de destino y la ruta de entrega están documentados.
Está definida la dirección IP pública o dirección WAN para el tráfico SMTP entrante.
El firewall puede enrutar y alcanzar el servidor de correo interno.
El acceso DNS saliente del firewall funciona.
La estrategia TLS y de certificados deseada está aclarada.
El proceso de cuarentena y liberación está definido organizativamente.

Antes de cambiar el mailflow debería planificarse una ventana de mantenimiento. Una prueba con registros MX productivos sin plan de fallback es arriesgada, porque los emails entrantes pueden retrasarse o rechazarse rápidamente según el remitente.

Definir la arquitectura objetivo

Primero debe decidirse qué dirección debe procesar el firewall.

Mailflow entrante

En el mailflow entrante, los registros MX externos apuntan a la dirección pública en la que Sophos Firewall acepta SMTP. El firewall analiza el mensaje y lo reenvía al servidor de correo interno.

Flujo típico:

El remitente externo se conecta por SMTP a la dirección MX pública.
Sophos Firewall acepta la conexión en MTA mode.
Mail Protection comprueba remitente, destinatario, spam, malware, adjuntos y policy.
El firewall entrega el email al servidor de correo interno.
El servidor de correo interno entrega al buzón o procesa el mensaje.

Es importante que el servidor de correo interno no siga siendo accesible también sin filtrar desde Internet. Si en paralelo una regla DNAT todavía apunta directamente al servidor de correo, parte del tráfico puede saltarse Mail Protection. Para publicaciones normales de servidores, Publicar un servidor mediante DNAT es la base adecuada, pero en MTA mode el propio firewall es el punto de aceptación SMTP.

Mailflow saliente

En el mailflow saliente, el servidor de correo interno envía a través de Sophos Firewall. El firewall puede analizar mensajes, reenviarlos a un smarthost o entregarlos directamente, según la configuración.

Aclarar antes:

¿Puede la IP pública del firewall enviar emails directamente?
¿SPF, DKIM y DMARC son correctos para la ruta de envío elegida?
¿Se necesita un smarthost del proveedor?
¿Debe limitarse el tráfico SMTP saliente a sistemas internos concretos?
¿Dónde se monitorizan los mensajes rechazados o retrasados?

Para el tráfico de correo saliente debería utilizarse una estructura propia y trazable de reglas y policies. Una regla general LAN to WAN sin restricción clara suele ser demasiado amplia para servidores de correo. Los fundamentos sobre orden de reglas y perfiles de seguridad están en Comprender y construir correctamente reglas de Sophos Firewall.

Preparar cambio MX y pruebas externas

Un cambio de Mail Protection solo se vuelve crítico cuando los remitentes externos usan realmente la nueva ruta. Por eso deben comprobarse registro MX, DNS TTL, accesibilidad externa y rollback antes del cambio productivo.

Antes del cambio:

Documentar registro MX actual, prioridad y TTL.
Reducir el DNS TTL con antelación si puede ser necesario un fallback rápido.
Distinguir claramente la ruta de correo antigua y la nueva dirección de Sophos Firewall.
Identificar antiguas reglas DNAT directas al servidor de correo.
Definir destinatarios y remitentes de prueba.
Definir plan de fallback: MX antiguo, regla DNAT antigua o smarthost temporal.
Preparar monitoring de spool, cuarentena y queue del servidor de correo.

Comprobaciones externas útiles desde un sistema fuera de la propia red:

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 comandos no sustituyen una prueba completa de mailflow, pero muestran rápidamente si DNS, puerto 25 y STARTTLS son básicamente accesibles. example.com y mail.example.com deben sustituirse por el dominio real y el host de correo real.

Después del cambio se debe enviar de inmediato un email de prueba entrante y documentar toda la ruta:

¿Conexión visible en Log Viewer?
¿Entrada presente en smtpd_main.log?
¿Verificación del destinatario correcta?
¿Entrega al servidor de correo interno realizada?
¿Mensaje recibido en el buzón?
¿Sin entrega directa paralela que pase por alto el MTA?

Si el firewall acepta emails pero no los entrega, no debería revertirse inmediatamente el MX. Primero hay que aclarar si se trata de un problema interno de routing, DNS, TLS o servidor de correo. Pero si remitentes externos no pueden conectarse al firewall o se rechazan ampliamente emails legítimos, un fallback rápido a la ruta de correo anterior suele ser más sensato que experimentar durante más tiempo en la ruta MX productiva.

Activar MTA mode

Los ajustes básicos se encuentran en Sophos Firewall en:

Email > General settings

Allí se define el modo de email. Para esta guía es relevante MTA mode. Después del cambio, debe comprobarse si las policies, objetos host y dominios de correo existentes siguen encajando con la operación deseada.

En entornos existentes, no cambiar simplemente entre Legacy mode y MTA mode sin probar el mailflow. El procesamiento, los logs y la lógica de policy son diferentes. Antes de una migración deben documentarse la configuración actual del firewall, los registros MX, los conectores del servidor de correo y los ajustes de relay.

Configurar routing SMTP y dominios

Para emails entrantes, el firewall debe saber qué dominios debe aceptar y dónde debe entregarlos.

Flujo típico:

En Email > Policies and exceptions o en las áreas de Mail Protection, planificar los dominios y servidores de destino afectados.
Introducir dominio de correo, por ejemplo example.com.
Definir servidor de correo interno u objeto host como destino de entrega.
Comprobar si el firewall alcanza el servidor de correo en el puerto de destino.
Comprobar requisitos TLS y certificados.
Enviar email de prueba desde fuera a un destinatario conocido.

Para servidores de correo internos, DNS es especialmente importante. El firewall debe poder resolver correctamente los destinos internos, y los remitentes externos deben alcanzar la entrada MX pública. Si la resolución DNS interna juega un papel, ayuda Configurar DNS Request Routes en Sophos Firewall.

Planificar policies para spam, malware y adjuntos

Mail Protection solo es tan buena como las policies que realmente se aplican. Una policy no solo debe crearse, sino nombrarse con un propósito claro.

Preguntas importantes de policy:

¿Qué dominios o grupos de destinatarios están afectados?
¿Se procesa tráfico de correo entrante, saliente o en ambas direcciones?
¿Qué ocurre con spam, malware, adjuntos sospechosos o tipos de archivo no deseados?
¿Los emails se bloquean, se ponen en cuarentena, se entregan o se marcan con cabeceras?
¿Quién puede revisar la cuarentena y liberar emails?
¿Qué procesos de falsos positivos existen?

Si se utiliza Zero-Day Protection, los adjuntos sospechosos pueden analizarse adicionalmente. Los límites, informes y decisiones de liberación se explican en Comprender y operar Sophos Firewall Zero-Day Protection.

Proteger relay y Device Access

Un error frecuente es confundir el mailflow MTA con un SMTP Relay abierto. El firewall no debe poder utilizarse como relay desde redes arbitrarias.

Comprobar:

En Administration > Device access, SMTP Relay solo es accesible desde las zonas internas necesarias.
Si se usan ACL Exception Rules, las fuentes están definidas de forma estricta.
Solo servidores de correo internos, escáneres o servidores de aplicaciones definidos pueden relayar a través del firewall.
Desde WAN, redes de invitados y zonas untrusted, SMTP Relay no está habilitado de forma general.
El logging está activo para que abusos o configuraciones erróneas sean visibles.

Si impresoras, escáneres o aplicaciones necesitan enviar emails, debería documentarse para ello una ruta de relay interna propia. Estos sistemas no deberían comunicarse directamente con destinos SMTP externos arbitrarios si el entorno puede evitarlo.

Probar el mailflow

Después de la configuración, un único envío correcto no basta. Deben realizarse varias pruebas y documentarse los resultados.

Probar entrada

Comprobar al menos:

El registro MX externo apunta a la dirección esperada.
El puerto 25 es accesible desde fuera.
El firewall acepta la conexión en MTA mode.
El email se reenvía al servidor de correo interno.
El destinatario existe y recibe el mensaje.
La prueba de spam o malware se trata como se espera.
La entrada de cuarentena o log es trazable.

Probar salida

Comprobar al menos:

El servidor de correo interno envía por la ruta esperada.
La regla de firewall y la mail policy se aplican.
SPF, DKIM y DMARC encajan con la ruta de envío.
El servidor destino acepta el mensaje.
Se monitorizan bounces o mensajes Deferred.
Ningún otro sistema interno envía directamente al exterior sin planificación.

Comprobar logs

Para una revisión visual rápida ayuda Log Viewer. Para un análisis más profundo son importantes los archivos de log de correo. La asignación está en Troubleshooting de Sophos Firewall: servicios y logs.

Archivos de log relevantes:

Área	Archivo de log típico
SMTP MTA	`smtpd_main.log`
Errores SMTP	`smtpd_error.log`, `smtpd_panic.log`, `smtpd_reject.log`
Anti-Spam	`sasi.log`
Legacy SMTP/MTA	`awarrensmtp.log`, `awarrenmta.log`, `awarrenmta_debug.log`
POP/IMAP Proxy	`warren.log`

En troubleshooting urgente, anotar la hora de prueba, recopilar remitente, destinatario, asunto, IP de origen y Message-ID, y después correlacionar Log Viewer y archivos de log por tiempo.

Cuarentena, spool y almacenamiento

Mail Protection genera datos locales. Según el volumen, los mensajes acaban en cuarentena, spool o áreas temporales. Por eso el espacio de almacenamiento, el estado del SSD y el plan de recovery son más relevantes que con una regla de firewall pura.

Preguntas operativas prácticas:

¿Quién revisa la cuarentena y con qué frecuencia?
¿Cómo se liberan los falsos positivos?
¿Cuándo se elimina un mensaje en lugar de liberarlo?
¿Cómo se detecta un mail spool creciente?
¿Existe monitoring para espacio de almacenamiento y System Health?
¿Se planifica una breve prueba de mailflow después de firmware updates?

Para temas de almacenamiento y reporting encajan Limpiar almacenamiento y reportes de Sophos Firewall y Comprobar Sophos Firewall SSD Health. En entornos HA también debe tenerse en cuenta que la cuarentena de correo y los datos de correo procesados pueden ser datos operativos ligados al nodo. Los fundamentos HA están en Variantes de cluster HA de Sophos Firewall.

Troubleshooting

No llegan emails externos

Primero comprobar DNS y accesibilidad: registro MX, IP pública, puerto 25, restos de NAT, MTA mode y dominio de correo responsable. Después comprobar en Log Viewer y en smtpd_main.log si la conexión llega al firewall. Si no hay conexión visible, el problema probablemente está antes de Mail Protection.

El firewall acepta emails, pero no los entrega

Entonces son más probables el servidor de correo interno, routing, DNS, puerto de destino, TLS, verificación de destinatario o policy. Se comprueba si el firewall puede alcanzar el servidor de correo y si este acepta la conexión. Reject logs y logs del servidor de correo deben evaluarse juntos por tiempo.

Muchos emails permanecen en el spool

Un spool creciente suele indicar problemas de entrega: servidor de correo interno no accesible, requisito TLS no encaja, falla la resolución DNS o el servidor destino rechaza el mensaje. En este caso no basta con volver a entregar mensajes individuales, sino que hay que buscar la causa en la ruta de routing y SMTP.

Un caso importante de orden de reglas se pasa por alto fácilmente: si una regla de firewall creada automáticamente o manualmente está por encima de la regla MTA y hace match con tráfico SMTP, la regla MTA real ya no se evalúa. Entonces los emails pueden quedar en el mail spool aunque DNS, puerto 25 y servidor de correo parezcan básicamente correctos.

Comprobar:

Abrir Rules and policies > Firewall rules.
Comprobar reglas por encima de la regla MTA o SMTP.
Revisar nuevas reglas creadas automáticamente, reglas IPsec, reglas hotspot o reglas colocadas manualmente en Top.
Realizar de nuevo la prueba SMTP y comparar Log Viewer, mail spool y smtpd_main.log.

La regla no debe moverse hacia abajo a ciegas si cumple otros fines productivos. Lo decisivo es si intercepta inesperadamente tráfico SMTP antes de la regla MTA.

Falta el digest de cuarentena para direcciones alias

Si los usuarios emplean direcciones alias, no se deben comprobar los ajustes de cuarentena solo para la dirección de correo primaria. Según Sophos, los ajustes de cuarentena no se aplican automáticamente por defecto a direcciones alias. Si faltan emails digest o liberaciones para destinatarios alias, las direcciones alias deben considerarse junto con la dirección primaria en el contexto de cuarentena o usuario.

Un remitente legítimo se detecta como spam

Los falsos positivos no deberían responderse de inmediato con excepciones amplias. Primero comprobar dominio remitente, SPF/DKIM/DMARC, cabeceras, reputación, policy match y destinatarios afectados. Si una excepción es necesaria, debería limitarse de forma estricta y documentarse con fecha de revisión.

Los sistemas internos no pueden relayar

Comprobar si SMTP Relay en Administration > Device access está permitido desde la zona correcta y si la fuente encaja con la ACL. Después revisar los logs de correo. Si un escáner o una aplicación debe relayar, la fuente debería documentarse como objeto host y no habilitarse innecesariamente toda una red.

Después de un firmware update el correo funciona de forma diferente

Después de firmware updates deben comprobarse MTA mode, policies, certificados, mail spool, cuarentena y logs relevantes. Para actualizaciones mayores también encaja Comprobar Sophos Firewall antes del upgrade a SFOS 22.

Checklist operativa

Licencia Mail Protection y soporte de appliance comprobados.
MTA mode elegido deliberadamente y documentado.
Registro MX, IP pública y servidor interno de destino correctos.
Cambio MX, pruebas externas y rollback preparados.
Ninguna regla DNAT paralela sin filtrar evita el MTA.
Policies entrantes y salientes nombradas de forma comprensible.
El orden de reglas del firewall no impide que se aplique la regla MTA.
SMTP Relay permitido solo desde fuentes internas definidas.
Proceso de cuarentena y falsos positivos definido.
Direcciones alias consideradas en el proceso de cuarentena y digest.
Mail spool, espacio de almacenamiento y System Health monitorizados.
Logs conservados localmente, en Sophos Central o por Syslog durante suficiente tiempo.
Después de firmware updates se realiza una prueba de mailflow.

Para retención más larga y correlación con otros eventos de seguridad, comprobar Central Firewall Reporting o Enviar Syslog de Sophos Firewall a SIEM.

FAQ

¿Qué es el MTA mode en Sophos Firewall?

En MTA mode, Sophos Firewall trabaja como Mail Transfer Agent. Acepta mensajes SMTP, los analiza con Mail Protection y después los entrega al servidor de correo interno o al siguiente mailhop.

¿Mail Protection necesita una licencia propia?

Sí. Para Mail Protection se necesita una autorización Email Protection adecuada o un bundle que incluya esta función. Sin licencia, la protección de correo MTA no debe planificarse como ruta de protección productiva.

¿Sophos Firewall Mail Protection es lo mismo que Sophos Central Email?

No. Sophos Firewall Mail Protection se ejecuta en el firewall dentro del mailflow. Sophos Central Email es un cloud mail gateway. Ambos enfoques pueden tener objetivos similares, pero son arquitectónicamente distintos y no deberían combinarse sin planificación.

¿Sophos Firewall puede abusarse como SMTP Relay?

El riesgo aparece cuando SMTP Relay se habilita demasiado ampliamente. Por eso SMTP Relay en Administration > Device access debe permitirse solo desde fuentes internas claramente definidas.

¿Por qué los emails quedan bloqueados en el mail spool?

A menudo intervienen el servidor de correo interno, DNS, TLS o routing. Además debe comprobarse si una regla de firewall de mayor prioridad hace match con tráfico SMTP antes de la regla MTA. Entonces la regla MTA real no se evalúa.

¿Dónde se ven problemas con MTA y SMTP?

Primero en Log Viewer y después en los logs de correo bajo /log, especialmente smtpd_main.log, smtpd_error.log, smtpd_reject.log y sasi.log. En problemas de entrega también deben revisarse los logs del servidor de correo interno.