DMARCbis: la guía completa para entender y migrar al nuevo estándar DMARC

⚡TL;DR

• DMARCbis reemplaza DMARC (RFC 7489) y se convierte en Proposed Standard IETF. Los tres documentos se publicaron en mayo de 2026 como RFC 9989 (núcleo), RFC 9990 (informes agregados) y RFC 9991 (informes de fallo).
• El DNS Tree Walk reemplaza la Public Suffix List: el descubrimiento del dominio organizacional se realiza mediante consultas DNS sucesivas (máx 8), sin depender de una lista externa.
• Tres tags agregados: psd (marcador Public Suffix Domain), np (política para subdominios inexistentes), t (modo testing binario).
• Tres tags eliminados: pct (reemplazado por t), ri y rf (trasladados a los documentos de reporting).
• Tus registros DMARC actuales siguen siendo válidos (v=DMARC1). La migración consiste en eliminar los tags obsoletos y adoptar los nuevos de forma progresiva.

DMARC protege los dominios contra la suplantación de identidad por correo electrónico desde 2015. Pero la RFC 7489 tenía debilidades estructurales: dependencia de una lista externa (la Public Suffix List), un tag pct mal comprendido y mal implementado, ningún mecanismo para los subdominios inexistentes.

DMARCbis corrige estos problemas. No es una simple actualización: es una reescritura que eleva DMARC al rango de Proposed Standard IETF, el primer estatus normativo del protocolo. Los tres documentos (base, informes agregados, informes de fallo) se publicaron en mayo de 2026 como RFC 9989, 9990 y 9991.

Esta guía está dirigida a administradores de sistemas, responsables de correo e ingenieros de seguridad que necesitan entender los cambios y preparar la migración. Aquí encontrarás el funcionamiento detallado del DNS Tree Walk, un comparativo completo de los tags, un plan de migración y las implicaciones de conformidad (PCI DSS 4.0, Google, Yahoo, Microsoft).

Un glosario al final del artículo define los términos técnicos: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

¿Qué es DMARCbis y por qué reemplaza a la RFC 7489?

DMARCbis es el sucesor de DMARC tal como lo definía la RFC 7489. El término "bis" sigue la convención IETF para designar la segunda iteración de un protocolo. En concreto, DMARCbis agrupa tres documentos normativos:

• RFC 9989: el documento base (a partir de draft-ietf-dmarc-dmarcbis-41): descubrimiento de política, alineación, tags
• RFC 9990: los informes agregados XML
• RFC 9991: los informes de fallo (mensaje por mensaje)

¿Por qué esta reforma?

La RFC 7489, publicada en 2015, tenía el estatus "Informational". Esto significa que DMARC no era un estándar de Internet en sentido estricto. DMARCbis (RFC 9989) corrige esta anomalía convirtiéndose en un Proposed Standard, lo que le otorga peso normativo en el ecosistema IETF. La RFC 9989 deja formalmente obsoletas la RFC 7489 y la RFC 9091 (PSD DMARC).

Las motivaciones técnicas son precisas:

1. La Public Suffix List es frágil. Mantenida manualmente por Mozilla, no estandarizada, actualizada fuera de banda. Un registro olvidado o un nuevo TLD no listado provoca falsos negativos.
2. El tag pct era inútil. En la práctica, solo se usaban los valores 0 y 100. Las implementaciones variaban entre receptores, haciendo el comportamiento impredecible.
3. Los subdominios inexistentes no estaban protegidos. Un atacante podía enviar desde falso.subdominio.captaindns.com sin que DMARC se aplicara.
4. PSD DMARC (RFC 9091) seguía siendo experimental. DMARCbis (RFC 9989) deja obsoleta e integra esta extensión unificando el modelo mediante el tag psd y el Tree Walk.

Cronología IETF

