DMARCbis: la guia completa para entender y migrar al nuevo estandar DMARC

⚡TL;DR

• DMARCbis reemplaza DMARC (RFC 7489) y se convierte en Proposed Standard IETF. Los tres documentos estan en la cola del RFC Editor, y se espera su publicacion a lo largo de 2026.
• El DNS Tree Walk reemplaza la Public Suffix List: el descubrimiento del dominio organizacional se realiza mediante consultas DNS sucesivas (max 8), sin depender de una lista externa.
• Tres tags agregados: psd (marcador Public Suffix Domain), np (politica 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 validos (v=DMARC1). La migracion consiste en eliminar los tags obsoletos y adoptar los nuevos de forma progresiva.

DMARC protege los dominios contra la suplantacion de identidad por correo electronico desde 2015. Pero la RFC 7489 tenia debilidades estructurales: dependencia de una lista externa (la Public Suffix List), un tag pct mal comprendido y mal implementado, ningun mecanismo para los subdominios inexistentes.

DMARCbis corrige estos problemas. No es una simple actualizacion: 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) estan en la cola del RFC Editor desde finales de 2025. La publicacion es inminente.

Esta guia esta dirigida a administradores de sistemas, responsables de correo e ingenieros de seguridad que necesitan entender los cambios y preparar la migracion. Aqui encontraras el funcionamiento detallado del DNS Tree Walk, un comparativo completo de los tags, un plan de migracion y las implicaciones de conformidad (PCI DSS 4.0, Google, Yahoo, Microsoft).

Un glosario al final del articulo define los terminos tecnicos: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

¿Que es DMARCbis?

DMARCbis es el sucesor de DMARC tal como lo definia la RFC 7489. El termino "bis" sigue la convencion IETF para designar la segunda iteracion de un protocolo. En concreto, DMARCbis agrupa tres documentos normativos:

• draft-ietf-dmarc-dmarcbis: el documento base (descubrimiento de politica, alineacion, tags)
• draft-ietf-dmarc-aggregate-reporting: los informes agregados XML
• draft-ietf-dmarc-failure-reporting: los informes de fallo (mensaje por mensaje)

¿Por que esta reforma?

La RFC 7489, publicada en 2015, tenia el estatus "Informational". Esto significa que DMARC no era un estandar de Internet en sentido estricto. DMARCbis corrige esta anomalia convirtiendose en un Proposed Standard, lo que le otorga peso normativo en el ecosistema IETF.

Las motivaciones tecnicas son precisas:

1. La Public Suffix List es fragil. 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 inutil. En la practica, 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 podia enviar desde falso.subdominio.captaindns.com sin que DMARC se aplicara.
4. PSD DMARC (RFC 9091) seguia siendo experimental. DMARCbis integra y reemplaza esta extension unificando el modelo mediante el tag psd y el Tree Walk.

Cronologia 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)
Q1/Q2 2026	Publicacion esperada como Proposed Standard

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

El tree walk DNS: el fin del PSL

El cambio mas 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 publicos (co.uk, com.au, gouv.fr). El receptor restaba el sufijo publico del dominio para identificar la organizacion.

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 esta estandarizado: cada implementacion gestiona la lista de forma diferente
• Ninguna autoridad DNS valida la exactitud de la lista

¿Como funciona el tree walk?

El Tree Walk consulta directamente el DNS para descubrir la politica 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 ningun registro, eliminar la etiqueta mas a la izquierda y repetir.
3. Si se encuentra un registro con psd=y, el dominio organizacional esta un nivel por debajo del dominio actual.
4. Si se encuentra un registro con psd=u, continuar la ascension.
5. Repetir hasta encontrar un resultado o alcanzar el limite de 8 consultas DNS.

Salida: el dominio organizacional y la politica 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 mas de 8 etiquetas, el algoritmo salta directamente a 7 etiquetas tras la primera consulta, y luego asciende etiqueta por etiqueta. El limite de 8 consultas garantiza que el proceso termine.

Comparacion entre el PSL y el tree walk

Aspecto	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Fuente de verdad	Lista estatica (Mozilla)	El propio DNS
Actualizacion	Descarga periodica	Tiempo real mediante consultas DNS
Cobertura	Manual, potencialmente incompleta	Todo dominio que publique un registro _dmarc
Deteccion PSD	Busqueda en la lista	Tag psd=y en el registro DNS
Estandarizacion	Proyecto comunitario, no normativo	Standards Track IETF

Rendimiento del tree walk

Para un dominio tipico de 3 etiquetas (como newsletter.captaindns.com), el Tree Walk agrega como maximo 1 consulta DNS adicional respecto a DMARC v1. El limite de 8 consultas garantiza que los dominios profundos no causen sobrecarga.

