DMARCbis es ahora un Estándar Propuesto por el IETF. Reemplazará RFC 7489 y RFC 9091. Tus registros existentes siguen usando v=DMARC1.
Empieza a planificar ahora para estar listo cuando se publique.
¿Qué es DMARCbis?: Un repaso rápido
DMARCbis mantiene el mismo objetivo. Permite especificar qué fuentes de envío que usan tu dominio son legítimas y cómo deben manejar los receptores los correos que no pasen esas comprobaciones. La actualización aclara la especificación, formaliza la conformidad y cambia cómo se encuentra el dominio organizativo usando un Tree Walk de DNS en lugar de la Public Suffix List.
¿Qué cambia realmente y cómo ayuda en dominios complejos?:
- El descubrimiento y la alineación son más claros: Los receptores buscan un registro DMARC en el Author Domain, después en el Organisation Domain y finalmente en el Public Suffix Domain. DMARCbis define el Tree Walk usado tanto para el descubrimiento de políticas como para la alineación.
- Public Suffix List (PSL) fuera; Tree Walk dentro: El Tree Walk reemplazará las búsquedas con PSL, permitiendo límites consistentes aunque existan subdominios anidados y registros PSD.
- La conformidad es explícita: Para una participación completa en DMARC, necesitas publicar registros para cada Author y Organisational Domain, enviar correo que se alinee vía SPF y DKIM, y consumir los reportes agregados.
- Mejor para DNS descentralizado: Los registros pueden publicarse en varios niveles. Para nombres de host muy profundos, añade un registro en el Author Domain para que se encuentre antes del recorrido.
Tus actualizaciones están en las etiquetas
Usa la tabla a continuación para mapear de viejo a nuevo: pon [t] para pruebas, usa [np] si quieres una regla para nombres inexistentes, pon [psd] solo si gestionas un public suffix, elimina [pct], [rf], [ri], y mantén [v=DMARC1].
Resumen de etiquetas
Etiqueta | Significado simple | Cuándo usarla | Opciones | Ejemplo |
[t] | Señal de modo de prueba para la política que defines en p, sp o np | Actívalo mientras haces pruebas; desactívalo para el funcionamiento normal | [y] prueba habilitada; no aplica la política especificada pero sí reglas de manejo especial | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[psd] | Marca un registro como publicado por un Public Suffix Operator, y guía el Tree Walk | Solo ponlo si gestionas un dominio public suffix (registro o similar). La mayoría de dominios no necesitarán declarar esta etiqueta | [y] = el dominio es un PSD [n] = el dominio no es un PSD | v=DMARC1; p=quarantine; psd=y; rua=mailto:dmarc@example.com |
[np] | Política para correos que usan nombres que no existen bajo tu dominio | Úsalo si quieres una regla explícita para subdominios falsos o con errores tipográficos | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[rf], [ri] | Pistas antiguas sobre el formato de los informes de fallos y el intervalo de informe agregado | Elimina de los registros antiguos | - | - |
[pct] | Control de despliegue porcentual antiguo | Reemplaza por pruebas [t], no uses en registros nuevos | - | Ver abajo |
Prepárate para DMARCbis con Red Sift OnDMARC
[Pct] -> [t] correspondencia
- [pct=0] -> usar [t=y]
- [pct=100] -> omitir la etiqueta, no es necesario declarar t=n explícitamente
- [pct=1-99] -> no hay equivalente directo; usa [t=y] y gestiona el riesgo en pruebas (por ejemplo, en dominios de menor impacto).
Actualización de registros DMARCbis: 5 comprobaciones rápidas
1. Encuentra tus registros
Enumera el registro DMARC de tu Organisational Domain y cualquier registro en subdominios clave. Anota cualquier etiqueta antigua pct, rf o ri. Estas están deprecadas en DMARCbis.
2. Actualiza la sintaxis de etiquetas
Si aún no tienes pct=100, reemplaza pct por la nueva bandera de prueba t. pct igual a cero corresponde a t igual a y. Si tienes pct=100, puedes eliminar la etiqueta pct. Elimina rf y ri. Deja fuera psd salvo que realmente gestiones un dominio public suffix. Mantén v igual a DMARC1.
3. Establece el alcance de la política
Define p para el dominio base y sp para los subdominios existentes. Añade np si quieres una regla para correos a nombres que no existen, por ejemplo np igual a reject. Si falta np, los receptores recurren a sp y luego a p.
4. Elige modos de alineación
Utiliza adkim y aspf. (r significa relaxed y s significa strict). Elige strict si quieres coincidencias exactas entre el dominio autenticador y tu dominio en From.
5. Revisa el reporte
Mantén rua para reportes agregados. Usa ruf con fo solo si necesitas detalles de fallas por mensaje. Muchos receptores no envían reportes de fallos y algunos los rechazan por razones de privacidad. Tenlo en cuenta.
¿Por qué Red Sift OnDMARC?
DMARCbis cambia cómo se encuentra la política y qué etiquetas debes usar. Red Sift OnDMARC soporta esto de forma nativa, uniendo DMARC, SPF y DKIM para que puedas implementar la actualización rápidamente.
- Todo en un único lugar para DMARC, SPF, DKIM - Edita registros uno al lado del otro, revisa resultados de alineación [adkim/aspf] y soluciona las brechas que impiden la aplicación.
- Preparado para Tree Walk - Visualiza el nodo donde el recorrido pasará (Author -> Org -> PSD) y dónde publicar en subdominios profundos.
- Actualizaciones paso a paso - Usa [t], [np], [psd]; elimina [pct], [rf], [ri]; mantén [v=DMARC1]. El sistema te guía en cada paso.
- SPF a escala - SPF dinámico gestiona el límite de 10 búsquedas con un único include que se expande en tiempo de consulta.
- Despliegue seguro - Simula don’t [t=y] (un nivel más suave) antes de activar, luego aplica cambios en masa a través de marcas y regiones.
- Informe claro - Vistas agregadas resaltan desalineaciones por fuente para que sepas qué corregir a continuación.
Habla con nuestro equipo para revisar rápidamente tus registros y haz una comprobación Investigate gratuita para ver qué informan los receptores sobre tu dominio.