Fecha	Evento
2015	RFC 7489 publicada (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Drafts DMARCbis iterativos en el WG DMARC
Q4 2025	Los tres drafts entran en la cola del RFC Editor (estado EDIT)
Mayo de 2026	Publicación como RFC 9989 / 9990 / 9991 (Proposed Standard)

Punto esencial: la versión del registro DNS sigue siendo v=DMARC1. No hay v=DMARC2. Los registros existentes siguen funcionando.

El tree walk DNS: cómo DMARCbis abandona la lista de sufijos públicos

El cambio más estructural de DMARCbis es el reemplazo de la Public Suffix List por un algoritmo de descubrimiento puramente DNS: el Tree Walk.

El problema del PSL

Con DMARC v1, para determinar el dominio organizacional (Organizational Domain), el receptor consultaba la Public Suffix List. Esta lista, mantenida por Mozilla, recoge los sufijos públicos (co.uk, com.au, gouv.fr). El receptor restaba el sufijo público del dominio para identificar la organización.

Las limitaciones eran conocidas:

• La lista debe descargarse y actualizarse regularmente (posible desfase)
• Los nuevos TLD o sufijos no listados provocan errores
• El mecanismo no está estandarizado: cada implementación gestiona la lista de forma diferente
• Ninguna autoridad DNS valida la exactitud de la lista

¿Cómo funciona el tree walk?

El Tree Walk consulta directamente el DNS para descubrir la política DMARC aplicable. El algoritmo es el siguiente:

Entrada: el dominio del encabezado From: (Author Domain)

Pasos:

1. Consultar _dmarc.<AuthorDomain>. Si se encuentra un registro DMARC con psd=n (o sin tag psd), este dominio es el dominio organizacional. Fin.
2. Si no se encuentra ningún registro, eliminar la etiqueta más a la izquierda y repetir.
3. Si se encuentra un registro con psd=y, el dominio organizacional está un nivel por debajo del dominio actual.
4. Si se encuentra un registro con psd=u, continuar la ascensión.
5. Repetir hasta encontrar un resultado o alcanzar el límite de 8 consultas DNS.

Salida: el dominio organizacional y la política aplicable (o "sin DMARC" si no se encuentra nada).

Ejemplos concretos

Caso 1: dominio simple

Para newsletter.captaindns.com:

Consulta 1: _dmarc.newsletter.captaindns.com -> sin registro
Consulta 2: _dmarc.captaindns.com -> "v=DMARC1; p=reject; psd=n"

Resultado: psd=n confirma que captaindns.com es el dominio organizacional. 2 consultas DNS.

Caso 2: Public Suffix Domain

Para contact.banque.co.uk:

Consulta 1: _dmarc.contact.banque.co.uk -> sin registro
Consulta 2: _dmarc.banque.co.uk -> sin registro
Consulta 3: _dmarc.co.uk -> "v=DMARC1; p=reject; psd=y"

Resultado: psd=y indica que co.uk es un PSD. El dominio organizacional es banque.co.uk (un nivel por debajo del PSD). 3 consultas DNS.

Caso 3: dominio profundo

Para un dominio con más de 8 etiquetas, el algoritmo salta directamente a 7 etiquetas tras la primera consulta, y luego asciende etiqueta por etiqueta. El límite de 8 consultas garantiza que el proceso termine.

Comparación entre el PSL y el tree walk

Aspecto	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Fuente de verdad	Lista estática (Mozilla)	El propio DNS
Actualización	Descarga periódica	Tiempo real mediante consultas DNS
Cobertura	Manual, potencialmente incompleta	Todo dominio que publique un registro _dmarc
Detección PSD	Búsqueda en la lista	Tag psd=y en el registro DNS
Estandarización	Proyecto comunitario, no normativo	Standards Track IETF

Rendimiento del tree walk

Para un dominio típico de 3 etiquetas (como newsletter.captaindns.com), el Tree Walk agrega como máximo 1 consulta DNS adicional respecto a DMARC v1. El límite de 8 consultas garantiza que los dominios profundos no causen sobrecarga.

La caché DNS atenúa el impacto en la práctica. Los registros _dmarc del dominio organizacional se almacenan en caché tras la primera consulta. Las respuestas NXDOMAIN también se almacenan en caché según el TTL del campo MINIMUM del SOA. Un dominio que recibe miles de mensajes por hora solo generará un puñado de consultas Tree Walk efectivas.

En comparación, el enfoque PSL no generaba ninguna consulta DNS para el descubrimiento. Pero requería la descarga periódica de una lista de aproximadamente 250 Ko y su mantenimiento en memoria.

Recomendación de TTL: publica tus registros _dmarc con un TTL de al menos 3600 s. Un TTL de 86400 s reduce aún más la carga DNS. Esto es particularmente útil para los registros con psd=n o psd=y, que sirven como puntos de anclaje del Tree Walk.

Lo que cambia en los tags DMARC

DMARCbis agrega tres tags, elimina tres y modifica el comportamiento de dos existentes. El tag de versión (v=DMARC1) y los tags fundamentales (p, sp, adkim, aspf, fo) permanecen sin cambios.

Tags agregados

El tag psd: marcador de sufijo público

El tag psd indica si el dominio que publica el registro es un Public Suffix Domain.

Valor	Significado
y	Este dominio es un PSD (ej: co.uk, gouv.fr). El dominio organizacional se encuentra un nivel por debajo.
n	Este dominio es un dominio organizacional normal.
u	No determinado. El Tree Walk continúa la ascensión.

Valor por defecto: u (undetermined).

¿Quién debe usarlo? Únicamente los operadores de sufijos públicos (registros TLD, registros sectoriales). Para un dominio estándar, deja psd ausente o indica psd=n.

Ejemplo para un registro:

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

El tag np: política para subdominios inexistentes

El tag np cubre un punto ciego de DMARC v1: los subdominios que no existen en el DNS. Un atacante podía enviar desde falso.captaindns.com sin política aplicable si no existía ningún registro _dmarc a ese nivel.

Con np, el dominio organizacional puede declarar una política específica para estos casos. Los valores son idénticos a p: none, quarantine, reject.

La cadena de fallback es: np (si está presente) luego sp (si está presente) luego p.

El receptor verifica la existencia del subdominio mediante DNS. Si el DNS devuelve NXDOMAIN, se aplica la política np.

Ejemplo:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-agg@captaindns.com"

Resultado: los subdominios existentes heredan p=quarantine. Los subdominios inexistentes se bloquean con np=reject.

El tag t: modo testing

El tag t reemplaza el uso de pct=0 para el modo test. La semántica es binaria:

• t=y: la política se retrograda un nivel (reject se convierte en quarantine, quarantine se convierte en none)
• t=n: la política se aplica normalmente (valor por defecto)

El modo testing no afecta al reporting: los informes agregados se envían normalmente, lo que permite monitorizar los resultados antes de aplicar la política estricta.

Punto crítico para la transición: los receptores DMARC v1 ignoran los tags desconocidos. Si publicas p=reject; t=y, un receptor que aún no implemente DMARCbis aplicará reject sin tener en cuenta t=y. Este comportamiento es por diseño: garantiza que la política más estricta se aplique por defecto.

Tags eliminados

Tag	Razón de la eliminación	Reemplazo
pct	En la práctica, solo se usaban los valores 0 y 100. El comportamiento variaba entre implementaciones.	t=y para el modo test, eliminación para el resto
ri	El intervalo de reporting estaba estandarizado de facto en 24 h. Los receptores ignoraban los demás valores.	Gestionado por el documento Aggregate Reporting
rf	Solo existía un formato (afrf). Ninguna alternativa se desplegó jamás.	Gestionado por el documento Failure Reporting

Si tus registros DMARC aún contienen pct, ri o rf, seguirán funcionando (los receptores los ignorarán). Pero se recomienda eliminarlos para evitar cualquier ambigüedad.

Tags modificados

rua (informes agregados): la sintaxis de límite de tamaño (!10m) se elimina. La verificación de destino externo se refuerza: si el dominio de la dirección rua difiere del dominio DMARC, debe existir un registro de autorización _dmarc-report._report.<rua-domain>.

ruf (informes de fallo): definido en un documento RFC separado (Failure Reporting). Misma verificación de destino externo que rua.

Tabla recapitulativa v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Estado
v	DMARC1	DMARC1	Sin cambios
p	none / quarantine / reject	Idéntico	Sin cambios
sp	Política subdominios	Idéntico	Sin cambios
adkim	r / s	Idéntico	Sin cambios
aspf	r / s	Idéntico	Sin cambios
fo	0 / 1 / d / s	Idéntico	Sin cambios
rua	URIs con límite de tamaño	URIs sin límite, verificación externa reforzada	Modificado
ruf	URIs	Definido en RFC separado	Modificado
pct	0-100	Eliminado	Eliminado
ri	Segundos	Eliminado	Eliminado
rf	afrf	Eliminado	Eliminado
np	N/A	none / quarantine / reject	Nuevo
psd	N/A	y / n / u	Nuevo
t	N/A	y / n	Nuevo

El reporting se separa en tres documentos

DMARC v1 agrupaba todo en la RFC 7489: política, informes agregados e informes de fallo. DMARCbis separa estas responsabilidades en tres documentos normativos distintos.

Los informes agregados

Los informes agregados siguen en formato XML, pero el esquema evoluciona. Los principales cambios:

• Nuevo namespace XML: urn:ietf:params:xml:ns:dmarc-2.0
• Nuevo campo <testing>: indica si el dominio estaba en modo test (t=y)
• Nuevo campo <np>: política para subdominios inexistentes
• Nuevo campo <discovery_method>: cómo se descubrió la política (Tree Walk vs directo)
• Nueva disposición pass: agregada a las disposiciones posibles
• Eliminación de sampled_out: la razón de override desaparece con pct

Cada URI listada en rua recibe su propio informe. Esto ya no es opcional: los receptores DEBEN enviar un informe distinto a cada dirección.

Los informes de fallo

Los informes de fallo ahora están cubiertos por un documento separado. Este cambio refleja la realidad: la mayoría de los grandes proveedores no enviaban informes de fallo, por razones de privacidad y volumen.

El documento clarifica los requisitos de confidencialidad y los casos en los que el envío es apropiado.

Otros cambios notables

• SPF restringido a MAIL FROM: DMARCbis elimina la verificación SPF basada en HELO/EHLO. Solo el dominio MAIL FROM se evalúa para la alineación.
• Directrices reforzadas sobre p=reject: los dominios con p=reject deben usar DKIM (no solo SPF). Los receptores no deben rechazar únicamente sobre la base de p=reject sin evaluación DKIM/SPF. Los dominios cuyos usuarios publican en listas de distribución no deberían publicar p=reject.

DMARCbis y las listas de distribución: evitar falsos positivos

Las listas de distribución son el caso de uso más problemático para DMARC desde 2015. DMARCbis no resuelve el problema, pero lo documenta formalmente y refuerza las recomendaciones.

¿Por qué las listas rompen la alineación?

Una lista de distribución modifica el mensaje en tránsito. El sobre SMTP cambia (nuevo MAIL FROM), lo que rompe la alineación SPF. El contenido suele modificarse (agregar un prefijo al asunto, footer de desuscripción), lo que invalida la firma DKIM. El resultado: un fallo DMARC sistemático para los dominios en p=reject.

DMARCbis refuerza formalmente la recomendación: los dominios cuyos usuarios participan en listas de distribución no deberían publicar p=reject. La política p=quarantine es preferible en este caso.

ARC como mecanismo de respaldo

ARC (Authenticated Received Chain, RFC 8617) permite a los intermediarios preservar una cadena de autenticación. DMARCbis referencia ARC como mecanismo que los receptores PUEDEN usar para recuperar los resultados de autenticación originales. Pero DMARCbis no hace ARC obligatorio. Es una opción, no una garantía.

Los tipos de override en los informes agregados

DMARCbis reconoce los siguientes tipos de override en los informes agregados:

• forwarded: mensaje reenviado por un tercero
• mailing_list: mensaje procedente de una lista de distribución
• trusted_forwarder: reenviador de confianza identificado por el receptor
• local_policy: política local del receptor (whitelist, reputación)
• policy_test_mode: nuevo tipo, reemplaza sampled_out (eliminado con pct)

Estos tipos permiten comprender por qué un receptor eligió no aplicar la política publicada.

Consejo práctico

Los softwares modernos de listas de distribución (Mailman 3, Sympa) incluyen mitigaciones DMARC integradas. La más común: la reescritura del From: para usar la dirección de la lista en lugar de la dirección original. Si tu dominio es utilizado por listas, verifica que estas mitigaciones estén activadas. Y prefiere p=quarantine a p=reject.

DMARCbis y los proveedores de envío (ESP)

Ningún ESP importante (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) ha anunciado soporte específico para DMARCbis en junio de 2026. Esto es normal y esperado: DMARCbis es un cambio del lado del receptor, no del lado del remitente. Los ESP no necesitan modificar su infraestructura.

La alineación DKIM: el desafío crítico

El desafío principal para los ESP sigue siendo la alineación DKIM. Existen dos modos de firma:

• Dominio compartido (ej: d=sendgrid.net): la firma DKIM usa el dominio del ESP. La alineación estricta falla porque el dominio DKIM no coincide con el dominio From:. La alineación relajada también falla.
• Dominio personalizado via CNAME (ej: d=captaindns.com): la firma DKIM usa tu propio dominio. La alineación pasa tanto en estricto como en relajado.

DMARCbis recomienda adkim=s (estricto). Esta recomendación hace que la firma DKIM personalizada sea indispensable para todo dominio que use un ESP.

SPF y el dominio de rebote

DMARCbis elimina la verificación SPF basada en HELO/EHLO. Solo el dominio MAIL FROM (Return-Path) cuenta para la alineación SPF. La mayoría de los ESP usan un dominio de rebote genérico por defecto (ej: bounce.sendgrid.net). Este dominio no coincide con tu dominio From:, lo que hace fallar la alineación SPF.

La solución: configura un dominio de rebote personalizado (Return-Path) que coincida con tu dominio From:. La mayoría de los ESP ofrecen esta opción mediante un CNAME DNS.

Checklist ESP

1. Verificar la firma DKIM personalizada: tu ESP debe firmar con d=captaindns.com, no con su propio dominio.
2. Verificar el Return-Path personalizado: el dominio de rebote debe coincidir con tu dominio From:.
3. Probar la alineación estricta: envía un correo de prueba y verifica los encabezados. Los campos d= (DKIM) y Return-Path deben coincidir con el dominio From:.
4. Empezar en relajado, pasar a estricto: publica adkim=r primero, valida los informes y luego pasa a adkim=s.

Cómo migrar a DMARCbis en seis pasos progresivos

La buena noticia: la migración es progresiva. Tus registros DMARC actuales siguen siendo funcionales. Estos son los pasos recomendados.

Paso 1: auditar tus registros actuales

Identifica todos tus dominios y subdominios que publican un registro _dmarc. Anota los tags utilizados, en particular pct, ri y rf.

Ejemplo de registro existente:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Antes de modificar la zona, pasa cada registro existente por el DMARC Validator para detectar una etiqueta mal formada o un URI rua/ruf inválido: no tiene sentido migrar un registro que ya era ignorado silenciosamente.

Paso 2: eliminar los tags obsoletos

Elimina pct, ri y rf de tus registros. Estos tags serán ignorados por los receptores DMARCbis y no aportan nada a los receptores v1.

Registro limpio:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Paso 3: activar el modo testing si es necesario

Si estás preparando un paso de quarantine a reject, usa t=y para probar primero:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Con t=y, los receptores DMARCbis aplicarán quarantine en lugar de reject. Los informes reflejarán este modo test. Tras la validación (2 a 4 semanas de informes limpios), elimina t=y o pasa a t=n.

Recordatorio: los receptores DMARC v1 ignorarán t=y y aplicarán p=reject directamente. No es un bug: es el comportamiento esperado.

Paso 4: proteger los subdominios inexistentes

Agrega np=reject para bloquear la suplantación desde subdominios que no existen en tu DNS:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Paso 5: verificar la alineación DKIM

DMARCbis recomienda adkim=s (estricto) para los dominios donde controlas la firma DKIM. La alineación estricta impide que un subdominio reutilice la firma de un dominio padre.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Paso 6: validar las autorizaciones de reporting externo

Si tus direcciones rua o ruf apuntan a un dominio diferente del dominio DMARC, verifica que el registro de autorización exista:

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Errores comunes de migración

Siete trampas aparecen regularmente durante la migración a DMARCbis. Conocerlas te evitará sorpresas en producción.

1. Publicar t=y sin entender el comportamiento v1. Los receptores DMARC v1 (todavía la mayoría en junio de 2026) ignoran t=y porque es un tag desconocido. Aplican p=reject directamente, sin retrogradación. Este comportamiento está previsto por diseño, pero suele sorprender a los administradores que esperan un modo test universal.

2. Mantener pct=0 con t=y. Esta combinación crea un comportamiento incoherente. Los receptores v1 aplican pct=0 (sin enforcement). Los receptores DMARCbis ignoran pct y aplican t=y (enforcement retrogradado). Resultado: dos poblaciones de receptores con comportamientos diferentes. Solución: elimina pct antes de agregar t.

3. Tree Walk produciendo un dominio organizacional diferente al del PSL. Algunos TLD poco comunes tienen una entrada PSL que no está actualizada. El Tree Walk puede entonces identificar un dominio organizacional diferente al determinado por el antiguo mecanismo PSL. Mitigación: publica un registro _dmarc explícito con psd=n a nivel de tu dominio organizacional.

4. Olvidar los registros de autorización de reporting externo. Cuando cambias de proveedor de monitoreo DMARC, los antiguos registros _dmarc-report._report apuntan al antiguo proveedor. Los informes cesan silenciosamente sin mensaje de error. Actualiza estos registros con cada cambio de proveedor.

5. No probar el impacto de np=reject. Esta política puede afectar a servicios legítimos que usan subdominios dinámicos. Algunos CDN, plataformas de marketing o herramientas de campaña crean subdominios al vuelo. Verifica que estos servicios no envíen correo desde subdominios no registrados en tu DNS.

6. Confiar en los informes de fallo (ruf). Los grandes proveedores (Google, Yahoo, Microsoft) han prácticamente dejado de enviar informes de fallo por razones de privacidad y cumplimiento RGPD. Usa los informes agregados (rua) como fuente principal de análisis. Los informes de fallo son un complemento, no una base fiable.

7. Planificar un despliegue progresivo sin pct. Con pct eliminado en DMARCbis, el despliegue por porcentaje ya no existe. Las opciones son t=y (retrogradación completa) o enforcement completo (sin t o t=n). Usa t=y con ventanas de monitoreo manuales de 2 a 4 semanas para reproducir un despliegue progresivo.

DMARCbis y la conformidad regulatoria

Conformidad anti-phishing y norma de pago

La versión 4.0 de PCI DSS (aplicable desde marzo de 2025) exige controles anti-phishing para las entidades que procesan pagos. DMARC en modo enforcement (quarantine o reject) forma parte de las medidas esperadas. DMARCbis refuerza esta postura con np=reject (protección de subdominios inexistentes) y la recomendación de alineación estricta DKIM.

Las exigencias de Google y Yahoo para el envío masivo

Desde febrero de 2024, Google y Yahoo exigen DMARC para los remitentes de más de 5 000 mensajes por día. Aunque estos proveedores aún no han implementado DMARCbis, reconocerán los registros limpios (sin pct, ri, rf) ya que estos tags ya son ampliamente ignorados.

Microsoft y Exchange Online

Microsoft aplica progresivamente verificaciones DMARC más estrictas en Exchange Online y Outlook. La adopción de DMARCbis por parte de Microsoft aún no ha sido anunciada, pero la preparación anticipada evitará ajustes de último momento.

Adopción actual (junio de 2026)

La adopción del lado de los receptores es todavía marginal. Solo United Internet AG (GMX, mail.com, WEB.DE) emite informes en formato DMARCbis (3 reporters de 3 493 en los datos observados). Google, Microsoft, Yahoo y Amazon SES aún no han migrado. Es el momento de preparar tus registros: cuando los grandes proveedores hagan la transición, estarás listo.

Plan de acción: preparar la transición

1. Inventariar todos los dominios y subdominios que publican un registro _dmarc. Identificar los Author Domains reales y las zonas sin registro DMARC.
2. Probar con el DMARCbis Checker la compatibilidad de cada dominio. Identificar los tags obsoletos y las recomendaciones específicas.
3. Limpiar tus registros: eliminar pct, ri, rf. Conservar v=DMARC1.
4. Agregar np=reject a nivel del dominio organizacional para proteger los subdominios inexistentes.
5. Usar t=y para toda escalada de política (paso de quarantine a reject).
6. Reforzar la alineación: apuntar a adkim=s como prioridad, mantener aspf=r salvo necesidad estricta.
7. Validar las autorizaciones externas si tus direcciones rua/ruf apuntan a un tercero.
8. Monitorizar los informes agregados durante 2 a 4 semanas tras cada cambio para detectar anomalías.

FAQ

¿Hay que cambiar v=DMARC1 por v=DMARC2?

No. La versión del registro sigue siendo v=DMARC1. DMARCbis no modifica el tag de versión. Tus registros existentes siguen funcionando sin ninguna modificación del tag v.

¿Qué es el DNS tree walk?

El DNS Tree Walk es el algoritmo DMARCbis que reemplaza la Public Suffix List para descubrir la política DMARC aplicable a un dominio. Consulta el DNS ascendiendo etiqueta por etiqueta desde el dominio remitente (Author Domain), con un límite de 8 consultas, hasta encontrar un registro _dmarc que identifique el dominio organizacional mediante el tag psd.

¿Desaparece la PSL por completo?

Sí, desde el punto de vista de DMARCbis. El descubrimiento de política y la determinación del dominio organizacional pasan íntegramente por el DNS Tree Walk. La Public Suffix List ya no se referencia en el estándar. Algunos receptores podrán mantener un fallback PSL durante la transición, pero no es obligatorio.

¿Por qué se eliminó el tag pct?

En la práctica, solo se usaban los valores 0 (modo test) y 100 (aplicación completa). El comportamiento para valores intermedios variaba entre receptores, haciendo el resultado impredecible. El tag t=y/n lo reemplaza con una semántica binaria clara: o la política se retrograda un nivel (test), o se aplica normalmente.

¿Mi registro DMARC actual es compatible con DMARCbis?

Sí, siempre que el tag v=DMARC1 esté presente. DMARCbis es retrocompatible. Los tags pct, ri y rf serán ignorados por los receptores DMARCbis, sin provocar errores. La migración recomendada consiste en eliminarlos y adoptar progresivamente np, psd y t.

¿Puedo publicar p=reject para todos mis dominios?

DMARCbis desaconseja p=reject para los dominios de uso general (listas de distribución, alias, redirecciones). Reserva p=reject para los dominios donde controlas cada intermediario de extremo a extremo. Para los demás casos, p=quarantine sigue siendo lo recomendado. Los receptores no deben rechazar un mensaje únicamente porque p=reject está publicado: deben cruzar con otras señales (ARC, reputación, listas de distribución).

¿El tag t=y es arriesgado durante la transición?

Hay un riesgo calculado. Los receptores DMARC v1 ignoran t=y (tag desconocido) y aplican la política tal cual. Si publicas p=reject; t=y, un receptor v1 aplicará reject sin retrogradación. Un receptor DMARCbis aplicará quarantine. Este comportamiento es intencional: favorece la seguridad por defecto. Usa t=y únicamente si aceptas que la política estricta se aplique en los receptores que aún no han migrado.

¿Quién debe usar el tag psd?

Únicamente los operadores de sufijos públicos: registros de TLD (co.uk, com.au, gouv.fr), registros sectoriales y las grandes organizaciones que delegan subdominios a entidades independientes. Para un dominio empresarial estándar, deja psd ausente o indica psd=n.

¿Cuándo implementarán DMARCbis los grandes proveedores?

Ninguna fecha ha sido anunciada públicamente (junio de 2026). La adopción del lado de los receptores es marginal: solo United Internet AG (GMX, mail.com, WEB.DE) emite informes en formato DMARCbis. La publicación de las RFC 9989/9990/9991 en mayo de 2026 debería acelerar la implementación en los grandes proveedores. Preparar tus registros ahora te posiciona con ventaja.

¿Cómo funciona la cadena de fallback np, sp, p?

Cuando un receptor DMARCbis recibe un correo desde un subdominio, primero verifica si ese subdominio existe en el DNS. Si no existe (NXDOMAIN), se aplica la política np. Si np no está definido, el receptor usa sp. Si sp tampoco está definido, se aplica p. Para los subdominios existentes, el fallback es sp y luego p (idéntico a DMARC v1).

¿DMARCbis ralentiza el procesamiento de correos?

No. El Tree Walk agrega 1 a 2 consultas DNS para un dominio típico de 3 etiquetas. La caché DNS atenúa este impacto: los registros _dmarc y las respuestas NXDOMAIN se almacenan en caché. El límite de 8 consultas garantiza un tiempo de procesamiento acotado, incluso para dominios profundos. En la práctica, la diferencia de latencia es insignificante.

¿Mi ESP debe soportar DMARCbis?

DMARCbis es un cambio del lado del receptor. Tu ESP no necesita soportarlo específicamente. Sin embargo, verifica dos puntos críticos: la firma DKIM personalizada (con d= correspondiente a tu dominio) y el Return-Path personalizado (dominio de rebote alineado con tu dominio From:). Estos dos elementos son indispensables para la alineación estricta recomendada por DMARCbis.

Glosario

• Author Domain: dominio utilizado en el encabezado From: del mensaje. Es el punto de partida del Tree Walk y de la alineación DMARC.
• DNS Tree Walk: algoritmo DMARCbis que asciende por el árbol DNS etiqueta por etiqueta para encontrar un registro _dmarc y determinar el dominio organizacional. Límite de 8 consultas.
• Organizational Domain: dominio principal de una organización, identificado por el Tree Walk (mediante psd=n o ausencia de psd). Tiene autoridad sobre la política DMARC aplicable a sus subdominios.
• PSL (Public Suffix List): lista mantenida por Mozilla de los sufijos públicos. Utilizada por DMARC v1, reemplazada por el Tree Walk en DMARCbis.
• PSD (Public Suffix Domain): sufijo de nombre de dominio operado por una entidad que delega subdominios (ej: co.uk, gouv.fr). Identificado por psd=y en el registro DMARC.
• PSO (Public Suffix Operator): entidad que administra un PSD y puede publicar una política DMARC de referencia para los dominios asociados.

Guías de autenticación de email relacionadas

• DKIM2: todo lo que cambia
• ARC: la cadena de autenticación explicada
• BIMI, VMC, CMC: compatibilidad DNS
• Gmail Bulk Sender 2025

Fuentes

1. RFC 9989: DMARC core (DMARCbis)
2. RFC 9990: DMARC Aggregate Reporting
3. RFC 9991: DMARC Failure Reporting
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)