La cache DNS atenua el impacto en la practica. Los registros _dmarc del dominio organizacional se almacenan en cache tras la primera consulta. Las respuestas NXDOMAIN tambien se almacenan en cache segun el TTL del campo MINIMUM del SOA. Un dominio que recibe miles de mensajes por hora solo generara un punado de consultas Tree Walk efectivas.

En comparacion, el enfoque PSL no generaba ninguna consulta DNS para el descubrimiento. Pero requeria la descarga periodica de una lista de aproximadamente 250 Ko y su mantenimiento en memoria.

Recomendacion de TTL: publica tus registros _dmarc con un TTL de al menos 3600 s. Un TTL de 86400 s reduce aun mas la carga DNS. Esto es particularmente util 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 version (v=DMARC1) y los tags fundamentales (p, sp, adkim, aspf, fo) permanecen sin cambios.

Tags agregados

El tag psd: marcador de sufijo publico

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 continua la ascension.

Valor por defecto: u (undetermined).

¿Quien debe usarlo? Unicamente los operadores de sufijos publicos (registros TLD, registros sectoriales). Para un dominio estandar, 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: politica para subdominios inexistentes

El tag np cubre un punto ciego de DMARC v1: los subdominios que no existen en el DNS. Un atacante podia enviar desde falso.captaindns.com sin politica aplicable si no existia ningun registro _dmarc a ese nivel.

Con np, el dominio organizacional puede declarar una politica especifica para estos casos. Los valores son identicos a p: none, quarantine, reject.

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

El receptor verifica la existencia del subdominio mediante DNS. Si el DNS devuelve NXDOMAIN, se aplica la politica 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 semantica es binaria:

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

El modo testing no afecta al reporting: los informes agregados se envian normalmente, lo que permite monitorizar los resultados antes de aplicar la politica estricta.

Punto critico para la transicion: los receptores DMARC v1 ignoran los tags desconocidos. Si publicas p=reject; t=y, un receptor que aun no implemente DMARCbis aplicara reject sin tener en cuenta t=y. Este comportamiento es por diseno: garantiza que la politica mas estricta se aplique por defecto.

Tags eliminados

Tag	Razon de la eliminacion	Reemplazo
pct	En la practica, solo se usaban los valores 0 y 100. El comportamiento variaba entre implementaciones.	t=y para el modo test, eliminacion para el resto
ri	El intervalo de reporting estaba estandarizado de facto en 24 h. Los receptores ignoraban los demas valores.	Gestionado por el documento Aggregate Reporting
rf	Solo existia un formato (afrf). Ninguna alternativa se desplegó jamas.	Gestionado por el documento Failure Reporting

Si tus registros DMARC aun contienen pct, ri o rf, seguiran funcionando (los receptores los ignoraran). Pero se recomienda eliminarlos para evitar cualquier ambiguedad.

Tags modificados

rua (informes agregados): la sintaxis de limite de tamano (!10m) se elimina. La verificacion de destino externo se refuerza: si el dominio de la direccion rua difiere del dominio DMARC, debe existir un registro de autorizacion _dmarc-report._report.<rua-domain>.

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

Tabla recapitulativa v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Estado
v	DMARC1	DMARC1	Sin cambios
p	none / quarantine / reject	Identico	Sin cambios
sp	Politica subdominios	Identico	Sin cambios
adkim	r / s	Identico	Sin cambios
aspf	r / s	Identico	Sin cambios
fo	0 / 1 / d / s	Identico	Sin cambios
rua	URIs con limite de tamano	URIs sin limite, verificacion 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: politica, 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>: politica para subdominios inexistentes
• Nuevo campo <discovery_method>: como se descubrio la politica (Tree Walk vs directo)
• Nueva disposicion pass: agregada a las disposiciones posibles
• Eliminacion de sampled_out: la razon 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 direccion.

Los informes de fallo

Los informes de fallo ahora estan cubiertos por un documento separado. Este cambio refleja la realidad: la mayoria 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 envio es apropiado.

Otros cambios notables

• SPF restringido a MAIL FROM: DMARCbis elimina la verificacion SPF basada en HELO/EHLO. Solo el dominio MAIL FROM se evalua para la alineacion.
• Directrices reforzadas sobre p=reject: los dominios con p=reject deben usar DKIM (no solo SPF). Los receptores no deben rechazar unicamente sobre la base de p=reject sin evaluacion DKIM/SPF. Los dominios cuyos usuarios publican en listas de distribucion no deberian publicar p=reject.

DMARCbis y las listas de distribucion

Las listas de distribucion son el caso de uso mas problematico para DMARC desde 2015. DMARCbis no resuelve el problema, pero lo documenta formalmente y refuerza las recomendaciones.

¿Por que las listas rompen la alineacion?

