El 7 de septiembre de 2026 consultamos los registros DNS públicos de 219 dominios de correo de grandes compañías españolas repartidas en ocho sectores, de la banca a la construcción. Tres de cada cuatro tienen una política DMARC de bloqueo, pero solo el 38 % ha llegado a p=reject. El 27 % sigue sin protección, repartido entre un 7 % que no publica registro y un 20 % en p=none, y uno de cada cinco registros SPF está a tres consultas DNS o menos de dejar de funcionar.
Publicar DMARC con la política p=none no impide a nadie enviar correo en nombre de tu dominio: solo pide a los servidores que lo reciben que te informen de lo que ven. Es un medidor, no un control.
Las grandes compañías del país están muy por delante de la media mundial de dominios, que mezcla empresas de todos los tamaños: según el informe de adopción 2026 de EasyDMARC, sobre los 1,8 millones de dominios más relevantes, el 52,1 % publica un registro DMARC y solo alrededor del 9 % combina una política de bloqueo con los informes que permiten saber qué se bloquea. El problema en España no es el arranque, es el último tramo.
En Hard2bit revisamos SPF, DKIM y DMARC en cada auditoría de Microsoft 365 y en el escáner de superficie de ataque pública, y en las empresas medianas casi siempre encontramos la misma escena: hay registro DMARC, la política es none y los informes llegan a un buzón que nadie abre. El escaneo de las grandes muestra que una buena parte ya pasó esa fase y se ha quedado en la siguiente: cuarentena sin dar el paso final.
¿Qué encontramos en 219 dominios de grandes empresas españolas?
La muestra son grandes empresas de ocho sectores elegidas con criterios públicos: cotizadas en BME, entidades con licencia del Banco de España o de la Dirección General de Seguros, universidades privadas y las mayores compañías por facturación de cada sector según rankings publicados. De 233 dominios candidatos se escanearon los 219 que reciben correo.
Todas las comprobaciones son lecturas de registros DNS públicos, los mismos que consulta cualquier servidor al recibir un mensaje, y los resultados se publican solo agregados por sector, con un mínimo de 23 empresas por grupo y sin nombrar a ninguna.
Por sectores, lideran tecnología y telecomunicaciones, junto con retail y gran consumo, con un 87 % de dominios con política de bloqueo, seguidos de banca y seguros (83 %), energía (76 %) e industria (75 %). Sanidad y farmacia se queda en el 65 %, y educación superior privada y construcción, inmobiliario y logística cierran la tabla con un 55 %. En educación, el 38 % de los dominios sigue en p=none, la cifra más alta de la muestra; en construcción y logística, el 17 % no publica ningún registro DMARC.
La política de rechazo, la única que impide de verdad la suplantación, solo supera la mitad en banca y seguros (62 %); retail se queda justo en el 50 %. Tecnología, con el 87 % de bloqueo, tiene al 47 % en cuarentena y solo al 40 % en reject; energía, al 44 % en cuarentena y al 32 % en reject. La cuarentena manda el correo suplantado a la carpeta de no deseado, donde el usuario sigue pudiendo abrirlo.
Dos hallazgos secundarios pesan tanto como la política. Once dominios tienen política de bloqueo pero ningún destino de informes, así que bloquean correo sin saber qué están bloqueando. Y once de los 84 dominios en p=reject no publican ningún selector DKIM de los habituales, lo que sugiere que se apoyan solo en SPF, justo lo que el RFC 9989 prohíbe para una política de rechazo. El escaneo no puede descartar un selector propio, así que es una sospecha y no una prueba.
El dato de SPF es el que más sorprende. Casi todos publican registro (216 de 219) y el 77 % de los que lo publican termina en -all. Pero seis dominios superan ya el límite de diez consultas DNS, con lo que su SPF debería devolver error permanente en un receptor que aplique el RFC 7208 al pie de la letra, y otros 49, el 22 %, están entre ocho y diez.
Cada nuevo proveedor de envío que contrate cualquier departamento añade uno o varios includes, y el registro se rompe sin que nadie toque DMARC. Tecnología (11 dominios entre ocho y diez, dos por encima) y educación (9 y 3) son los sectores más cercanos al borde.
Las capas posteriores casi no existen: MTA-STS aparece en 6 dominios de 219, TLS-RPT en 10 y BIMI en 23, dos tercios de ellos en banca, retail y tecnología. Y la etiqueta np del RFC 9989 no la publica ninguno; sp, que protege a los subdominios existentes, solo el 20 %.
¿Qué exigen hoy los grandes receptores y el nuevo estándar?
Desde el 1 de febrero de 2024, cualquier remitente que envíe más de 5.000 mensajes diarios a cuentas de Gmail tiene que publicar SPF y DKIM. Debe disponer también de un registro DMARC, que Google acepta en p=none como mínimo. Además, el dominio que aparece en el remitente visible debe coincidir con el dominio que autentica SPF o DKIM, lo que en la jerga se llama alineación.
Las directrices para remitentes de Google añaden a esos requisitos de autenticación otros de infraestructura y buenas prácticas: registros PTR válidos, transporte TLS, una tasa de quejas por spam por debajo del 0,3 % (Google recomienda no pasar del 0,1 %) y baja en un clic para el correo comercial. Las mismas directrices fijan un suelo para todo remitente, con volumen o sin él: al menos SPF o DKIM.
Microsoft adoptó una postura equivalente un año después. Su aviso para remitentes de gran volumen establece desde el 5 de mayo de 2025 los mismos tres requisitos de autenticación, con alineación incluida. Afecta a quien envíe más de 5.000 mensajes al día a los buzones de consumo de Outlook.com y sus dominios hermanos. Quien no cumpla ve primero su correo en la carpeta de no deseado y, en una fecha que Microsoft todavía no ha anunciado, lo verá rechazado con el código 550 5.7.515.
El estándar DMARC también se ha renovado. En mayo de 2026 el IETF publicó RFC 9989, que reemplaza al RFC 7489 de 2015 y eleva DMARC a la categoría de estándar propuesto; lo acompañan el RFC 9990, dedicado a los informes agregados, y el RFC 9991, dedicado a los informes de fallo.
Con RFC 9989 el registro DMARC sigue empezando por v=DMARC1, así que no hay que migrar nada con urgencia, pero cambian varias piezas del despliegue: las etiquetas pct, rf y ri quedan como históricas, aparecen np para los subdominios inexistentes y t=y para probar una política sin aplicarla del todo, y el descubrimiento del dominio organizativo ya no depende de la Public Suffix List. Y hay una frase del RFC que cualquier responsable de correo debería subrayar: los dominios que publican p=reject no pueden apoyarse solo en SPF y tienen que firmar con DKIM; el RFC lo formula como obligación.
En el terreno normativo español, el Esquema Nacional de Seguridad reserva al correo electrónico una medida específica dentro del bloque de protección de servicios, la mp.s.1, y la autenticación del dominio es la evidencia más directa para acreditarla en una certificación ENS. Fuera de España, el NCSC británico mantiene desde 2019 una guía de seguridad del correo que ordena el despliegue en esta secuencia: TLS, SPF, DKIM, DMARC en none, cuarentena y, por último, rechazo.
¿Por qué tantas empresas se quedan en p=none?
La objeción más habitual merece una respuesta seria porque es legítima: el miedo a perder correo. Un dominio corporativo normal envía desde el servidor de correo, pero también desde el CRM, la plataforma de marketing, el sistema de facturación, la herramienta de tickets, el gestor de nóminas, la firma electrónica y media docena de servicios que nadie apuntó al contratarlos. Cualquiera de ellos que no autentique bien empezará a fallar en cuanto la política pase a cuarentena, y el primero en enterarse será el cliente que no recibe su factura.
A esa objeción se suman dos trampas técnicas que castigan a quien pasa a rechazo sin preparación. Una es el límite de SPF: el RFC 7208 obliga a los receptores a abortar la evaluación con un error permanente si el registro provoca más de diez consultas DNS, y cada include de un proveedor consume una o varias. La otra es el reenvío: cuando un buzón reenvía un mensaje de forma automática, o cuando una lista de distribución lo redistribuye, SPF falla porque la IP de origen ya no es la del remitente original, un problema que el RFC 7960 describe desde 2016.
Una tercera trampa son los subdominios olvidados: desde ellos sigue saliendo correo de algún sistema antiguo y, si nadie les asigna una política específica, heredan la del dominio principal. Cuando el dominio principal pasa a rechazo, ese correo desaparece sin que nadie sepa por qué.
La consecuencia de esa objeción y de esas tres trampas es conocida: el equipo de sistemas publica p=none para cumplir el requisito de Google, comprueba que el correo sigue llegando y cierra la incidencia. Mientras tanto, cualquiera puede seguir enviando facturas falsas con el dominio de la empresa en el campo De, y los receptores las tratan igual que a cualquier otro mensaje sin política de bloqueo.
¿Por qué los informes de DMARC resuelven la objeción?
La respuesta al miedo a perder correo está dentro del mismo DMARC, en sus informes. Los informes agregados se piden con la etiqueta rua y los envían Google, Microsoft, Yahoo y el resto de receptores participantes. Indican, para cada IP que ha enviado correo con tu dominio, cuántos mensajes fueron, si pasaron SPF, si pasaron DKIM y si estaban alineados. Leídos durante unas semanas, dibujan el inventario completo de remitentes legítimos que nadie tenía por escrito, junto con las fuentes que están suplantando el dominio.
El problema del reenvío lo resuelve DKIM: la firma viaja dentro del mensaje y sobrevive al salto entre servidores mientras nadie modifique el cuerpo firmado. Por esa razón el RFC 9989 convierte DKIM en obligatorio para quien publica reject, y por esa razón el NCSC señala que DKIM, aunque esté menos extendido que SPF, es el mecanismo que aguanta el correo reenviado.
Las listas de distribución que reescriben el asunto o añaden un pie de página siguen siendo el caso difícil, porque rompen la firma DKIM. Para ese supuesto, el RFC 9989 pide a los receptores que no rechacen un mensaje solo por la política publicada y que apliquen otros criterios para no romper esos flujos.
El límite de diez consultas de SPF se gestiona con inventario: retirar del registro los proveedores que ya firman con DKIM alineado, eliminar los includes de servicios dados de baja y, si aun así no cabe, mover el correo masivo a un subdominio con un registro SPF independiente. Los subdominios se cubren con las etiquetas sp, para los que existen, y np, para los que no existen, de modo que un atacante no pueda inventarse uno.
¿Cómo se llega a p=reject sin perder correo?
La secuencia que se desprende del RFC 9989 y de la guía del NCSC cabe en seis pasos, y ninguno de ellos debería saltarse.
- Publica DMARC en modo monitorización desde el primer día: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.es. Si los informes van a un dominio distinto del que publica la política, ese dominio tiene que autorizarlo con un registro _report._dmarc; de lo contrario los receptores descartan el envío.
- Durante al menos un mes, convierte los informes en un inventario: cada fuente legítima con su servicio, su responsable interno y su método de autenticación. Los informes son ficheros XML pensados para máquinas, así que una herramienta de análisis, comercial o de código abierto, evita leerlos a mano.
- Arregla la autenticación fuente por fuente: cada proveedor firma con DKIM alineado a tu dominio, usando claves de al menos 1.024 bits (Google exige ese mínimo y recomienda 2.048) y selectores independientes que puedas rotar sin tocar los demás. En SPF incluye solo lo imprescindible y termina el registro en -all sin superar las diez consultas.
- Pasa a p=quarantine cuando todas las fuentes conocidas pasen la autenticación. El RFC 9989 ofrece la etiqueta t=y para pedir a los receptores que apliquen la política un escalón por debajo de la publicada mientras siguen llegando informes; sustituye al antiguo despliegue gradual con la etiqueta pct, que el mismo RFC deja como histórica.
- Pasa a p=reject cuando los informes lleven semanas sin fallos de fuentes legítimas. Declara sp=reject para que cualquier subdominio sin registro propio herede el rechazo, y np=reject para los subdominios que no existen; los subdominios que sí envían correo necesitan un registro DMARC específico.
- Cierra los dominios que no envían correo, que a menudo son más numerosos que los que sí lo envían: v=spf1 -all, un registro MX nulo y DMARC en reject. Un dominio aparcado sin esa configuración es de los primeros que un atacante prueba a suplantar.
Cumplidos los seis pasos quedan dos capas que protegen el correo entrante en tránsito, no la identidad del saliente: MTA-STS, que obliga a quien te envía correo a usar TLS válido y evita que un intermediario degrade la conexión, y TLS-RPT, que te informa de los fallos de esa negociación. En nuestro informe sobre 60 grandes empresas europeas, el 98 % de los dominios publicaba algún registro DMARC y solo el 15 % publicaba MTA-STS: el correo saliente lleva años en la agenda de las grandes organizaciones; el transporte entrante, todavía no.
Qué vigilar después
Llegar a p=reject no cierra el proyecto. Los informes hay que seguir leyéndolos, porque cada proveedor nuevo que contrate marketing o recursos humanos reaparecerá como fuente sin autenticar, y porque las IP que siguen intentando suplantar el dominio son información útil para el equipo de seguridad. Un análisis de superficie de ataque que incluya el correo detecta además los dominios parecidos que DMARC no cubre: en junio escaneamos 24 marcas y encontramos 591 dominios imitadores activos, contra los que ninguna política del dominio legítimo sirve.
¿Qué cuesta dejar el dominio en p=none?
El fraude por correo tiene una cifra oficial. El informe anual 2025 del IC3, el centro de denuncias del FBI, recoge 24.768 denuncias de fraude del CEO y compromiso del correo corporativo con 3.046 millones de dólares de pérdidas declaradas, frente a 2.770 millones en 2024; el total de cibercrimen denunciado en 2025 fue de 20.877 millones. Son denuncias presentadas al FBI, en su mayoría desde Estados Unidos, y no existe una serie equivalente para España, pero el mecanismo del fraude es idéntico en cualquier país.
DMARC frena una cosa y solo una: la suplantación directa del dominio, una de las formas de phishing más difíciles de detectar para el usuario porque el remitente es exactamente el real. No frena un dominio parecido, ni un buzón legítimo comprometido desde el que el atacante escribe con credenciales robadas, ni una llamada con voz clonada. Para cada uno de esos casos hacen falta otros controles, y que esas amenazas existan no es excusa para dejar el dominio abierto.
Lo que el comité no puede delegar
Pasar de p=none a p=reject es una decisión de negocio con apariencia de tarea técnica, porque exige que alguien con autoridad diga a marketing, a finanzas y a recursos humanos que sus proveedores de envío autentiquen correctamente o dejen de usar el dominio. Sin ese respaldo, nadie en sistemas asumirá el riesgo de romper el correo de otro departamento, y la política se queda en none.
Como empresa de ciberseguridad que audita dominios cada semana, y tras revisar los 219 dominios de este escaneo, lo que vemos fallar casi nunca es la configuración DNS, que se arregla en horas. Lo que falla es que el dominio no tiene un dueño reconocido dentro de la organización. Nombrar a esa persona es lo que el comité no puede delegar.
Sobre el escaneo: los datos por sector proceden de consultas DNS públicas realizadas el 7 de septiembre de 2026 sobre 219 dominios de correo de grandes empresas españolas seleccionadas con los criterios descritos en el texto; se publican únicamente agregados por sector, con un mínimo de 23 empresas por grupo, y ninguna empresa se identifica. La ausencia de un selector DKIM habitual no demuestra que el dominio no firme con DKIM. Los registros DNS cambian, y una empresa puede haber modificado su política después de esa fecha.
Este artículo tiene carácter divulgativo. Los registros y la secuencia de despliegue descritos se basan en RFC 9989, RFC 7208 y en las directrices públicas de Google, Microsoft y el NCSC a fecha de publicación, y deben adaptarse al inventario de remitentes y a las herramientas de cada organización; una política de rechazo aplicada sin inventario previo puede bloquear correo legítimo. Las cifras de adopción y de fraude proceden de terceros y se citan con su fuente.
