La sanidad francesa frente a la suplantación de correo

Qué recoge el barómetro, y cómo

El apartado de sanidad del barómetro del Observatorio DMARC sigue un corpus de dominios de instituciones sanitarias francesas — hospitales universitarios y generales, grupos de clínicas, redes de laboratorios — y los recoge en el DNS público. El método no tiene nada de intrusivo: lee lo que cualquier resolutor ve. El registro TXT colocado en _dmarc.ejemplo.es, la política p= que declara, la suerte de los subdominios, el registro SPF y su rigor, los indicios públicos de DKIM y de BIMI.

Cada dominio se clasifica según su política efectiva: reject (la suplantación se rechaza), quarantine (va a la carpeta de spam), none (vigilancia sin bloqueo), registro ausente, o inválido — un solo error de sintaxis basta para privar a una política de todo efecto. La lectura se rehace cada mes, lo que produce dos cosas que una foto aislada nunca da: una clasificación a fecha y una trayectoria — quién progresa, quién se estanca, quién retrocede.

La jerarquía útil se lee así: ausente < inválido < none < quarantine < reject. Un registro en p=none:

v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.es

no bloquea estrictamente nada — es un modo de escucha, indispensable para empezar, sin valor defensivo alguno. Un dominio hospitalario en p=none sigue siendo suplantable exactamente como si no tuviera DMARC; la única diferencia es que las tentativas aparecen en sus informes.

Un principio firme se deriva del ritmo mensual: este artículo no cita ningún porcentaje. Una cifra impresa aquí sería falsa seis meses después y seguiría, sin embargo, leyéndose. El reparto por estado, la clasificación por institución y la evolución mensual viven en la edición mensual, actualizada en cada lectura — es ella la que da fe.

Los patrones estructurales del corpus sanitario

Sin copiar las cifras del mes, cuatro patrones estructurales reaparecen en este corpus — y señalan los frentes de trabajo reales.

Los grandes hospitales universitarios relativamente por delante. Las instituciones más visibles suelen ser las mejor mantenidas: un equipo de seguridad identificado, auditorías regulares, una exposición mediática que prohíbe la negligencia. «Relativa» sigue siendo la palabra justa: la delantera se manifiesta a menudo por la presencia de un registro y de una vigilancia, todavía no por una política endurecida en todo el perímetro.

La cola larga. Detrás del pelotón de cabeza, la distribución se estira: hospitales medianos a mitad de camino, estructuras pequeñas sin registro alguno, residencias ajenas al asunto. La media de un corpus así no dice casi nada; la forma de la distribución lo dice todo, y es esa forma la que la edición mensual hace visible.

Múltiples dominios por institución. Un mismo hospital acumula a menudo un dominio histórico, el dominio de la agrupación, dominios por centro o por actividad — reclutamiento, fundación, eventos. El atacante elige la puerta menos vigilada: una política estricta en el dominio principal protege mal a una institución cuyo dominio de reclutamiento, el que escribe espontáneamente a candidatos, permanece en none. Los dominios latentes — antiguas identidades, fusiones pasadas — se cierran, sin embargo, con dos registros: un SPF v=spf1 -all y un DMARC p=reject. Es el frente menos costoso de todo el sector.

Registros inválidos. El DNS hospitalario ha atravesado a menudo varios proveedores y varias fusiones; conserva las cicatrices — registros duplicados, sintaxis defectuosa, una dirección de informe huérfana. Una política inválida equivale a una ausencia, y solo una lectura regular la detecta.

El estándar vigente, DMARCbis (RFC 9989 a 9991), afina la lectura de estas lecturas: la etiqueta pct ha desaparecido en favor del modo de prueba t=y, el descubrimiento de política sigue el DNS Tree Walk, y la etiqueta np= cubre los subdominios inexistentes — objetivo favorito de las suplantaciones «técnicas». La cabecera v=DMARC1 sigue siendo retrocompatible. Una política madura para un dominio hospitalario se parece a:

v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.es; sp=reject; np=reject

Alojamiento de datos de salud, el programa CaRE, NIS2: un marco que empuja en el mismo sentido

El sector no avanza solo: tres marcos empujan, cada uno a su manera, hacia el correo autenticado.

La certificación de alojamiento de datos de salud regula el almacenamiento de esos datos: una institución o su proveedor debe confiar esos datos a un alojador certificado. Es una base necesaria, pero no dice nada del canal de correo: un hospital puede ser irreprochable en el alojamiento de su historia clínica y dejar su dominio libremente suplantable. Los dos asuntos están separados, y el segundo quedó mucho tiempo en el punto ciego.

El programa CaRE, lanzado a finales de 2023 para acelerar la ciberseguridad de las instituciones sanitarias, cambió las cosas: financiación dirigida, auditorías de la superficie expuesta en internet, ejercicios de crisis. La protección de los dominios — DNS, autenticación del correo — entra naturalmente en ese movimiento, porque marca las dos casillas del programa: poco costosa, de efecto inmediato.

