Sophos Email: configurar la autenticación del remitente y Smart Banners

Sophos Email comprueba los mensajes entrantes mediante DMARC, SPF y DKIM, y también puede detectar anomalías en los encabezados y los dominios. Estas comprobaciones no determinan por sí solas qué ocurre con un mensaje: la Email Security policy correspondiente define los tipos de error, su orden y las acciones que se aplican. Los Smart Banners muestran el resultado a los destinatarios y pueden ofrecerles acciones seguras.

Procedimiento rápido recomendado: En My Products > Email Security > Policies, abra la Email Security policy afectada y configure en Settings > Inbound > Authentication las acciones que deben ejecutarse si fallan DMARC, SPF o DKIM. Al principio, seleccione Quarantine para los errores críticos en lugar de Reject, ordene las condiciones de arriba abajo y, a continuación, revise Header anomaly, Domain anomaly y End-user message settings. Compare mensajes de prueba legítimos y fallidos en Message History antes de añadir excepciones o aplicar medidas más estrictas.

Preparar el alcance, las pruebas y la reversión

Antes de cambiar la configuración, identifique los dominios y buzones protegidos, los servicios de envío legítimos conocidos y un grupo de prueba limitado. Anote:

• la política afectada, su posición y si está en estado Enforced;
• la dirección Inbound y los usuarios, grupos y dominios asignados;
• las reglas actuales de DMARC, SPF, DKIM y comprobación del remitente, respetando su orden;
• las entradas existentes en la lista de permitidos y las excepciones aprobadas por la empresa;
• las acciones originales, el texto de los banners y las opciones disponibles para los usuarios finales;
• los remitentes y destinatarios de prueba, junto con los resultados esperados.

Para revertir los cambios, restaure el orden de las reglas, las acciones y las opciones de los banners que haya anotado, o cambie una política piloto nueva a Policy Bypassed. Durante la prueba piloto, modifique un solo conjunto de reglas relacionadas cada vez; así podrá atribuir con claridad cualquier resultado inesperado.

Advertencia: Nunca utilice una excepción de autenticación para justificar la desactivación del análisis de malware. Incluso un remitente permitido o correctamente autenticado puede utilizar una cuenta comprometida o enviar contenido malicioso. Limite cada excepción al problema de autenticación demostrado y al alcance mínimo imprescindible, y mantenga activas todas las demás comprobaciones de protección.

Entender correctamente DMARC, SPF y DKIM

Los tres métodos responden a preguntas distintas:

• SPF compara el servidor de correo emisor con los hosts, las direcciones IP y las redes que el propietario del dominio del remitente del sobre ha autorizado en DNS.
• DKIM valida la firma digital de un mensaje mediante la clave pública que el dominio firmante ha publicado en DNS.
• DMARC determina si SPF o DKIM se valida correctamente y si el dominio correspondiente está alineado con el dominio visible del encabezado From. Sin un registro DMARC válido y una comprobación SPF o DKIM que se pueda evaluar, Sophos no puede completar la evaluación de DMARC.

El interruptor que aparece en la política controla la acción en caso de error; las comprobaciones de autenticación se ejecutan siempre. Este artículo solo trata la evaluación de mensajes entrantes. No crea ni aloja registros DNS para sus dominios de salida, ni activa la firma DKIM de los mensajes salientes.

Configurar Message Authentication

1. Abra My Products > Email Security > Policies, seleccione la política Email Security correcta y compruebe su grupo de destino y su posición.
2. Abra Settings > Inbound > Authentication.
3. Active las acciones necesarias en caso de error para DMARC, SPF y DKIM.
4. Para cada comprobación, haga clic en Add Rule y seleccione un tipo de error y la acción correspondiente.
5. Ordene las condiciones desde el caso más específico hasta el más general. Sophos las evalúa de arriba abajo y aplica la primera coincidencia.
6. Guarde la política y confirme que esté en estado Enforced para los destinatarios de prueba.

Sophos recomienda Quarantine para todas las categorías de Message Authentication. También es una opción adecuada durante una prueba piloto, ya que el mensaje sigue disponible para analizarlo y liberarlo de forma controlada. Reject rechaza el mensaje durante el procesamiento; Sophos no conserva los encabezados sin procesar de los mensajes rechazados. Tag subject line marca el mensaje y lo envía a las siguientes fases de procesamiento. Deliver también significa que el mensaje pasa a la siguiente capa de análisis, no que necesariamente se entregue en el buzón. Include In End User Quarantine permite que un mensaje en cuarentena aparezca en la cuarentena del usuario.