Una lista de distribucion modifica el mensaje en transito. El sobre SMTP cambia (nuevo MAIL FROM), lo que rompe la alineacion SPF. El contenido suele modificarse (agregar un prefijo al asunto, footer de desuscripcion), lo que invalida la firma DKIM. El resultado: un fallo DMARC sistematico para los dominios en p=reject.

DMARCbis refuerza formalmente la recomendacion: los dominios cuyos usuarios participan en listas de distribucion no deberian publicar p=reject. La politica 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 autenticacion. DMARCbis referencia ARC como mecanismo que los receptores PUEDEN usar para recuperar los resultados de autenticacion originales. Pero DMARCbis no hace ARC obligatorio. Es una opcion, no una garantia.

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 distribucion
• trusted_forwarder: reenviador de confianza identificado por el receptor
• local_policy: politica local del receptor (whitelist, reputacion)
• policy_test_mode: nuevo tipo, reemplaza sampled_out (eliminado con pct)

Estos tipos permiten comprender por que un receptor eligio no aplicar la politica publicada.

Consejo practico

Los softwares modernos de listas de distribucion (Mailman 3, Sympa) incluyen mitigaciones DMARC integradas. La mas comun: la reescritura del From: para usar la direccion de la lista en lugar de la direccion original. Si tu dominio es utilizado por listas, verifica que estas mitigaciones esten activadas. Y prefiere p=quarantine a p=reject.

DMARCbis y los proveedores de envio (ESP)

Ningun ESP importante (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) ha anunciado soporte especifico para DMARCbis en marzo 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 alineacion DKIM: el desafio critico

El desafio principal para los ESP sigue siendo la alineacion DKIM. Existen dos modos de firma:

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

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

SPF y el dominio de rebote

DMARCbis elimina la verificacion SPF basada en HELO/EHLO. Solo el dominio MAIL FROM (Return-Path) cuenta para la alineacion SPF. La mayoria de los ESP usan un dominio de rebote generico por defecto (ej: bounce.sendgrid.net). Este dominio no coincide con tu dominio From:, lo que hace fallar la alineacion SPF.

La solucion: configura un dominio de rebote personalizado (Return-Path) que coincida con tu dominio From:. La mayoria de los ESP ofrecen esta opcion 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 alineacion estricta: envia 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.

Como migrar a DMARCbis

La buena noticia: la migracion 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"

Paso 2: eliminar los tags obsoletos

Elimina pct, ri y rf de tus registros. Estos tags seran 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 estas 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 aplicaran quarantine en lugar de reject. Los informes reflejaran este modo test. Tras la validacion (2 a 4 semanas de informes limpios), elimina t=y o pasa a t=n.

Recordatorio: los receptores DMARC v1 ignoraran t=y y aplicaran p=reject directamente. No es un bug: es el comportamiento esperado.

Paso 4: proteger los subdominios inexistentes

Agrega np=reject para bloquear la suplantacion 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 alineacion DKIM

DMARCbis recomienda adkim=s (estricto) para los dominios donde controlas la firma DKIM. La alineacion 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 autorizacion exista:

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

Errores comunes de migracion

Siete trampas aparecen regularmente durante la migracion a DMARCbis. Conocerlas te evitara sorpresas en produccion.

1. Publicar t=y sin entender el comportamiento v1. Los receptores DMARC v1 (todavia la mayoria en marzo de 2026) ignoran t=y porque es un tag desconocido. Aplican p=reject directamente, sin retrogradacion. Este comportamiento esta previsto por diseno, pero suele sorprender a los administradores que esperan un modo test universal.

2. Mantener pct=0 con t=y. Esta combinacion 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. Solucion: 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 esta actualizada. El Tree Walk puede entonces identificar un dominio organizacional diferente al determinado por el antiguo mecanismo PSL. Mitigacion: publica un registro _dmarc explicito con psd=n a nivel de tu dominio organizacional.

4. Olvidar los registros de autorizacion 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 politica puede afectar a servicios legitimos que usan subdominios dinamicos. Algunos CDN, plataformas de marketing o herramientas de campana crean subdominios al vuelo. Verifica que estos servicios no envien correo desde subdominios no registrados en tu DNS.

