DMARC: la guía completa del registro DMARC

La sintaxis del registro _dmarc

Un registro DMARC es un único registro TXT publicado en el subdominio _dmarc del dominio a proteger. Un dominio solo debe llevar uno — dos registros vuelven la política ambigua y los destinatarios pueden ignorar ambos.

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:informes@ejemplo.es; adkim=s; aspf=r"

El valor es una serie de pares etiqueta=valor separados por punto y coma. v=DMARC1 debe abrir el registro — también bajo DMARCbis, que conserva este identificador de versión por retrocompatibilidad. Estas son las etiquetas tal como las define la RFC 9989:

Etiqueta	Función	Valores	Observaciones
v	Versión del protocolo	DMARC1	Obligatoria, en primera posición — sin cambios con DMARCbis
p	Política del dominio	none, quarantine, reject	Obligatoria; se aplica al dominio y, por defecto, a sus subdominios
sp	Política de los subdominios	none, quarantine, reject	Opcional; sustituye a p para los subdominios existentes
np	Política de los subdominios inexistentes	none, quarantine, reject	Novedad de DMARCbis; apunta a los subdominios que no resuelven
rua	Destino de los informes agregados	mailto: (una o varias direcciones)	Muy recomendada: sin ella, ningún retorno
ruf	Destino de los informes de fallo	mailto:	Opcional; envíos raros y a menudo censurados
adkim	Modo de alineación DKIM	r (relaxed), s (strict)	Por defecto: r
aspf	Modo de alineación SPF	r (relaxed), s (strict)	Por defecto: r
t	Modo de prueba	y, n	Novedad de DMARCbis; reemplaza a la etiqueta pct, suprimida
psd	Marcador de dominio de sufijo público	y, n, u	Novedad de DMARCbis; concierne sobre todo a los registros de dominios

Dos evoluciones de DMARCbis merecen subrayarse aquí. Primero, la etiqueta pct — que pretendía aplicar la política a un porcentaje del correo — ha sido suprimida: los destinatarios la interpretaban de forma dispar y daba una falsa sensación de progresividad. Su relevo es la etiqueta de modo de prueba t, binaria y sin ambigüedad: t=y señala que la política está en experimentación. Segundo, la determinación del dominio organizativo — la base de la alineación relaxed — ya no descansa en la Public Suffix List, una lista externa mantenida a mano, sino en el DNS Tree Walk: el destinatario asciende por el propio árbol DNS, con un tope de ocho consultas. El resultado es determinista y autosuficiente.

Para partir de una base sólida en lugar de una página en blanco, el blog ofrece ejemplos de registros listos para adaptar, proveedor por proveedor.

Las tres políticas: none, quarantine, reject

La etiqueta p anuncia a los destinatarios qué deben hacer con un mensaje que falla DMARC. Los tres valores forman una escalera, y el peldaño elegido lo cambia todo:

• p=none — observación pura. Los mensajes en fallo se entregan con normalidad; solo se generan informes. Es el punto de partida obligado: permite inventariar las fuentes de envío sin riesgo alguno para el correo legítimo. Pero no protege nada ni a nadie — un dominio en p=none sigue siendo íntegramente suplantable.
• p=quarantine — los mensajes en fallo se tratan con desconfianza; en la práctica, van a la carpeta de correo no deseado. La protección se vuelve real: un correo suplantado ya no llega a la bandeja de entrada, pero sigue siendo recuperable, lo que limita el daño de un falso positivo.
• p=reject — los mensajes en fallo se rechazan durante la sesión SMTP. No se entregan ni se almacenan: suplantar el dominio exacto se vuelve imposible ante cualquier destinatario que aplique la política. Es el objetivo final, y el único nivel que detiene de verdad el phishing en nombre del dominio.

¿Cuándo usar cada una? p=none durante la fase de inventario, mientras los informes sigan revelando fuentes legítimas no alineadas. p=quarantine en cuanto los informes estén limpios, como etapa de validación en condiciones reales. p=reject como régimen de crucero, cuando la cuarentena no haya hecho aflorar ningún incidente. La comparativa detallada de los dos niveles de aplicación — incluidos los casos en que una cuarentena prolongada se justifica — se trata en p=quarantine o p=reject: cuál elegir. Retenga el principio: none es un estado transitorio, no un destino. Un dominio que se estaciona ahí durante años documenta su exposición sin reducirla.

Los informes DMARC: rua y ruf

La parte de «Reporting» de DMARC es lo que hace pilotable el despliegue. Sin ella, endurecer una política sería navegar a ciegas; con ella, cada decisión se apoya en datos observados.