Evaluar deliberadamente los tipos de error

En DMARC, Hard failure significa que ni SPF ni DKIM se han validado con la alineación necesaria. La opción predeterminada es Conform to sender policy, por lo que el mensaje se trata conforme a la política DMARC del remitente. También se pueden seleccionar p=none, Unsupported, Temporary failure y Permanent failure. En este contexto, Unsupported solo se aplica al Gateway mode, mientras que M365 bestguesspass solo se aplica al M365 Mailflow mode. Una regla independiente para p=none resulta especialmente útil cuando Hard failure sigue configurado como Conform to sender policy.

En SPF, además de Hard failure, están disponibles Soft failure, Neutral, Unsupported, Temporary failure y Permanent failure. En DKIM, además de Hard failure, se ofrecen Unsupported, Temporary failure y Permanent failure. Un error temporal de DNS puede desaparecer sin intervención; un error permanente indica que el registro publicado no se puede interpretar. Ninguno de estos resultados debe considerarse automáticamente una prueba de suplantación.

Orden de procesamiento y Sender check

Las comprobaciones de Message Authentication se ejecutan en el orden indicado en la política. Para evaluar DMARC, Sophos realiza las comprobaciones SPF y DKIM necesarias con independencia de las acciones configuradas para sus errores. DMARC falla si ni SPF ni DKIM se validan con la alineación requerida. Si existen varias reglas de error, siempre se aplica la primera que coincida, siguiendo el orden de arriba abajo.

Si una regla de DMARC, SPF o DKIM coincide y su acción es Quarantine o Reject, se detiene el procesamiento de esa rama. Si las tres comprobaciones se superan en una configuración que utiliza estas acciones, no se siguen procesando las comprobaciones de anomalías de encabezado y el mensaje se entrega. Por tanto, el orden influye en el comportamiento de seguridad; no es una simple disposición visual en el portal.

En Sender check, Sophos añade dos comprobaciones de anomalías:

• Header anomaly protege sus propios dominios frente a la suplantación desde el exterior. Solo se activa cuando el dominio del encabezado From visible coincide con cualquiera de los dominios configurados en la cuenta de Sophos Fusion (antes Sophos Central) y esa dirección de encabezado es distinta de la dirección MAIL FROM del sobre SMTP. Se comprueban todos los dominios de la cuenta, no solo el dominio del destinatario.
• Domain anomaly detecta dominios de remitentes que no tienen ningún registro MX ni A.

Para ambas comprobaciones puede elegir Tag subject line, Quarantine, Reject o Deliver; la opción predeterminada documentada es Tag subject line. Durante la prueba piloto, utilice el etiquetado o la cuarentena y examine los reenvíos legítimos, los sistemas CRM, las plataformas de gestión de incidencias y los servicios de envío externos antes de activar Reject.

Configurar Smart Banners

En End-user message settings, active por separado cada tipo de banner, adapte el texto predefinido y elija las acciones que ofrecerá al usuario. La configuración se aplica a los mensajes externos entrantes, tanto HTML como de texto sin formato. Los mensajes de Sophos, como los resúmenes de cuarentena, no muestran un Smart Banner.

El color y el mensaje del banner dependen de la lista de permitidos y del resultado de DMARC:

• Trusted es verde: el remitente está en la lista de permitidos y el mensaje ha superado DMARC.
• External es amarillo: el remitente ha superado DMARC, pero no está en la lista de permitidos; está en esa lista, pero Trusted está desactivado; o no tiene ningún registro DMARC, por lo que no es posible determinar un resultado correcto o fallido.
• Untrusted es naranja: existe una política DMARC, pero el mensaje no ha superado DMARC.

Un banner sirve como ayuda para tomar decisiones, pero no demuestra que el mensaje sea inofensivo. Ni siquiera un banner verde sustituye el análisis del contenido ni la prudencia al abrir enlaces y archivos adjuntos.

Activar de forma segura las acciones del usuario