NIS2, en fin, incorpora a una parte de los actores de la sanidad al perímetro de las entidades esenciales: gestión de riesgos documentada, medidas de protección proporcionadas, notificación de incidentes. La directiva no cita DMARC por su nombre — como la mayoría de los textos, impone un resultado, no un medio. Pero un dominio dejado en p=none pese a informes que muestran el abuso se convierte en una posición difícil de defender ante un auditor o una autoridad.

A ello se añade una presión sin texto legal: desde 2024, Gmail y Yahoo exigen una autenticación de los remitentes en volumen, y Microsoft siguió en 2025. Recordatorios de cita que ya no llegan son consultas perdidas — la entregabilidad es aquí un asunto de salud pública antes que un asunto de marketing.

Remediar con los medios de un departamento informático hospitalario

La remediación DMARC de una institución sanitaria no puede pensarse como la de un banco: sin equipo dedicado, con guardias ya saturadas, un sistema de información donde la historia clínica pasará siempre por delante del DNS. El enfoque debe tenerlo en cuenta — y es posible, porque DMARC se presta bien al esfuerzo discontinuo.

La primera etapa no entraña ningún riesgo: publicar p=none con una dirección de informe y dejar que los datos se acumulen. Ningún mensaje se bloquea, el inventario se construye solo — la mensajería de la institución (a menudo Microsoft 365 o un alojamiento compartido), la plataforma de cita previa, las herramientas de nómina y de recursos humanos, los boletines institucionales, los servidores de resultados. Cada fuente identificada se alinea después — SPF, DKIM — sobre la marcha, entre dos urgencias.

El segundo gesto es el cierre de los dominios que no emiten nada: unos minutos por dominio, una ganancia definitiva. El tercero es el endurecimiento por escalones del dominio principal — quarantine y luego reject, apoyándose en el modo de prueba t=y de DMARCbis para jalonar la subida. En cada escalón, los informes dicen si un flujo legítimo se vería afectado antes de que lo sea realmente.

El factor limitante casi nunca es la técnica, es el tiempo de análisis: informes XML en bruto, nadie los leerá en el hospital. La explotación con herramientas — agregación, identificación de las fuentes, alertas — reduce el asunto a unas pocas decisiones al mes, un formato compatible con un departamento informático compartido. El recorrido completo del asunto para el sector, proveedores y software de gestión incluidos, está balizado en la guía dedicada al correo de las instituciones sanitarias.

La suplantación de un dominio sanitario es un riesgo para el paciente

Queda por nombrar lo que de verdad distingue a este corpus de todos los demás: la naturaleza del riesgo. La suplantación de un dominio bancario roba dinero; el barómetro de los bancos franceses muestra un sector que lo comprendió hace tiempo, empujado por el fraude y por su regulador. La suplantación de un dominio sanitario, en cambio, alcanza a las personas en el momento en que son vulnerables.

Un falso mensaje de resultados que redirige a un portal falsificado recoge identidades completas. Una falsa anulación de consulta retrasa una atención. Una falsa factura de estancia desvía el pago de una familia. Un falso mensaje de la dirección a un profesional sanitario abre la puerta del sistema de información — y se vuelve a caer en el escenario del ransomware, el que desprograma quirófanos. En cada uno de estos escenarios, el dominio suplantado es el instrumento, y la víctima final no es la institución: es el paciente.

Por eso la protección del dominio pertenece a la seguridad de la atención igual que la higiene de las manos — una medida de prevención poco costosa cuya ausencia solo se ve en el momento del incidente. Los mecanismos por los que un dominio no protegido acaba explotado, y las contramedidas en el orden útil, se detallan en impedir el phishing en nombre de un dominio.

En resumen

La sanidad francesa acumula todo lo que atrae la suplantación: datos irrevocables, una dependencia vital de la continuidad del servicio, una superficie humana bajo tensión — y un paisaje de una heterogeneidad extrema, del hospital universitario auditado a la residencia sin informático. La postura DMARC de este paisaje se mide en el DNS público, dominio a dominio; la lectura útil no es «tener un registro» sino «aplicar una política», y p=none no ha bloqueado jamás una sola suplantación. Los patrones estructurales — hospitales universitarios relativamente por delante, cola larga, dominios múltiples y latentes, registros inválidos — señalan frentes cuyo primero no cuesta casi nada. El alojamiento de datos de salud, CaRE y NIS2 empujan en la misma dirección, cada uno por su palanca. Las cifras del mes, por su parte, viven en la edición mensual del Observatorio, actualizada lectura tras lectura.

La prolongación cabe en dos gestos. Un paso del dominio de una institución por el analizador en línea sitúa en segundos su posición en la misma escala que el barómetro — presencia, validez, política efectiva, subdominios. Y crear una cuenta abre el seguimiento continuo, con los informes agregados de apoyo, para llevar la política hacia p=reject al ritmo que un departamento informático hospitalario puede sostener de verdad.