Configurar Sophos Email Gateway con Google Workspace

Con una integración Gateway, el correo entrante sigue Internet → Sophos Gateway → Google Workspace y el saliente Google Workspace → Sophos Gateway → Internet. Para migrar con seguridad, configura y prueba cada destino, gateway y ruta interna antes de cambiar los registros MX de producción. Así habrá en cada fase una ruta de entrega conocida y una opción de reversión.

Vía rápida: verifica el dominio en Sophos Fusion (antes Sophos Central), prepara el host de entrega de Google independiente, añade los buzones, limita el Inbound Gateway de Google a las direcciones IP regionales de Sophos y enruta los mensajes internos directamente a Google. Después, introduce el Outbound Relay Host mostrado en Sophos Fusion como gateway saliente de Google. Cambia los MX principales por los valores mostrados para tu región de Sophos solo tras probar ambas direcciones.

Alcance y requisitos previos

Esta guía se aplica a Sophos Email en modo Gateway con Google Workspace. Necesitas acceso administrativo a Sophos Fusion, la consola de administración de Google y el DNS del dominio de correo. El dominio debe estar configurado en Sophos Gateway y todos los destinatarios protegidos deben existir en Sophos Email.

Antes de empezar, registra en una hoja de cambio:

dominio de correo y unidad organizativa de Google Workspace afectada;
conjunto MX de producción actual, con prioridades y TTL;
registro SPF actual y configuración DKIM y DMARC existente;
valores MX, Delivery IP, relay y SPF mostrados en Sophos Fusion para tu región de datos;
destinos MX indicados actualmente por Google para tu tenant;
un remitente de prueba externo y otro interno, además de un destinatario interno y otro externo;
requisitos TLS previstos y ventana de mantenimiento o reversión.

No copies hosts ni direcciones IP regionales de ejemplos o tickets antiguos. Cópialos de Sophos Fusion justo antes del cambio. Verifica también los destinos de Google con la documentación actual de Google o la pantalla del tenant.

Límite del producto: Google Post Delivery Protection y la sincronización de Google Directory no modifican ni sustituyen este diseño de enrutamiento SMTP. Son tareas distintas y quedan fuera del alcance.

Preparar el cambio con seguridad

Documenta el flujo actual con un mensaje entrante y otro saliente de prueba. Guarda las cabeceras y el seguimiento de Google y confirma que todavía no aparecen en Message History de Sophos.
Reduce con suficiente antelación el TTL DNS de los MX de producción a un valor adecuado para la operación. Documenta el conjunto MX anterior y todas las reglas de enrutamiento de Google como estado de reversión.
Comprueba si ya hay activo otro secure email gateway, un Google Outbound Gateway o una regla catch-all. No apliques en paralelo reglas solapadas a los mismos mensajes.
Utiliza un pequeño ámbito piloto o una ventana de pruebas planificada. Activa protecciones como Reject all mail not from gateway IPs solo cuando estén registradas todas las Sophos Delivery IP regionales y se hayan probado las rutas internas de Google.

La principal protección contra bucles consiste en separar inequívocamente los destinos: el MX principal apuntará a Sophos, mientras que el destino guardado en Sophos apunta a un destino independiente de Google y nunca de vuelta al MX de Sophos. La ruta saliente de Google apunta a Sophos, pero no debe volver a aplicarse a mensajes entrantes ya entregados por Sophos.

Configurar el flujo entrante

Preparar el dominio y el destino de Google en Sophos

En Sophos Fusion, abre Global Settings > Products and Services > Email > Gateway Domains y selecciona o añade el dominio.
Como Delivery Destination, usa un nombre MX separado bajo tu dominio, por ejemplo routing-mx.example.com, e introduce el puerto SMTP documentado por Sophos. Es una ruta DNS dedicada a las entregas de Sophos, no el MX de producción del dominio principal.
Inicia Verify Domain Ownership, publica sin cambios en DNS el valor TXT mostrado para el dominio y vuelve a verificar después de la propagación.
Crea para routing-mx.example.com registros MX que apunten a los destinos actuales de Google indicados para tu tenant de Google Workspace. No deben apuntar a Sophos.
Añade cada buzón o destinatario protegido a Sophos Email y guarda la configuración del dominio.

La verificación es correcta cuando Sophos Fusion muestra el dominio como verificado y una consulta DNS para routing-mx.example.com devuelve únicamente los destinos de Google previstos.

