Ir al contenido
Avanet

Sophos Email Mailflow: reparar Microsoft 365 de forma sistemática

Sophos Email

Si Sophos Email Mailflow falla en Microsoft 365, no conviene eliminar conectores ni reglas de transporte por mera sospecha. Primero se comprueba el estado del dominio en Sophos Fusion (antes Sophos Central), se ejecuta Run a Quick Test y se compara el mismo mensaje en Microsoft Message Trace y Sophos Message History. Solo entonces se repara la ruta afectada.

Vía rápida: Connected con una marca verde indica que la conexión Mailflow está activa. Not Connected con una cruz roja exige comprobar la conexión o los permisos. Un signo de exclamación con View Details señala una regla o un conector modificado directamente en Microsoft 365. Ante un error 552, hay que buscar primero cabeceras de Sophos y Microsoft duplicadas: suelen indicar que una plataforma de firmas ha vuelto a enviar el mensaje por Sophos.

Este runbook solo se aplica a Sophos Email en modo Mailflow (MFR). Los registros MX siguen apuntando a Microsoft 365 y las reglas de transporte y los conectores de Microsoft envían los mensajes a Sophos y de vuelta. En modo Gateway, los MX apuntan a Sophos y el diagnóstico y la retirada son distintos. No se deben aplicar instrucciones de Gateway a un dominio Mailflow. La implantación y la migración planificada se describen en Configurar Sophos Email Mailflow para Microsoft 365.

Requisitos y punto de partida seguro

Se necesita acceso administrativo a Sophos Fusion y una cuenta capaz de conceder consentimiento a la aplicación Sophos Email y los permisos de flujo de correo de Exchange Online. Los dominios de Microsoft 365 deben ser aptos para Mailflow y los usuarios y grupos necesarios deben estar sincronizados.

Antes de cambiar nada, se registra:

  • dominio, remitente, destinatario, hora UTC, Internet Message-ID y cabeceras completas;
  • estado actual de Mailflow Connection y, si procede, Post Delivery;
  • nombres, estado y prioridad de las reglas y conectores de Sophos, del servicio de firmas y de terceros;
  • resultados de Microsoft Message Trace y Sophos Message History;
  • última configuración operativa y responsable de cada cambio.

Se modifica un solo factor por prueba. No se elimina el dominio xgeconnector.com creado por Sophos, ya que puede interrumpir el flujo y el procesamiento. Tampoco se borra un conector aparentemente huérfano sin documentar su dominio y la vía de reversión.

1. Comprobar la conexión y el dominio

  1. En Sophos Fusion, abrir Global Settings.
  2. Elegir Products and Services > Email > M365 Mailflow Domains.
  3. Revisar el dominio:
    • marca verde, Connected: existe conexión;
    • cruz roja, Not Connected: al pasar el cursor aparece la marca verde para reconectar;
    • exclamación, View Details: se debe investigar un cambio de Microsoft 365.
  4. Pulsar el icono de prueba. En Run a Quick Test, indicar un destinatario controlado y seleccionar Proceed. Puede tardar unos minutos.
  5. Si falla, usar primero Run The Test Again. Si persiste, seleccionar Reconnect.

Un Quick Test correcto restaura la marca verde, pero no demuestra la entrega completa. Después se envía un mensaje entrante y otro saliente controlados y se siguen hasta el destinatario final en Microsoft Message Trace y Sophos Message History.

Si Reconnect no crea reglas o conectores

Se comprueba que la aplicación Sophos Mailflow tenga las asignaciones por rol necesarias en el tenant. En particular, los permisos de flujo de correo de Exchange Online deben estar disponibles mediante el rol de administrador de Exchange. La reparación automática requiere consentimiento válido y esos permisos.

Si Reconnect sigue fallando, no se repiten borrados manuales. Se conservan estado, resultado del Quick Test, nombres de reglas y conectores y Message-ID, y se escala a Sophos Support; puede ser necesaria una limpieza manual.

2. Tratar una alerta por objetos Mailflow modificados

