Una política p=none no bloquea ningún mensaje, mientras que una política p=reject mal preparada bloquea mensajes legítimos. Entre ambas, DMARC deja fuera el nombre visible y los dominios parecidos, y tampoco detecta una cuenta comprometida. En pocas palabras: el protocolo frena la suplantación exacta del dominio del remitente y nada más, y su puesta en marcha expone a perder correos de clientes y a olvidar remitentes externos. Los límites se compensan con otras herramientas; los riesgos se controlan con un despliegue progresivo.
El panel de la herramienta de emailing muestra «todo OK» y, sin embargo, las campañas acaban en spam: la autenticación es uno de los primeros sitios que conviene revisar. En cuanto al fraude, el FBI cifra en 3050 millones de dólares las pérdidas por Business Email Compromise (24 768 denuncias) en su informe IC3 2025, frente a 2770 millones en 2024 (21 442 denuncias).
Qué controla DMARC
DMARC se apoya en SPF y DKIM. Un mensaje supera el control si uno de los dos pasa y si el dominio autenticado se alinea con el de la cabecera From, campo definido por la RFC 5322. Este alineamiento es el punto que los equipos descubren el último: un SPF válido para el dominio de un proveedor no basta cuando la dirección visible lleva el suyo. Si el control falla, el destinatario aplica la política publicada por el propietario del dominio: quarantine envía al spam, reject rechaza el mensaje y none no hace nada.
Dos ajustes fijan el rigor de ese alineamiento. Por defecto es «relaxed»: mail.ejemplo.es se alinea con ejemplo.es, porque comparten el mismo dominio organizativo. En modo «strict», que se activa con adkim=s para DKIM y aspf=s para SPF, los dos nombres deben ser idénticos. El modo estricto cierra puertas, pero también rompe a cualquier proveedor que firme con un subdominio, algo que rara vez se descubre antes de pasar a reject.
La propia norma delimita su alcance. Desde mayo de 2026, la RFC 9989 (vía Standards Track de la IETF) define DMARC y sustituye a las RFC 7489 (marzo de 2015) y 9091 (2021). Su sección 2.2 precisa que DMARC no trata los dominios visualmente parecidos ni el abuso del nombre legible del remitente, y la sección 2.4 deja fuera de su campo los ataques por display name: el texto de 2015 ya decía lo mismo.
Display name y dominios parecidos: dos puntos ciegos documentados
Un mensaje que muestra «Atención al cliente Banco X» y se envía desde soporte@banco-x-seguridad.com pasa DMARC sin dificultad. El dominio de envío pertenece al atacante, que ha publicado su propio SPF y su propia clave DKIM, así que SPF, DKIM y DMARC aparecen todos en verde. El control se aplica al dominio técnico; el nombre que el cliente de correo destaca no se examina.
Los dominios parecidos (typosquatting, guiones añadidos, otra extensión) siguen la misma lógica: su registro protege su dominio, no los que se le parecen. La defensa pasa por vigilar los registros de dominios cercanos al suyo y por el filtrado en recepción.
Una cuenta comprometida supera todos los controles
Un buzón cuyas credenciales se han filtrado envía desde la infraestructura correcta y con la firma correcta. La puerta de entrada suele ser un phishing o una filtración de datos; DMARC no tiene nada que señalar, porque el mensaje es auténtico. La autenticación multifactor y la alerta ante conexiones inusuales actúan antes, fuera del perímetro del protocolo.
Reenvíos y listas de distribución: el alineamiento se rompe por el camino
Cuando un alias de empresa o una lista de distribución retransmite un mensaje, la IP del relé no figura en el SPF del dominio de origen, por lo que SPF suele fallar. Queda DKIM, que sobrevive mientras no se modifique el contenido firmado. Una lista Mailman o Listserv que añade un pie de página invalida la firma, y el mensaje legítimo falla en los dos controles.
La RFC 9989 (sección 7.4) pone el ejemplo de un banco cuyos clientes han dado una dirección de antiguo alumno, del tipo jones@alumni.example.edu, que reenvía a otro buzón: el mensaje llega desde la IP del relé, ausente del SPF del remitente (RFC 5321 de 2008, MailFrom), salvo reescritura. Las firmas DKIM (RFC 6376 de 2011) suelen seguir siendo válidas mientras no se modifique el cuerpo del mensaje. Una lista de distribución que añade un pie de página las rompe.
La RFC 9989 (sección 7.4, que remite a la RFC 7960 de 2016 sobre listas de distribución) extrae dos consignas: un dominio con p=reject no debe depender solo de SPF y tiene que firmar con DKIM; un dominio cuyos usuarios escriben a listas de distribución públicas no debería publicar p=reject. El protocolo ARC (Authenticated Received Chain, RFC 8617 de julio de 2019) sirve para conservar el resultado de autenticación original, siempre que el relé lo haya activado.
Subdominios: ¿quién manda, el dominio o el subdominio?
El subdominio manda en cuanto publica su propio registro; si no, hereda el del dominio padre. La RFC 9989 lo resume en dos reglas. El destinatario busca primero un registro en el dominio exacto del From y después sube por el árbol DNS (DNS tree walk, sección 4.10, limitado a 8 consultas DNS): un registro propio del subdominio prevalece, por tanto, sobre el del padre. Y sin la etiqueta sp=, la política p= del dominio principal se aplica a los subdominios.
Consecuencia práctica: un _dmarc.newsletter.ejemplo.es que se quedó en p=none tras una prueba deja ese ámbito en simple vigilancia mientras ejemplo.es está en reject. En sentido contrario, un sp=none en el dominio principal deja abiertos todos los subdominios sin registro propio; es útil durante la auditoría y conviene retirarlo después. La etiqueta sp= se ignora en un registro publicado en un subdominio. Desde la RFC 9091, recogida por la RFC 9989, una etiqueta np= regula además el caso de los subdominios que no existen en el DNS.
p=none, el modo de vigilancia que da una falsa sensación de seguridad
El registro existe y la comprobación de conformidad pasa, pero no se bloquea nada. Google precisa en su página de despliegue, consultada el 27 de octubre de 2026, que con p=none los mensajes se entregan con normalidad. Un dominio que se queda así durante años sigue aceptando mensajes suplantados.
p=reject: los correos legítimos que desaparecen
Con reject, un dominio rechaza a todo remitente cuyo SPF o DKIM no se alinee. El departamento de RR. HH. envía las nóminas con una herramienta externa, soporte usa un helpdesk y facturación un módulo SaaS: cada uno escribe en nombre del dominio y será rechazado el día del cambio si no está alineado. Google lo dice sin rodeos: los mensajes que no superan el control se rechazan y no se entregan nunca. En quarantine, en el mejor de los casos acaban en la carpeta de spam. Los informes rua del día siguiente enumeran entonces las IP cuyos mensajes han fallado, incluidas las que nadie había registrado. De ahí el interés de pasar primero por quarantine y señalar la fase de prueba con t=y antes de cualquier reject.
Los proveedores de envío generan la trampa más frecuente. En una IP compartida o dedicada, el SPF valida el dominio del proveedor; el alineamiento DMARC depende entonces de una firma DKIM con su dominio, salvo que haya un Return-Path personalizado. Sin ella, la campaña falla desde el primer cambio a reject. La clave DKIM se publica bajo un selector dedicado, con la forma selector._domainkey.ejemplo.es; la firma debe llevar el dominio del From.
Errores en el TXT y el límite SPF de 10 consultas DNS
Un error de configuración basta para neutralizar DMARC sin ninguna alerta. El DNS no lo señala: el registro se publica sin validación, así que una errata en la zona solo se revela al leer los informes, unos días después. Un registro partido en dos cadenas mal unidas, unas comillas tipográficas pegadas desde un procesador de texto o un punto y coma olvidado entre dos etiquetas son suficientes. ¿Dos registros DMARC en el mismo nombre? La RFC 9989 descarta entonces todos los registros encontrados en ese lugar (sección 4.10). Un v=DMARC1 mal escrito hace que se ignore el registro entero; una etiqueta desconocida se ignora sin aviso; un fallo en rua= deja sin informes sin romper nada a simple vista. Una dirección de informes alojada en otro dominio exige además un registro de autorización en ese dominio (RFC 9990).
En cuanto a SPF, la RFC 7208 (sección 4.6.4) limita la evaluación a 10 consultas DNS: cuentan include, a, mx, ptr, exists y redirect, pero no ip4 ni ip6. Las consultas vacías se limitan a 2. Más allá, el resultado es permerror (un límite que ya recogía la RFC 4408 de abril de 2006) y SPF deja de contribuir a DMARC. Cada herramienta añadida mediante un include acerca el dominio a ese umbral.
Límites y riesgos en una tabla
| Caso | Por qué | Qué hacer |
|---|---|---|
| Display name suplantado | DMARC controla el dominio del From; el nombre visible se le escapa | Filtrado antiphishing en recepción, concienciación |
| Dominio parecido | Dominio de un tercero con sus propios SPF, DKIM y DMARC | Vigilancia de dominios cercanos, registros defensivos |
| Cuenta comprometida | El mensaje es auténtico | MFA, alertas de conexión |
| Reenvío, lista de distribución | SPF falla; DKIM falla si cambia el contenido | DKIM en todos los flujos, ARC |
| Subdominio | Herencia de p=; un registro propio prevalece |
Inventario, sp= asumido |
p=none duradero |
Ninguna acción sobre los mensajes que fallan | Calendario de paso a quarantine |
p=reject demasiado pronto |
Remitente externo no alineado | Inventario, informes rua, prueba con t=y |
| SPF por encima de 10 consultas | permerror, SPF deja de contar | Quitar include innecesarios, firmar con DKIM |
| Error en el TXT | Registro o etiqueta ignorados | Un solo registro, revisión de la sintaxis |
Pasar de none a reject sin perder correos
El recorrido se resume en tres tiempos: inventariar los remitentes, observar en none y endurecer por etapas pasando por quarantine antes de reject. Todo empieza por el inventario de remitentes: herramienta de emailing, CRM, helpdesk, nóminas, facturación, servidores de aplicaciones. Los equipos siempre olvidan alguno; los informes agregados rua sirven para encontrarlo, porque enumeran cada IP que ha enviado en nombre del dominio con su resultado SPF y DKIM.
Los pasos son siempre los mismos: p=none, lectura de los informes, quarantine y después reject. En la ayuda de Google Workspace, Google recomienda configurar SPF y DKIM al menos 48 horas antes de publicar DMARC, mantenerse una semana en p=none con lectura diaria de los informes y pasar después a quarantine con un porcentaje bajo de mensajes: 10 % para una organización pequeña, 1 % para una grande (página «Despliegue DMARC recomendado»). Un registro de partida se parece a v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@ejemplo.es, publicado como TXT en _dmarc.ejemplo.es. Atención: la etiqueta pct= de la RFC 7489 ya no existe en la RFC 9989, que señala que se aplicaba de forma muy desigual fuera de los valores 0 y 100 y la sustituye por t=y (prueba) o t=n. La propia RFC 9989 recomienda publicar p=none al menos un mes apoyándose en los informes agregados.
El tiempo que lleva cada paso depende del número de flujos: con pocas fuentes de envío, una semana de informes puede bastar para inventariarlas; con 20 herramientas, los remitentes olvidados aparecen informe tras informe. Durante la subida, un sp= distinto permite endurecer el dominio principal mientras los subdominios sin auditar siguen en none.
Gmail, Yahoo y la entregabilidad
Desde el 1 de febrero de 2024, Google exige a los remitentes de más de 5000 mensajes diarios hacia Gmail un SPF y un DKIM válidos, además de una política DMARC; puede quedarse en none. La tasa de spam que muestra Google Postmaster Tools debe mantenerse por debajo del 0,30 %, con un objetivo por debajo del 0,10 % (pautas de Google para remitentes). Yahoo, que aplica sus reglas a los remitentes masivos desde febrero de 2024, también pide un DMARC como mínimo en none, con un dominio From alineado con SPF o DKIM (buenas prácticas de Yahoo). El detalle sobre Gmail está en el artículo sobre los requisitos de Gmail para remitentes.
DMARC abre, por tanto, la puerta de la bandeja de entrada sin fijar la reputación del remitente. Esa reputación depende de la tasa de quejas y de los rebotes: un dominio en reject que envía a una lista llena de direcciones muertas alimenta los rebotes duros y daña su entregabilidad. Pasar una muestra de la lista por una herramienta de verificación antes de la próxima campaña permite ver esa tasa antes de que Gmail la mida.
¿Contiene su próximo informe rua una fuente de envío que nadie en el equipo reconoce?
