Por qué los correos electrónicos de simulación de phishing van a parar a la carpeta de spam (y cómo solucionarlo sin debilitar la seguridad)

Si tus correos de simulación de phishing van a parar a la carpeta de spam o a la cuarentena, es difícil confiar en tus resultados.

Una tasa de clics del 2 % podría significar que tus usuarios han mejorado. O podría significar que gran parte de la empresa nunca llegó a ver el mensaje. Eso no es solo un problema de informes. Es un problema de diseño del programa. Esta guía está dirigida a ingenieros de seguridad, administradores de TI, CISO y responsables de cumplimiento que necesitan una entrega fiable para las simulaciones sin abrir agujeros peligrosos en la seguridad del correo.

Nota de seguridad: este artículo trata sobre simulaciones defensivas y la medición de la concienciación. No incluye instrucciones para el phishing real, el robo de credenciales o eludir controles de seguridad con fines maliciosos.

La versión corta

Si los correos electrónicos de simulación de phishing van a parar a la carpeta de spam, la solución no suele ser «relajar los filtros hasta que todo llegue a la bandeja de entrada».

El enfoque más seguro es:

• utilizar un dominio o subdominio dedicado a la simulación
• hacer que la alineación de SPF, DKIM y DMARC sea intencionada
• mantener limpios el contenido y las cadenas de redireccionamiento
• distinguir la telemetría de entrega de la telemetría de comportamiento de los usuarios
• y, cuando sea necesario, utilizar listas de permitidos muy específicas en lugar de omisiones generales

Este último punto es importante. Las listas de permitidos generales son arriesgadas. Pero las reglas específicas y bien documentadas vinculadas a una IP de envío dedicada y a identidades de remitente conocidas pueden ser un control a largo plazo perfectamente razonable.

Por qué falla la entregabilidad de la simulación de phishing

Los fallos de entregabilidad rara vez son aleatorios. Suelen ser el resultado previsible de cómo se configuró el programa.

1) SPF, DKIM o DMARC no están alineados con el remitente visible

Esta es la causa más común.

Si el dominio que ven los usuarios en el campo De no coincide con el dominio autorizado por SPF o firmado por DKIM, los sistemas de correo tienen motivos para sospechar. Tanto Microsoft como Google tratan SPF, DKIM y DMARC como señales fundamentales de confianza del remitente, y ambos hacen hincapié en la coincidencia con el dominio del remitente visible.

Patrones de fallo habituales:

• el dominio visible en el campo De no es el dominio que realmente has autenticado
• Falta la firma DKIM o está asociada al dominio equivocado
• Existe DMARC, pero nunca se comprobó correctamente la coincidencia con el remitente visible
• Se realizaron cambios en el DNS, pero no se propagaron ni validaron por completo antes del lanzamiento de la campaña

2) La simulación utiliza el dominio corporativo principal

Usar el dominio principal de la empresa puede parecer realista, pero a menudo crea conflictos innecesarios.

Acabas probando contra los mismos controles antisuperstiación, de suplantación de identidad y contra el abuso que existen para proteger ese dominio en producción. Eso puede ser adecuado en algunos programas maduros, pero rara vez es el mejor punto de partida.

Para la mayoría de los equipos, un subdominio de simulación dedicado es la opción predeterminada más segura.

3) Se utilizó un tipo incorrecto de lista de permitidos

Las listas de permitidos pueden convertirse en un problema de seguridad, especialmente cuando los equipos hacen cosas como:

• eludir la protección contra el phishing de forma global
• incluir en la lista de permitidos enormes rangos de IP de proveedores de nube
• eximir a infraestructuras de remitentes enteras que no controlan
• saltarse el análisis de amplias categorías de correo

Pero ese no es el único modelo.

Hay una gran diferencia entre eludir de forma generalizada y aplicar reglas de entrega precisas. Si tu proveedor envía desde una IP dedicada y un conjunto pequeño y conocido de direcciones o dominios de remitentes, una lista de permitidos de alcance limitado puede ser aceptable e incluso puede mantenerse como parte de la configuración estándar. Los propios documentos de guía de configuración de AutoPhish describen exactamente ese modelo: las campañas se envían desde un servidor SMTP/IP dedicado y un conjunto definido de direcciones de remitente, lo que hace factibles excepciones de filtrado precisas sin recurrir a ese tipo de omisiones excesivas que crean una exposición real.

4) El contenido y los enlaces activan los mismos controles que esperas que los usuarios confíen

Los correos de simulación suelen contener:

• enlaces de seguimiento
• redireccionamientos
• lenguaje de urgencia
• frases propias de una marca
• llamadas a la acción tipo «iniciar sesión»