6. Confiar en los informes de fallo (ruf). Los grandes proveedores (Google, Yahoo, Microsoft) han practicamente dejado de enviar informes de fallo por razones de privacidad y cumplimiento RGPD. Usa los informes agregados (rua) como fuente principal de analisis. 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 (retrogradacion 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 version 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 (proteccion de subdominios inexistentes) y la recomendacion de alineacion estricta DKIM.

Las exigencias de Google y Yahoo para el envio masivo

Desde febrero de 2024, Google y Yahoo exigen DMARC para los remitentes de mas de 5 000 mensajes por dia. Aunque estos proveedores aun no han implementado DMARCbis, reconoceran los registros limpios (sin pct, ri, rf) ya que estos tags ya son ampliamente ignorados.

Microsoft y Exchange Online

Microsoft aplica progresivamente verificaciones DMARC mas estrictas en Exchange Online y Outlook. La adopcion de DMARCbis por parte de Microsoft aun no ha sido anunciada, pero la preparacion anticipada evitara ajustes de ultimo momento.

Adopcion actual (marzo de 2026)

La adopcion del lado de los receptores es todavia 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 aun no han migrado. Es el momento de preparar tus registros: cuando los grandes proveedores hagan la transicion, estaras listo.

Plan de accion: preparar la transicion

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 especificas.
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 politica (paso de quarantine a reject).
6. Reforzar la alineacion: 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 anomalias.

FAQ

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

No. La version del registro sigue siendo v=DMARC1. DMARCbis no modifica el tag de version. Tus registros existentes siguen funcionando sin ninguna modificacion del tag v.

¿Que es el DNS tree walk?

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

¿Desaparece la PSL por completo?

Si, desde el punto de vista de DMARCbis. El descubrimiento de politica y la determinacion del dominio organizacional pasan integramente por el DNS Tree Walk. La Public Suffix List ya no se referencia en el estandar. Algunos receptores podran mantener un fallback PSL durante la transicion, pero no es obligatorio.

¿Por que se elimino el tag pct?

En la practica, solo se usaban los valores 0 (modo test) y 100 (aplicacion completa). El comportamiento para valores intermedios variaba entre receptores, haciendo el resultado impredecible. El tag t=y/n lo reemplaza con una semantica binaria clara: o la politica se retrograda un nivel (test), o se aplica normalmente.

¿Mi registro DMARC actual es compatible con DMARCbis?

Si, siempre que el tag v=DMARC1 este presente. DMARCbis es retrocompatible. Los tags pct, ri y rf seran ignorados por los receptores DMARCbis, sin provocar errores. La migracion 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 distribucion, alias, redirecciones). Reserva p=reject para los dominios donde controlas cada intermediario de extremo a extremo. Para los demas casos, p=quarantine sigue siendo lo recomendado. Los receptores no deben rechazar un mensaje unicamente porque p=reject esta publicado: deben cruzar con otras senales (ARC, reputacion, listas de distribucion).

¿El tag t=y es arriesgado durante la transicion?

Hay un riesgo calculado. Los receptores DMARC v1 ignoran t=y (tag desconocido) y aplican la politica tal cual. Si publicas p=reject; t=y, un receptor v1 aplicara reject sin retrogradacion. Un receptor DMARCbis aplicara quarantine. Este comportamiento es intencional: favorece la seguridad por defecto. Usa t=y unicamente si aceptas que la politica estricta se aplique en los receptores que aun no han migrado.

¿Quien debe usar el tag psd?

Unicamente los operadores de sufijos publicos: 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 estandar, deja psd ausente o indica psd=n.

¿Cuando implementaran DMARCbis los grandes proveedores?

Ninguna fecha ha sido anunciada publicamente (marzo de 2026). La adopcion del lado de los receptores es marginal: solo United Internet AG (GMX, mail.com, WEB.DE) emite informes en formato DMARCbis. La publicacion de las RFC probablemente desencadenara la implementacion en los grandes proveedores. Preparar tus registros ahora te posiciona con ventaja.

¿Como 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 politica np. Si np no esta definido, el receptor usa sp. Si sp tampoco esta definido, se aplica p. Para los subdominios existentes, el fallback es sp y luego p (identico a DMARC v1).

¿DMARCbis ralentiza el procesamiento de correos?

No. El Tree Walk agrega 1 a 2 consultas DNS para un dominio tipico de 3 etiquetas. La cache DNS atenua este impacto: los registros _dmarc y las respuestas NXDOMAIN se almacenan en cache. El limite de 8 consultas garantiza un tiempo de procesamiento acotado, incluso para dominios profundos. En la practica, la diferencia de latencia es insignificante.

¿Mi ESP debe soportar DMARCbis?

DMARCbis es un cambio del lado del receptor. Tu ESP no necesita soportarlo especificamente. Sin embargo, verifica dos puntos criticos: 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 alineacion 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 alineacion DMARC.
• DNS Tree Walk: algoritmo DMARCbis que asciende por el arbol DNS etiqueta por etiqueta para encontrar un registro _dmarc y determinar el dominio organizacional. Limite de 8 consultas.
• Organizational Domain: dominio principal de una organizacion, identificado por el Tree Walk (mediante psd=n o ausencia de psd). Tiene autoridad sobre la politica DMARC aplicable a sus subdominios.
• PSL (Public Suffix List): lista mantenida por Mozilla de los sufijos publicos. 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 politica DMARC de referencia para los dominios asociados.

Guias de autenticacion de email relacionadas

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

Fuentes

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)