En cada banner puede ofrecer Allow sender, Block sender y Report Spam messages to Sophos. Allow y Block abren una página de confirmación y actualizan la lista personal del usuario; Report envía el mensaje a SophosLabs como spam.

La guía de excepciones Inbound Allow/Block explica cómo interactúan las entradas personales y globales y cómo protegerlas mediante autenticación, exportación, importación y reversión.

Para que Allow sender y Block sender funcionen en el banner HTML, abra Global Settings > Products and Services > Email > User Settings, active primero Release/Delete, después Allow/Block List, y guarde los cambios. Los enlaces de Allow y Block no están disponibles en los banners de texto sin formato.

El correo saliente debe pasar por Sophos Fusion cuando se utilicen enlaces de Smart Banners. Sophos recomienda configurar este enrutamiento antes de activar End-user message settings; de lo contrario, los destinatarios externos podrían ver el banner en respuestas o mensajes reenviados. En HTML, el banner aparece en color en la parte superior; en texto sin formato, aparece como texto al principio del cuerpo. Un banner existente puede seguir visible cuando se responde a un mensaje o se reenvía internamente.

Validar el resultado en Message History

Para cada ámbito de política relevante, envíe mensajes entrantes controlados a un destinatario piloto:

1. un mensaje legítimo que previsiblemente supere la autenticación;
2. un mensaje legítimo que pase por un servicio conocido de reenvío o envío;
3. si puede hacerlo de forma segura, un mensaje de su propio dominio de prueba con un error de autenticación provocado y documentado.

No falsifique correo de producción ni cambie los registros DNS de terceros para realizar una prueba. En Message History, busque por remitente, destinatario e intervalo de tiempo, abra el mensaje y compare la política aplicada, la categoría, los detalles de autenticación o de comprobación del remitente y la acción ejecutada. En los mensajes entregados, compruebe también el tipo, el texto, el color y las acciones visibles del banner, tanto en HTML como en texto sin formato. El resultado es correcto cuando los mensajes legítimos llegan a la siguiente fase de análisis o al buzón previsto, los errores activan la primera acción configurada que coincide y no aparecen acciones de usuario imprevistas.

Solucionar los problemas de forma metódica

• Error inesperado de DMARC o DKIM: Conserve los encabezados sin procesar y los detalles de la comprobación del remitente. Compruebe si una puerta de enlace previa, un aviso legal, una lista de correo o una ruta de reenvío modificaron el cuerpo o los encabezados firmados. En especial cuando Sophos EMS está detrás de otro sistema principal de seguridad del correo, los mensajes modificados pueden invalidar DKIM y la alineación DMARC; en ese caso, el error por sí solo no demuestra que exista un riesgo.
• Acción incorrecta pese a una regla coincidente: Compruebe primero el alcance, el estado de aplicación y el orden de las políticas; después, lea las reglas de error de arriba abajo. Una coincidencia general anterior puede ocultar una regla específica posterior.
• Header anomaly en un servicio legítimo: Compare el encabezado From visible con el MAIL FROM del sobre e identifique cuál de sus dominios ha coincidido. Corrija primero la configuración de envío o la alineación. Plantéese una excepción de autenticación de alcance muy limitado únicamente si no es posible corregirlas y el servicio está identificado de manera inequívoca.
• Domain anomaly en correo legítimo: Compruebe por separado la resolución de los registros MX y A del dominio remitente. No responda a un problema temporal de DNS con una regla de permiso global y permanente.
• No aparece el banner: Compruebe que estén activos la política y el tipo de banner correctos, que el mensaje sea externo y entrante, y que no se trate de un mensaje del sistema de Sophos.
• Allow/Block no aparece o falla: Compruebe Release/Delete y Allow/Block List en User Settings, el formato HTML y el enrutamiento saliente a través de Sophos. Estos enlaces no están disponibles en texto sin formato.

Solo después de este análisis debe modificar el orden, la acción o la entrada imprescindible más restrictiva en la lista de permitidos y repetir la misma prueba. Si el resultado sigue sin estar claro, recopile el Message-ID, la fecha y hora, el remitente, el destinatario, el nombre de la política, la acción ejecutada y todos los encabezados sin procesar para escalar el caso, en lugar de omitir de forma general la autenticación o la protección contra malware.