Ciberseguro: qué miran las aseguradoras en el correo

p=reject: el riesgo asegurado se reduce mecánicamente

Un contrato de seguro cubre una esperanza de pérdida. Todo control que reduce la probabilidad o la gravedad de un incidente reduce el riesgo transferido a la aseguradora — es la materia prima de la tarificación. Y DMARC en aplicación estricta actúa exactamente ahí. Cuando un dominio publica

_dmarc.ejemplo.es.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.es"

los servidores receptores que aplican la política rechazan cualquier mensaje que se reclame de ejemplo.es sin autenticación alineada. La suplantación del dominio exacto —el falso correo del directivo enviado «desde» la dirección real, dirigido a la propia contabilidad de la empresa o a sus clientes— deja de ser una opción para el atacante. Todo un tramo del fraude del CEO se vuelve bloqueable por construcción, antes de cualquier juicio humano, antes de cualquier filtro heurístico.

La honestidad obliga a trazar el perímetro exacto: DMARC no detiene ni los dominios gemelos, ni los nombres visibles engañosos, ni las cuentas legítimas comprometidas —tres vectores que exigen otras defensas (registros defensivos, filtrado, MFA, procedimiento de contrallamada antes de cualquier cambio de cuenta bancaria)—. Las aseguradoras lo saben, y por eso precisamente la pregunta DMARC se suma a las demás en lugar de sustituirlas. Pero en el paisaje de los controles antifraude, este ofrece una relación coste-eficacia difícil de batir: una línea de DNS, oponible al mundo entero.

El DNS público habla: la suscripción se escanea

Un hecho poco conocido por los asegurados: una parte del cuestionario se verifica sin preguntar nada a nadie. El registro DMARC es un registro DNS público —una consulta dig TXT _dmarc.ejemplo.es basta para leerlo, y lo mismo vale para SPF—. Corredores y portadores de riesgo se apoyan ya en herramientas de calificación externa que escanean automáticamente la superficie expuesta de los candidatos al seguro: puertos abiertos, certificados, servicios obsoletos… y la política DMARC. El resultado llega a la mesa del suscriptor antes incluso que el cuestionario cumplimentado.

Las consecuencias son muy concretas. Una respuesta que declara «autenticación del correo en marcha» cuando el DNS muestra p=none —o ningún registro en absoluto— crea una contradicción visible entre lo declarado y lo observado, con el peor efecto posible sobre cómo se juzga la fiabilidad general del expediente. A la inversa, un dominio en p=reject, coherente y limpiamente configurado, habla a favor del candidato sin que se pronuncie una palabra: el control se constata en lugar de declararse. Algunos actores integran explícitamente estas señales externas en la evaluación del riesgo, y la brecha entre declaración y realidad observable se convierte en un criterio por sí misma.

Una casilla marcada de más puede costar cara en el siniestro

El seguro descansa sobre un principio declarativo: el contrato se tarifica y se concede sobre la fe de las respuestas dadas en la suscripción. Una casilla marcada de más —«DMARC en aplicación» cuando el dominio seguía en p=none, «MFA generalizado» cuando un acceso quedaba fuera— no es un detalle administrativo. Según el derecho nacional y la redacción de las cláusulas, una declaración inexacta puede fundar una reducción proporcional de la indemnización, o incluso una denegación de cobertura en el momento preciso en que la empresa más la necesitaría. Litigios públicos en torno a siniestros ciber han girado ya exactamente sobre ese terreno: si las respuestas de suscripción se ajustaban a la realidad.

Nada de esto constituye un consejo jurídico —cada contrato merece su propia lectura—, pero la regla prudente es simple y técnica: declarar el estado real, fechado, y mantenerlo al día. «DMARC publicado en p=none, paso a p=reject previsto para el próximo trimestre» es una respuesta honesta y a menudo bien recibida, porque acredita un programa pilotado. La versión optimista de la misma casilla, en cambio, se vuelve contra el declarante el día en que el perito del siniestro compara el cuestionario con el DNS histórico —porque el DNS se archiva, y los escáneres guardan memoria de los estados pasados—.

Preparar el expediente: estado, trayectoria, pruebas

Ante un cuestionario o una renovación, el capítulo de correo del expediente se prepara como un expediente de auditoría, con tres piezas.

El estado, primero: un inventario exacto de los dominios de la organización —activos, pero también defensivos y durmientes, que los escáneres ven igual— con, para cada uno, el estado SPF, DKIM y DMARC constatado en el DNS. Un dominio durmiente sin política es una puerta abierta con el nombre de la empresa; neutralizarlo (SPF v=spf1 -all, DMARC p=reject) lleva minutos y mejora el perfil de conjunto.

La trayectoria, después: para los dominios aún en camino, la progresión documentada de p=none hacia p=reject, con la fecha de cada etapa. El paso por p=quarantine, o el modo de prueba t=y introducido por DMARCbis, muestra una subida en aplicación controlada en lugar de un statu quo prolongado.

Las pruebas, por último: la recopilación efectiva de los informes agregados, alertas sobre las fuentes desconocidas, un rastro de explotación —revisiones periódicas, tickets, un diario de auditoría—. Es exactamente la lógica de evidencia de un sistema de gestión de la seguridad, desarrollada en DMARC en un programa ISO 27001: un control sin prueba de funcionamiento vale poco más que un control ausente, a ojos de un auditor igual que de un suscriptor.

Más allá de la prima: reducir el riesgo real

Sería una lástima reducir la autenticación del correo a un ejercicio de cumplimiento asegurador. La casilla del cuestionario no es más que el reflejo de una realidad más interesante: p=reject no se limita a tranquilizar a un suscriptor, elimina de verdad un vector de ataque —el más humillante de todos, el que vuelve el nombre exacto de la empresa contra sus propios equipos, sus clientes y sus proveedores—. La prima eventualmente suavizada es un bono; el fraude que nunca ocurre es la ganancia principal.

La ecuación económica sigue siendo favorable mucho más allá del seguro. El coste de un programa DMARC completo —el desglose detallado está en lo que cuesta realmente un servicio DMARC— no guarda proporción con un solo fraude por transferencia consumado, ni siquiera con el aumento de franquicia que sigue a un siniestro. Se añaden los beneficios colaterales: una entregabilidad reforzada desde que Gmail y Microsoft exigen la autenticación a los remitentes de volumen, una marca protegida y una señal de seriedad legible por cualquier socio que se tome la molestia de consultar el DNS.

En resumen

El fraude por transferencia domina la siniestralidad ciber, el correo es su vector, y los cuestionarios de suscripción han sacado las consecuencias: junto al MFA, las copias de seguridad y el EDR, la autenticación del dominio —SPF, DKIM y sobre todo la política DMARC— se ha convertido en pregunta estándar. p=reject reduce mecánicamente una parte del riesgo asegurado al volver bloqueable la suplantación del dominio exacto; el DNS público permite a las aseguradoras verificar las respuestas sin preguntar; y el principio declarativo hace peligrosa cualquier casilla marcada con optimismo. Un buen expediente cabe en tres piezas —un estado exacto, una trayectoria fechada, pruebas de explotación— y el control, una vez en marcha, protege mucho más allá de la prima.

Antes del próximo cuestionario, el reflejo útil no cuesta nada: un análisis DMARC gratuito del dominio muestra en segundos lo que el suscriptor verá desde el otro lado —política publicada, alineación SPF y DKIM, puntos débiles restantes—. Y para transformar esa foto en una trayectoria documentada hacia p=reject, con los informes como respaldo, crear una cuenta permite fechar cada etapa — hasta la casilla que ya nadie dudará en marcar.