Resumen
LetsDMARC muestra fallos que llegan de servicios de seguridad del correo y de servidores de reenvío que pertenecen a tus destinatarios. Detrás de esos fallos hay copias de mensajes que tú enviaste correctamente y que otra parte entregó una segunda vez. El fallo no lo causan tus sistemas ni es un error de LetsDMARC, y no es motivo para retrasar el paso a la política reject.
Antes de empezar
- Acceso al panel de LetsDMARC para el dominio que estás mirando.
- La lista de las fuentes que envían realmente correo en nombre de tu dominio, por ejemplo tu pasarela, tu tenant, tu plataforma de marketing y tu sistema de tickets.
- El estado actual de DKIM de cada una de esas fuentes.
Cómo funciona
Tu mensaje sale de la pasarela y supera SPF, DKIM y DMARC en la primera entrega. El servidor que lo recibe lo acepta, y esa es la entrega que cuenta para ti y para tu destinatario.
Muchos destinatarios mueven después el mensaje una segunda vez. Su servidor lo pasa a un servicio de seguridad externo mediante un conector, una regla de transporte o una API, o bien una regla del buzón lo reenvía a otra dirección. En ambos casos el mensaje se entrega de nuevo, y esa segunda entrega parte de una dirección IP que pertenece al servicio o al servidor que reenvía.
Esa dirección no está en tu registro SPF, así que SPF falla, y es correcto que falle, porque nunca autorizaste a ese host a enviar correo por tu dominio. Si el servicio además modifica el mensaje, por ejemplo añadiendo un aviso en el texto, reescribiendo los enlaces o cambiando el asunto, también se rompe la firma DKIM. Sin SPF ni DKIM alineados, DMARC falla.
El sistema que recibe esta segunda copia envía un informe agregado a tu dominio, porque el dominio de la cabecera From sigue siendo el tuyo. LetsDMARC lee ese informe y muestra el fallo con el nombre del servicio como fuente.
Síntomas
En la página DMARC reports by sources ves fallos de nombres de host que no reconoces y que nunca configuraste. Aparecen también en el recuadro Top 5 failure sources, y ahí suele empezar la pregunta. La lista completa está en la tabla grande Details al final de la página, con una fila por cada fuente que ha enviado correo con tu dominio en la cabecera From.
Los nombres de fuentes observados hasta ahora son cloud-sec-av.com, inkyphishfence.com, perception-point.io, shield.security, ppe-hosted.com, mimecast.com, sonicwall.com y oraclecloud.com. La lista sigue creciendo, porque depende del producto que haya comprado cada uno de tus destinatarios.
Estas fuentes muestran un cumplimiento cercano a cero, con SPF y DKIM ambos a cero, mientras que tus propias plataformas de envío se mantienen en el noventa y nueve o cien por cien. Su volumen es una parte pequeña de tu tráfico total.
Cuatro señales juntas te dicen que estás ante este caso.
| Qué mirar | Qué ves en este caso |
|---|---|
| Fuente | Un servicio de seguridad del correo conocido, o un servidor que reenvía el correo de un destinatario |
| Header From | El mismo dominio que usan tus fuentes legítimas, porque el mensaje es una copia del tuyo |
| Forwarded | A menudo un valor por encima de cero. LetsDMARC lo calcula por su cuenta y no siempre llega al cien por cien: a veces es más bajo y a veces se queda en cero incluso con un servicio que reenvía con seguridad. Léelo como un indicio, no como una prueba |
| Volumen | En línea con tu tráfico normal hacia ese destinatario, sin picos repentinos |
Causa
El fallo lo genera quien realiza la segunda entrega. No lo generan tus servidores, que en la primera entrega hicieron su trabajo correctamente, y no es un error de LetsDMARC, que solo muestra los informes que recibe de los sistemas que recibieron esa segunda copia.
En tu lado no hay nada roto. No existe ningún ajuste, ni en tu DNS, ni en tu pasarela, ni en LetsDMARC, que convierta estos fallos en superados, porque la entrega que falla la hace un host que no es tuyo y que no puedes controlar.
Solución
- Abre la tabla grande Details al final de la página y mira la fuente que falla. Si es un servicio de seguridad del correo o un servidor de reenvío de uno de tus destinatarios, no hay nada que hacer.
- No intentes hacer que esos fallos pasen. Intentar arreglarlos es el único camino que lleva a un cambio peligroso, y lo correcto es no contarlos cuando valoras el estado de tu dominio.
- No añadas nunca las direcciones IP ni el include SPF de estos servicios a tu propio registro SPF.
- Asegúrate de que cada fuente legítima tuya firme con una clave DKIM alineada. Una firma intacta sobrevive a un reenvío simple, así que una parte de estas segundas entregas todavía puede superar DMARC solo con DKIM.
- Pasa a la política reject cuando tus fuentes legítimas sean conformes. Estos fallos por sí solos no son motivo para esperar.
Añadir el servicio de seguridad de un destinatario a tu registro SPF es el único cambio que empeora las cosas, porque desde ese momento cualquiera que use esa plataforma puede enviar correo con tu dominio y superar SPF.
Comprobar el resultado
Filtra la tabla Details por tus propias fuentes de envío y comprueba que cada una sea conforme, con SPF o DKIM alineado. Ese es el número que decide si estás listo para reject.
Después mira otra vez las fuentes que fallan. Si todas son servicios de seguridad o servidores que reenvían, y el volumen se mantiene en línea con tu tráfico normal, tu dominio está en buen estado aunque el contador de fallos siga subiendo.
Limitaciones conocidas
- Tu primera entrega no se ve afectada nunca. El mensaje que envías supera DMARC, así que la política reject no le afecta, no se bloquea y no cuenta como fallo. Los fallos que ves corresponden solo a la segunda entrega.
- Lo que le ocurre a la segunda copia no se puede prever desde tu lado. Depende de cómo haya configurado el servicio el destinatario, de lo que el servicio haga con el mensaje y de qué sistema tome la decisión final, y un servicio mal configurado puede hacer que esa copia se rechace.
- SPF no puede sobrevivir a la segunda entrega, porque el mensaje sale de un host que no has autorizado. SPF está diseñado para funcionar así.
- DKIM sobrevive a un reenvío simple, pero se rompe en cuanto el servicio modifica el mensaje.
- Estos informes seguirán llegando mientras tus destinatarios usen esos servicios. No puedes detenerlos desde tu lado.