Sophos supervisa la desactivación, eliminación y modificación de reglas y conectores necesarios para Mailflow. La auditoría de Microsoft 365 debe estar activa y la aplicación Sophos Email debe tener el permiso organizativo Read activity data. Para dominios configurados antes del 12 de abril de 2022, se concede al desconectar y reconectar; las configuraciones posteriores deberían tenerlo.

Las alertas son High, Medium o Low. Todas aparecen en Sophos Fusion; solo High y Medium también envían correo a administradores y superadministradores y cambian el estado del dominio. En Alerts, se agrupan, se abre Mail Flow Rules y View Details muestra dominio, hora, objeto y cambio.

  • Cambio de nombre conocido de una lista: comprobar que el grupo se haya sincronizado, actualizarlo en el dominio M365 y guardar.
  • Cambio intencionado: documentarlo y ejecutar Run a Quick Test; conservarlo solo si pasa.
  • Cambio desconocido o accidental: identificar evento y responsable en la auditoría de Microsoft 365. Revertir un cambio erróneo entendido y repetir el Quick Test. Si no está claro o falla, usar Reconnect para que Sophos recree o active los objetos necesarios.

Una alerta no demuestra por sí sola que el flujo esté cortado; tampoco un cambio previsto es seguro solo por ser conocido. Lo deciden Quick Test y las pruebas de entrega.

3. Corregir fallos SPF al volver a Microsoft 365

En Mailflow, los mensajes salientes van de Microsoft 365 a Sophos y regresan a Microsoft 365. Microsoft puede fallar SPF si el remitente regional de Sophos no está autorizado en el registro SPF del dominio.

v=spf1 include:spf.protection.outlook.com -all

Se añade el dominio include publicado para la región de Sophos Fusion:

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> es un marcador, no un valor publicable. Se obtiene el valor regional actual de Sophos Email domain information, se mantiene un único registro TXT SPF por dominio y no se cambia el mecanismo final sin revisarlo. Tras la propagación DNS, se verifica el TXT publicado y se envía una prueba saliente; SPF debe pasar para la ruta prevista.

4. Corregir reenvíos y Microsoft DLP

Se rechaza un mensaje reenviado automáticamente al exterior

Microsoft 365 reescribe con SRS el envelope-from (P1 From). Si Header-From sigue siendo un dominio externo no configurado en Sophos Email, Sophos puede rechazarlo. Sophos no retransmite de forma general correo originado fuera porque supondría un riesgo similar a open relay y dañaría la reputación.

  1. En Microsoft 365 Security Center, abrir Policies & rules > Threat policies > Rules > Enhanced filtering.
  2. Elegir el conector que permite mensajes entrantes desde Sophos Email.
  3. Activar Automatically detect and skip the last IP address para la organización.
  4. Configurar el reenvío afectado para usar como remitente un buzón local del dominio protegido.
  5. Repetir con el mismo origen y destino y comparar cabeceras, Message Trace y Message History.

No se añaden dominios externos arbitrarios a Sophos ni una excepción amplia de relay.

Microsoft DLP duplica las notificaciones

Si una regla DLP se activa en ambos pasos de Mailflow, se excluyen de esa regla únicamente las IP de remitente documentadas de Sophos Email:

  1. Acceder como administrador al portal DLP de Microsoft Purview.
  2. Editar la policy y la regla en Advanced DLP rules > Customize advanced DLP rules.
  3. Elegir Add exception > Except if sender IP address is e introducir solo las IP regionales actuales indicadas en la información del dominio.
  4. Guardar y repetir para cada regla afectada.
  5. Verificar con un mensaje controlado que DLP sigue evaluando y genera una sola notificación.

La excepción no se amplía a rangos innecesarios, para que DLP siga activo en las demás rutas.

5. Investigar el error 552 y los servicios de firma

El NDR habitual es:

552 5.6.0 Headers too large (32768 max)

Se revisan las cabeceras completas. Grupos duplicados como X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info o X-Microsoft-Antispam-Message-Info-Original indican procesamiento repetido. Con CodeTwo o Exclaimer suele aparecer esta ruta incorrecta:

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