Los informes agregados (rua, especificados por la RFC 9990) son documentos XML enviados — normalmente a diario — por los destinatarios que han recibido correo que se reclama de su dominio. Google, Microsoft y Yahoo los producen a gran escala. Cada informe resume, por dirección IP emisora: el volumen de mensajes, el resultado SPF, el resultado DKIM, el estado de la alineación y la política aplicada. No contienen contenido de mensajes ni direcciones de destinatarios — solo estadística. Son la materia prima de todo despliegue: revelan los servicios de envío olvidados (plataforma de marketing, CRM, herramienta de facturación) que habrá que alinear antes de endurecer. Su estructura e interpretación se detallan en leer los informes agregados DMARC.

Los informes de fallo (ruf, RFC 9991) son distintos: emitidos uno a uno, en el momento de un fallo, contienen extractos del mensaje afectado. Prometen un diagnóstico fino pero rara vez cumplen: la mayoría de los grandes destinatarios no los envían o los censuran a fondo, por razones de privacidad — un mensaje real puede contener datos personales. En la práctica, un despliegue se pilota con los informes agregados; los de fallo son un complemento ocasional, que se solicita con conocimiento de causa. Las diferencias, casos de uso y precauciones de ambos canales se comparan en rua vs ruf: qué informes solicitar.

Una dirección rua debe figurar en todo registro, desde el primer día y sea cual sea la política. Si los informes se envían a un dominio tercero (un proveedor de análisis, por ejemplo), ese dominio debe publicar un registro de autorización externa que confirme que acepta recibirlos.

El camino de despliegue: de p=none a p=reject

El despliegue de DMARC es un proceso iterativo en el que cada etapa se valida con los informes. La secuencia probada:

1. Publicar p=none con una dirección rua. Ningún impacto en el correo; la recogida comienza. Cuente de dos a cuatro semanas para obtener una imagen representativa, ciclos de facturación y envíos mensuales incluidos.
2. Inventariar las fuentes. Los informes revelan cada IP que emite en nombre del dominio. Clasifíquelas: servicios legítimos por alinear, servicios desconocidos por investigar, suplantación caracterizada.
3. Alinear cada fuente legítima. Añadir los emisores al registro SPF y activar DKIM con un dominio de firma alineado en cada proveedor de envío. Es la etapa más larga — depende de la cooperación de los equipos y de los proveedores.
4. Pasar a p=quarantine. Cuando los informes muestren que todo el correo legítimo está alineado. El modo de prueba t=y de DMARCbis permite declarar ese endurecimiento en experimentación mientras se verifica que ninguna fuente olvidada caería.
5. Pasar a p=reject. Tras unas semanas de cuarentena sin incidentes. La vigilancia de los informes continúa después como rutina: una nueva fuente aparece cada vez que un equipo adopta una herramienta nueva.

Los criterios objetivos que indican que un dominio está listo para subir un peldaño — tasa de alineación, estabilidad, cobertura de subdominios — están reunidos en la checklist de elegibilidad de p=none a p=reject, y el relato completo del recorrido, escollos incluidos, en alcanzar p=reject sin romper el correo. Antes de nada, verifique el estado real de su registro actual con nuestro analizador DMARC gratuito: política publicada, alineación, errores de sintaxis — el punto de partida se mide, no se adivina.

DMARCbis en breve

DMARCbis es la revisión completa del estándar, publicada por el IETF en forma de tres RFC: 9989 (el protocolo), 9990 (los informes agregados) y 9991 (los informes de fallo). Juntas reemplazan a la RFC 7489 de 2015 y llevan a DMARC, por primera vez, al estatus de Proposed Standard — la vía de estándares, cuando el texto original era meramente informativo.

Lo esencial cabe en cuatro puntos:

• Retrocompatibilidad total. Los registros siguen empezando por v=DMARC1; un registro existente sigue siendo válido sin modificación.
• pct suprimida, t introducida. El despliegue «por porcentaje» desaparece en favor de un modo de prueba binario, más honesto e interpretado de manera uniforme.
• np y psd introducidas. La primera bloquea los subdominios inexistentes, blanco favorito de los suplantadores; la segunda marca los dominios de sufijo público.
• El DNS Tree Walk reemplaza a la Public Suffix List. El descubrimiento del dominio organizativo pasa a ser nativo del DNS, determinista e idéntico en todos los destinatarios.