Eso no es automáticamente incorrecto. Pero sí significa que el correo será inspeccionado como si fuera sospechoso. Si la simulación depende de parecer lo suficientemente sospechosa como para burlar tus propios controles, ya no estás probando realmente a los usuarios. Estás probando si tu sistema de seguridad detecta contenido obviamente arriesgado.

5) Los datos de entrega y los datos de comportamiento se mezclan

Si no puedes separar claramente:

• enviado
• entregado
• abierto
• clicado
• denunciado

entonces tus informes te llevarán a conclusiones erróneas. Una métrica de campaña débil puede reflejar un problema del usuario. O un problema de enrutamiento. O una política de cuarentena. O un problema de filtrado específico del proveedor de correo. Esas son vías de solución muy diferentes.

Una forma más segura de mejorar la capacidad de entrega de las simulaciones de phishing

Paso 1: Separa el envío de simulaciones del correo electrónico empresarial normal

Para la mayoría de las organizaciones, el mejor punto de partida es:

• un dominio o subdominio dedicado a las simulaciones
• registros de autenticación dedicados
• una ruta de envío limpia que sea fácil de explicar y auditar
• ninguna suplantación de identidad de personas internas reales a menos que haya una razón sólida y revisada

Esto reduce el alcance del impacto, minimiza la confusión y facilita mucho la resolución de problemas.

Paso 2: Valida la autenticación antes de la primera campaña

Antes de llegar a la conclusión de que «Microsoft nos está bloqueando» o «Google es demasiado agresivo», comprueba lo básico:

• El SPF incluye solo la infraestructura que debe enviar el correo de simulación
• El DKIM está habilitado y firma de forma fiable
• El DMARC está publicado y alineado con el dominio del remitente visible
• Los mensajes de prueba muestran realmente los resultados de autenticación que esperabas

Para un repaso independiente de proveedores, la descripción general de Microsoft sobre la autenticación de correo electrónico es una referencia útil, y la guía para remitentes de Google plantean lo mismo: una entrega fiable empieza por una autenticación limpia y la alineación del dominio.

Si utilizas AutoPhish, el artículo de ayuda sobre la entrega de correos de campaña y la comprobación de DNS son buenos puntos de partida durante la configuración.

Paso 3: Usa listas de permitidos selectivas cuando sea necesario, no exenciones generales

Esta es la parte que muchos equipos realmente necesitan.

Una buena excepción es:

• específica
• documentada
• revisable
• fácil de explicar a los auditores
• vinculada a una identidad de remitente conocida o a una IP de envío dedicada
• lo suficientemente específica como para no confiar accidentalmente en tráfico no relacionado

Una mala excepción es «cualquier cosa de este proveedor está bien». Una excepción mejor es «el correo de simulación procedente de esta IP dedicada y este conjunto de remitentes definido debe entregarse de forma consistente para este programa de concienciación». Esa distinción importa.

En la práctica, la postura más defendible suele ser:

• mantener el escaneo normal siempre que sea posible
• evitar reglas globales de «saltar el filtrado»
• preferir reglas específicas basadas en remitentes/IP en lugar de la confianza a nivel de toda la infraestructura
• documentar exactamente por qué existe la regla y qué cubre
• revísala periódicamente, pero no des por sentado que debe ser temporal si su alcance sigue siendo limitado y sigue encajando en tu modelo de control

Con AutoPhish, ese modelo es factible porque las campañas se envían desde una IP dedicada y una huella de remitente conocida, en lugar de desde un enorme grupo de correo compartido.

Paso 4: Diseña simulaciones para enseñar a reconocer, no para luchar contra la puerta de enlace

Las mejores simulaciones de phishing no necesitan «ganarle» a todos los controles de seguridad.

Deben ayudarte a evaluar si las personas:

• detectan señales sospechosas
• evitan acciones de riesgo
• informan rápidamente de los mensajes sospechosos
• mejoran con el tiempo

Ese es un objetivo de diseño más sensato que intentar que cada correo parezca indistinguible de un ataque real en la capa de filtrado.

Paso 5: Crea informes que distingan los problemas de correo de los problemas de las personas

Un programa maduro debería poder responder a:

• ¿Cuántos mensajes se entregaron realmente?
• ¿Qué proveedor o política los filtró?
• ¿Qué departamentos tuvieron menos visibilidad?
• ¿Los usuarios denunciaron el mensaje?
• ¿Mejoraron esos mismos usuarios con el tiempo?

Eso es lo que convierte las simulaciones de «un montón de correos falsos» en algo útil desde el punto de vista operativo.