La ruta definitiva procesa una vez cada servicio:

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Se revisan conectores y reglas del servicio de firma y Sophos. CodeTwo o Exclaimer debe actuar antes de la salida por Sophos; se eliminan o restringen las reglas solapadas que devuelven el mensaje a Sophos. La regla de terceros se configura según su guía vigente. Message Trace y las cabeceras deben demostrar un paso por cada servicio.

Solución temporal limitada si no hay bucle

Si no existe ruta duplicada pero una gran cabecera de diagnóstico supera el límite, se crea en Exchange Admin Center, Mail flow > Rules:

  • Apply this rule if: A message header > includes any of these words; cabecera X-Sophos-Email-ID, palabra True.
  • Do the following: Modify the message properties > remove a message header; cabecera X-Microsoft-Exchange-Diagnostics-untrusted.
  • Se dejan los demás valores predeterminados. La regla va después de las reglas de prefiltro y redirección de Sophos Email; si conservan sus prioridades predeterminadas 0, 1 y 2, se usa la prioridad 3.

Antes se exporta o documenta el orden. Después se prueba un mensaje afectado y otro normal. La regla reduce datos de cabecera, pero no corrige un bucle. Eliminar cabeceras Microsoft en Sophos con .* también es solo temporal; con cabeceras Sophos duplicadas se repara el enrutamiento.

Comportamiento esperado: dos etiquetas de confidencialidad

Microsoft 365 puede aplicar dos veces la misma sensitivity label a un mensaje saliente: procesa la etiqueta antes de enviarlo a Sophos y después de su retorno. Si Message Trace muestra esa ruta sin bucle, es comportamiento esperado de Mailflow y no demuestra un segundo análisis de Sophos. No se cambian conectores solo por dos etiquetas.

Validación, reversión y escalado

La reparación termina cuando:

  • el dominio muestra Connected en M365 Mailflow Domains y Quick Test pasa;
  • un mensaje entrante y otro saliente coinciden en Microsoft Message Trace y Sophos Message History y se entregan;
  • las cabeceras muestran solo los pasos previstos por Sophos, Microsoft y el servicio de firma;
  • SPF pasa y las pruebas de reenvío o DLP dan exactamente el resultado esperado;
  • no aparecen alertas Mailflow High o Medium nuevas.

Para una reversión manual deliberada, se desconecta el dominio pulsando la cruz junto a Connected en M365 Mailflow Domains. Sophos elimina las aplicaciones, conectores y reglas creados para ese dominio; puede tardar unos minutos. Antes de reconectar, se verifica la eliminación en App registrations de Microsoft Entra Admin Center y en Mail flow > Rules y Mail flow > Connectors de Exchange Admin Center. Después se reconecta con consentimiento válido.

Distinguir un bloqueo RBL de Gateway anterior a la detección de Mailflow

Si se rechaza un mensaje entrante, los registros de Sophos Gateway muestran un rechazo RBL, pero Sophos Message History no contiene el evento Mailflow correspondiente, es posible que la conexión Gateway aún activa aplicara su lista de bloqueo en tiempo real antes de que Sophos pudiera detectar la conexión Mailflow y reenviar el mensaje. Hay que correlacionar el mismo mensaje y la misma hora UTC en los registros de Gateway, Microsoft Message Trace y Mailflow Message History. En este patrón, la ausencia del evento Mailflow no demuestra que haya fallado el conector Mailflow.

No se responde omitiendo ampliamente ni desactivando globalmente una RBL. Tampoco se prolonga el procesamiento paralelo: una vez validados los flujos Mailflow entrante y saliente, se elimina de inmediato la antigua conexión Gateway conforme al plan de migración.

Es un paso controlado, no una limpieza improvisada. En producción se definen antes ventana, ruta alternativa y criterio de aborto. En una migración Gateway a Mailflow, la ruta Gateway documentada solo queda como reversión prevista; no se enruta simultáneamente el mismo dominio productivo por Gateway y Mailflow, pues causaría análisis duplicados o bucles. Si quedan objetos, su responsable no está claro o Reconnect falla con permisos correctos, se detienen los cambios y se entregan a Sophos Support dominio, Message-IDs, horas UTC, cabeceras, trazas, Quick Test e inventario.