Para el análisis completo del nuevo estándar — génesis, debates del grupo de trabajo, consecuencias para el ecosistema —, ver DMARCbis explicado. Y si se pregunta qué hay que cambiar concretamente en un registro existente, la respuesta corta es «muy poco»: el modo de empleo cabe en ¿hay que migrar a DMARCbis? — retirar una pct ya inerte, plantearse np=reject, y poco más.

Casos particulares: subdominios y dominios aparcados

Los subdominios heredan por defecto la política p del dominio organizativo — salvo que una etiqueta sp decida otra cosa, o que el subdominio publique su propio registro _dmarc. Esta flexibilidad es útil (un subdominio de envío transaccional puede endurecer antes que el dominio raíz), pero también es un punto ciego clásico: un p=reject en la raíz acompañado de un sp=none deja todos los subdominios suplantables. DMARCbis añade la etiqueta np para un caso aún más insidioso: los subdominios inexistentes. Nada impide a un atacante emitir desde nominas.ejemplo.es aunque ese nombre nunca haya existido en su zona — y como ningún servicio legítimo puede depender de él, un np=reject se publica sin el menor riesgo, a menudo mucho antes de que la raíz esté lista. La articulación completa de los tres niveles — p, sp, np — y sus trampas de herencia se tratan en la política de subdominio DMARC.

Los dominios aparcados — en propiedad pero sin enviar nunca correo — son el otro punto ciego. Precisamente porque nadie los vigila, son blancos de suplantación ideales: el destinatario no tiene motivo para desconfiar de un dominio que realmente le pertenece a usted. La protección es simple e inmediata, puesto que no hay correo legítimo que preservar: p=reject de entrada, un SPF v=spf1 -all que no autoriza a ningún emisor, sin DKIM, y un null MX para señalar que no se espera correo alguno. El procedimiento completo, registro a registro, se describe en proteger un dominio aparcado. Un inventario de dominios bien llevado aplica este bloqueo a cada dominio dormido de la cartera — es el endurecimiento con mejor relación esfuerzo/protección de toda la iniciativa.

FAQ

¿DMARC reemplaza a SPF y DKIM?

No. DMARC no funciona sin ellos: se apoya en sus resultados y les añade la alineación con el dominio del From:, luego la política y los informes. Un mensaje pasa DMARC si SPF o DKIM tiene éxito con un dominio alineado. Los tres estándares se despliegan, pues, juntos: SPF y DKIM primero, DMARC para ligarlos a la dirección visible y hacer el conjunto exigible.

¿Se pueden publicar varios registros DMARC en un mismo dominio?

No. Un dominio solo debe llevar un único registro TXT en _dmarc. Si coexisten varios registros que empiezan por v=DMARC1, el comportamiento de los destinatarios es indefinido — la mayoría los ignora todos, lo que deja al dominio sin política mientras se cree protegido. Cualquier modificación pasa por fusionarlo todo en un solo registro.

¿Sigue existiendo la etiqueta pct?

No. DMARCbis (RFC 9989) suprimió pct, cuya semántica de «aplicar la política a un porcentaje del correo» se interpretaba de forma distinta según el destinatario. La reemplaza la etiqueta t, un modo de prueba binario: t=y señala que la política está en experimentación. Una pct residual en un registro existente es simplemente ignorada por las implementaciones al día — retirarla mantiene el registro limpio.

¿Cuánto se tarda en pasar de p=none a p=reject?

Depende de cuántos servicios envíen en nombre del dominio. Un dominio simple, con una plataforma de correo y una o dos herramientas de envío, se bloquea en unas semanas. Una organización con decenas de fuentes — marketing, CRM, facturación, soporte — cuenta más bien en meses, el tiempo de alinear a cada proveedor. Las referencias de plazos realistas, fase por fase, se detallan en cuánto se tarda en alcanzar p=reject.

¿p=none protege un dominio contra la suplantación?

No. En p=none, los mensajes que fallan DMARC se entregan con normalidad: la política no pide ninguna acción a los destinatarios. p=none sirve para observar — una etapa indispensable, pero un dominio que permanece ahí indefinidamente sigue siendo tan suplantable como un dominio sin DMARC. La protección empieza en p=quarantine y se completa en p=reject.

¿Qué ocurre si un dominio no tiene ningún registro DMARC?

Los destinatarios no encuentran ninguna política y tratan el correo únicamente según sus propias heurísticas: un correo que suplante el dominio puede perfectamente llegar a la bandeja de entrada. El dominio tampoco recibe informes, y por tanto carece de visibilidad sobre el uso fraudulento de su nombre. Se añade un efecto de entregabilidad: los grandes proveedores de buzones exigen ya un registro DMARC a los remitentes masivos — su ausencia penaliza también al correo legítimo.