Si la entrega mediante ASPMX.L.GOOGLE.COM presenta problemas, cambia únicamente el destino de entrega de Google situado detrás de routing-mx.example.com a SMTP.GOOGLE.COM. Es una alternativa condicional para la entrega de Sophos a Google, no un valor predeterminado universal ni un cambio del MX de producción del dominio principal, que sigue apuntando a Sophos. Confirma antes los valores válidos para tu entorno de Google Workspace y después vuelve a probar el flujo entrante. Si la prueba también falla, restaura el destino de entrega de Google documentado anteriormente y contacta con Sophos Support.

Proteger el Inbound Gateway de Google

En la consola de administración de Google, abre Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway para la organización superior afectada.
Activa el Inbound Gateway y añade solo las Delivery IP que Sophos Fusion indica para tu región.
Activa Automatically detect external IP y el requisito TLS acordado.
Activa Reject all mail not from gateway IPs solo después de una prueba piloto. Esta opción bloquea la entrega directa y evita eludir Sophos, pero una lista IP incompleta también puede detener correo legítimo.
Guarda y espera hasta 24 horas para que se aplique la configuración entrante.

Si la restricción estricta bloquea rutas de entrega propias de Google, desactiva temporalmente el rechazo, restaura el flujo y determina las direcciones actuales necesarias de Google y Sophos conforme a la documentación de los fabricantes. No autorices ampliamente redes desconocidas.

Sophos informa de una anomalía de DMARC observada en sus propias pruebas: si están activados Time of Click URL Protection o los ajustes de mensajes de usuario final, Google a veces marca mensajes entrantes como fallos de DMARC, aunque la documentación de Google indica que la autenticación DMARC se omite para los mensajes de hosts incluidos en la lista del gateway y que el gateway entrante debe realizar la comprobación. Sophos afirma haber comunicado esta discrepancia a Google. Tenla en cuenta antes de considerar el fallo como prueba de que Automatically detect external IP o la lista Delivery IP son incorrectos.

Enrutar mensajes internos directamente a Google

Los mensajes internos no deben viajar por el MX de producción a Sophos y volver después a Google. En Apps > Google Workspace > Gmail > Hosts, crea una ruta con los destinos actuales de Google para el tenant. En Apps > Google Workspace > Gmail > Routing, aplícala solo a Internal - Sending y limítala a tu dominio mediante un filtro del remitente del sobre. Activa TLS y la validación de certificado firmado por una CA según las indicaciones de Google y Sophos.

Define ámbitos y condiciones de coincidencia que no se solapen entre la ruta interna y la regla del gateway saliente. Guarda el cambio de enrutamiento y espera hasta 24 horas para que surta efecto; puedes seguir los cambios en el registro de auditoría de administración de Google Workspace. No inicies la validación de mensajes internos ni del piloto, ni cambies el MX de producción, hasta que el cambio sea efectivo. Envía después un mensaje interno a un destinatario del mismo dominio: debe permanecer en Google y no aparecer además como análisis entrante y saliente en Sophos.

Configurar el flujo saliente

Abre el dominio en Gateway Domains y selecciona Inbound and Outbound bajo Configure Domain.
Selecciona Google Apps Gmail como Outbound Gateway, guarda y copia el Outbound Relay Host mostrado para el tenant en Configure External Dependencies > Outbound Settings. Esta etiqueta representa Google Workspace en Sophos Fusion.
En la consola de Google, abre la configuración del gateway saliente para la organización superior afectada e introduce exactamente ese Relay Host. La interfaz actual de Google puede organizar de otro modo la sección de enrutamiento; no deduzcas hosts de ejemplos.
Asigna a la regla criterios de remitente y mensaje que no se solapen con la ruta interna. Desactiva o excluye del mismo ámbito una segunda regla catch-all o de gateway.
Guarda, espera varios minutos para que se aplique la configuración saliente y envía primero desde un remitente piloto a una dirección externa de prueba.

Mantener SPF y DKIM alineados con la ruta real

El registro SPF debe incluir todas las rutas que envían realmente correo autorizado, pero no conservar rutas sin uso. Durante una transición controlada pueden estar autorizados Google Workspace y Sophos. Cuando todo el correo saliente pase exclusivamente por Sophos, elimina la ruta directa antigua de Google solo si ninguna aplicación, reenvío o plataforma de terceros sigue usándola.