Si quieres ese tipo de estructura, los informes son tan importantes como el contenido. Consulta: Informes de simulaciones de phishing: 12 características que los equipos de seguridad deberían comparar.

Cómo es una «buena» lista de permitidos

Una buena regla debe ser lo suficientemente específica como para que tu equipo de seguridad pueda trabajar con ella y tus auditores puedan entenderla.

Esto suele significar que:

• se limita a la infraestructura de envío de simulaciones
• está vinculada a dominios conocidos, identidades de remitentes o una IP dedicada
• no confía en el correo no relacionado procedente del mismo proveedor general
• no establece una condición general de «entregar siempre, no escanear nunca» a menos que haya una razón de peso
• se supervisa como parte del diseño del programa de concienciación, no como una solución alternativa oculta

Aquí es también donde la arquitectura del proveedor cobra importancia. Si una plataforma envía desde un grupo compartido que usan muchos clientes, se hace más difícil justificar una lista de permitidos a largo plazo. Si envía desde una IP dedicada con una superficie de remitentes pequeña y documentada, una lista de permitidos más restringida se vuelve mucho más fácil de defender.

Una lista de verificación rápida cuando los correos de simulación de phishing van a la carpeta de spam

Usa esta lista de verificación cuando tus resultados parezcan sospechosos.

Autenticación e identidad del remitente

• ¿El dominio «De» visible es el que pretendías usar?
• ¿Están SPF, DKIM y DMARC alineados con ese dominio?
• ¿Ha cambiado algo recientemente en el DNS o en la configuración de envío?
• ¿Muestran los encabezados de prueba los resultados que esperabas?

Arquitectura de envío

• ¿Estás utilizando un subdominio de simulación dedicado?
• ¿Está la infraestructura de envío aislada del correo de producción?
• ¿Es estable el historial de reputación del remitente?
• ¿Dependes de un grupo de remitentes compartido o de una IP dedicada?

Reglas y excepciones

• ¿Alguien ha creado una excepción general para que «simplemente funcione»?
• ¿Se podría restringir la regla a identidades de remitente exactas o a una IP dedicada?
• ¿Está documentada y se puede revisar la excepción?
• ¿Sigues analizando siempre que sea posible?

Contenido y medición

• ¿Son las URL limpias y predecibles?
• ¿Hay cadenas de redireccionamiento innecesarias?
• ¿Mides la entrega por separado de la interacción?
• ¿Estás haciendo un seguimiento de la tasa de denuncias y el tiempo hasta la denuncia, y no solo de los clics?

Preguntas frecuentes

¿Deberíamos incluir en la lista blanca los correos de simulación de phishing?

A veces sí.

Lo que quieres evitar es la confianza generalizada. Lo que suele ser aceptable es la confianza limitada: una IP de envío dedicada, identidades de remitentes conocidas, un propósito claramente documentado y ninguna excepción excesivamente amplia que debilite el resto de tu seguridad de correo.

¿Deberían ser temporales esas reglas?

No necesariamente.

Las excepciones generales de emergencia deben ser temporales. Pero las reglas precisas y bien delimitadas pueden mantenerse si forman parte del modelo operativo aprobado, siguen siendo lo suficientemente específicas y se revisan periódicamente.

¿Podemos realizar simulaciones desde nuestro dominio corporativo principal?

Puedes hacerlo, pero suele suponer más complicaciones y un mayor riesgo.

Un subdominio dedicado a la simulación es más fácil de autenticar, más fácil de explicar y menos propenso a entrar en conflicto con tus controles de producción contra la suplantación de identidad y el spoofing.

¿Una mejor capacidad de entrega reduce el realismo?

No.

Las buenas simulaciones miden el comportamiento de reconocimiento y notificación. No necesitan una infraestructura descuidada ni omisiones inseguras para ser útiles.

¿Cómo demostramos que los resultados son fiables?

Documenta ambos lados del sistema:

1. lo que se suponía que debía entregarse
2. lo que los usuarios hicieron realmente tras la entrega

Eso es mucho más defendible que mostrar un gráfico de tasa de clics sin contexto de entrega.

¿Listo para ejecutar simulaciones que midan la resiliencia en lugar de accidentes en el flujo de correo?

AutoPhish está diseñado para equipos que quieren simulaciones seguras, informes que respetan la privacidad y pruebas fáciles de auditar sin una gran carga operativa.

Si necesitas orientación precisa para la configuración, consulta nuestro artículo de ayuda sobre cómo asegurarte de que los correos de campaña se reciban correctamente.

Regístrate

Crédito de la imagen: Foto de Krsto Jevtic en Unsplash.