Obtén de Sophos Fusion el valor include de SPF regional de Sophos; aquí un ejemplo sería peligroso. Antes de guardar, confirma que el dominio sigue teniendo exactamente un registro TXT de SPF y que la estrategia -all o ~all elegida es adecuada para la migración. Mantén activas las firmas DKIM y, por separado, mantén DMARC activo; comprueba ambos en un mensaje recibido externamente tras el cambio.

Validar el piloto y después cambiar el MX de producción

Antes de cambiar el MX de producción, usa el ámbito piloto o la ventana de pruebas para validar la entrega saliente por Sophos y un mensaje interno que permanezca en Google. Confirma las cabeceras previstas, el seguimiento de Google y Sophos Message History, y verifica que el registro SPF preparado cubra la ruta de envío real del piloto.

Solo cuando funcionen el destino, los destinatarios, el Inbound Gateway, la ruta interna, el gateway saliente, la preparación de SPF y las comprobaciones piloto debes sustituir el conjunto MX de producción del dominio principal por los valores y prioridades mostrados en Sophos Fusion para tu región. Durante la propagación DNS, conserva documentados el estado anterior, el responsable y la decisión de reversión. Si falla la entrega, restaura el conjunto MX guardado en vez de añadir más rutas sin probar.

Validar ambas direcciones

Después de cada cambio, espera la propagación y realiza cuatro pruebas específicas:

externo → destinatario interno protegido;
usuario interno → destinatario externo;
usuario interno → usuario interno del mismo dominio;
intento de entrega directa que eluda Sophos, siempre que esté autorizado y pueda hacerse de forma segura.

Para las pruebas 1 y 2 debe aparecer exactamente una entrada coincidente, con dirección, remitente, destinatario, hora y resultado correctos, en Sophos Fusion bajo Reports > Message History. Examina en paralelo el seguimiento de Google y las cabeceras completas del mensaje entregado. La cadena Received debe mostrar la ruta prevista en el orden correcto; comprueba SPF, DKIM y DMARC en el destino externo.

La prueba 3 no debe atravesar Sophos dos veces innecesariamente. La prueba 4 debe rechazarse tras activar la restricción estricta del Inbound Gateway. Varias entradas de Sophos para el mismo Message-ID, hosts repetidos en la cadena Received o tiempos de entrega que aumentan mucho indican procesamiento duplicado o un bucle.

Resolver problemas de forma metódica

Falta el correo externo entrante: comprueba primero el MX de producción y su región, y después Sophos Message History. Si no hay entrada, el fallo está antes de Sophos. Si hay entrada pero Google no recibe, revisa routing-mx.example.com, destinos de Google, destinatarios, restricción Delivery IP y TLS.
El correo saliente no aparece en Sophos: revisa el ámbito y las condiciones de coincidencia de las reglas de Google y el Outbound Relay Host introducido. Si aparece en Sophos pero no llega, examina estado de entrega, SPF/DKIM/DMARC y error del sistema de destino.
El correo interno aparece dos veces en Sophos: confirma que Internal - Sending coincide solo con tu dominio y que ninguna regla general coincide con los mismos mensajes. Elimina reglas salientes o catch-all solapadas en vez de añadir otra excepción.
Error TLS: compara host de origen y destino, nombre del certificado, confianza de la CA y opción TLS exigida en ambos lados. No desactives permanentemente el requisito; relájalo para una prueba solo tras documentar la decisión de riesgo y restáuralo después.
El correo circula entre Google y Sophos: detén el cambio. Compara el MX principal, routing-mx.example.com, la ruta saliente de Google y los saltos de cabecera. El destino de Sophos debe ser Google, no Sophos; la regla saliente de Google no debe volver a capturar correo entregado por Sophos.
Solo fallan algunos destinatarios: comprueba que existan y estén escritos igual en Sophos Email y Google Workspace, incluida la resolución de alias y grupos. No eludas errores de dominio o destinatario con un permiso de relay amplio.

Si DNS, ámbito de rutas, hosts, coincidencia del dominio, TLS y destinatarios son correctos pero el error documentado sigue siendo reproducible, facilita a Sophos Support el Message-ID, la fecha y hora, remitente, destinatario, cabeceras relevantes y entradas de Sophos Message History y del seguimiento de Google. Así podrá investigarse el salto afectado sin cambiar más reglas de producción por conjeturas.