DMARCbis cambia cómo partes de DMARC están especificados e implementados. No le pide que cambie el nombre de su registro a DMARC2. La especificación central, RFC 9989, se publicó en mayo de 2026, mientras que RFC 9990 y RFC 9991 cubrir los informes agregados y de fallas por separado.
La tarea práctica es determinar qué cambios afectan a su dominio, a sus servicios de envío y al software que procesa sus datos de autenticación. Eso comienza con la comprensión de las especificaciones actuales y luego compararlas con la configuración y los procesos que ya están en uso. El resultado debe ser un registro de preparación claro con evidencia, propietarios y una decisión para cada hallazgo.
Asigne las tres especificaciones a sus sistemas
Utilice los documentos vigentes para sus respectivos trabajos:
| Documento | Que revisar |
|---|---|
| RFC 9989 | Evaluación central DMARC , descubrimiento de políticas, alineación y registrar la semántica |
| RFC 9990 | Formato, generación y procesamiento de informes agregados |
| RFC 9991 | Informes de fallas y consideraciones sobre su manejo. |
Comience con el registro existente y el historial de configuración. No elimine un registro operativo simplemente porque una guía anterior cita RFC 7489. Identifique las instrucciones que cambiaron y el software que las implementa.
Las principales áreas de revisión incluyen las siguientes:
- Descubrimiento de dominio: RFC 9989 sección 4.10 define el recorrido del árbol DNS . Revisar los sistemas que asumen un modelo de descubrimiento de lista pública de sufijos más antiguo.
- Etiquetas de política: Consulte el registro actual IANA . El
pct,rfyRhode IslandLas etiquetas son históricas. Evaluart,notario públicoypsdpor su alcance real en lugar de agregarlos como una lista de verificación de actualización. - Pruebas: Establecer cómo el evaluador relevante implementa el binario.
tseñal. Un estado de prueba declarado y la disposición final del receptor son observaciones diferentes. - Informes: Confirme que los recopiladores y analizadores manejen los formatos y campos de informes que espera recibir, sin perder observaciones heredadas relevantes.
El marcador de versión permanece v=DMARC1. No sustituir DMARC2 o reemplazar mecánicamente un porcentaje antiguo con una bandera de prueba.
Traducir las etiquetas modificadas en pruebas.
El t la bandera por defecto es n, solicitando la aplicación de la evaluación declarada a fallos DMARC . Configuración t=y indica que el propietario está probando en lugar de solicitar que la evaluación declarada se aplique directamente. RFC 9989 sección 4.7 define una reducción de un nivel para los mensajes fallidos: el rechazo se convierte en cuarentena y la cuarentena se convierte en ninguna. Las implementaciones también pueden tener un manejo especial relevante.
La bandera no cambia un resultado de autenticación fallido en un pase, no altera la generación de informes ni afecta una política de ninguno. Es binario, no una solicitud para muestrear un porcentaje arbitrario de correo. Establezca soporte de implementación antes de confiar en él para el tráfico real y mantenga el filtrado local del receptor separado del resultado de la prueba a nivel de política.
Otras dos etiquetas afectan el alcance de la evaluación:
- notario público: Especifica la evaluación de subdominios inexistentes del prevaleciente. dominio organizacional. Si está ausente, el respaldo aplicable es sp cuando está presente; de lo contrario, p. un desaparecido registro MX por sí solo no establece la inexistencia.
- psd: Marca la información de límites de dominio utilizada durante el descubrimiento. El valor predeterminado u deja la determinación de límites a las reglas de descubrimiento; y identifica un sufijo público, mientras que n identifica un límite organizacional con sufijo no público para sí mismo y sus subdominios. No establezca ningún valor de límite explícito sin establecer que describe el dominio correctamente.
Una organización ordinaria no debería etiquetar su dominio como un sufijo público simplemente para afirmar que está preparada. Revise las suposiciones de descubrimiento reales y los espacios de nombres delegados. El guía de políticas de subdominio cubre la cuestión más específica de la herencia.
Identificar el correo que debe seguir funcionando
Un dominio puede representar mucho más que el correo electrónico de los empleados. Puede aparecer en facturas, enlaces de inicio de sesión, alertas de clientes y mensajes enviados por agencias externas. Una actualización de estándares es una oportunidad para verificar esas dependencias antes de que un cambio de configuración apresurado las interrumpa.
Solicite tres entregables: un inventario de los servicios que utilizan su identidad, una explicación de los cambios específicos que le afectan y un plan de prueba para mensajes críticos. La respuesta debe distinguir una especificación publicada de una característica ya implementada por un receptor o servicio de software en particular.
Asigne la propiedad y el presupuesto. Un cambio en el procesamiento de informes necesita a alguien responsable del proceso de generación de informes. Un remitente que no puede autenticarse correctamente necesita que el propietario de su empresa participe. Llamar a ambos elementos una actualización DNS oculta el trabajo.
Crear un registro de preparación
El siguiente es un registro de planificación ilustrativo, no una evaluación de un dominio real:
| Descubrimiento | Trabajo requerido | Prueba de finalización |
|---|---|---|
| Las instrucciones de implementación asumen un muestreo porcentual | Pruebe la bandera binaria usando los dispositivos controlados a continuación | Evaluación declarada registrada, evaluación después del indicador de prueba y decisión del receptor independiente |
| El analizador de informes asume un esquema heredado | Revisar los formatos aceptados, los campos y el manejo de errores. | Accesorios versionados válidos, heredados y con formato incorrecto |
| La aplicación crítica no tiene propietario conocido | Establecer el servicio empresarial y las identidades admitidas. | Propietario designado y muestra de mensaje recibido verificado |
| El editor DNS está controlado por un equipo subcontratado | Acordar las responsabilidades de aprobación y recuperación. | Vista previa del cambio exacto, aprobación y material de restauración. |
Los siguientes accesorios sintéticos especifican los resultados esperados para un evaluador controlado que implementa RFC 9989 . Son entradas de prueba, no plantillas de registros de producción ni pruebas ya realizadas. Supongamos que se descubre una política aplicable válida y el mensaje de prueba falla DMARC .
| Artículos fijos | Aporte | Observación esperada a nivel de políticas |
|---|---|---|
| Bandera de prueba | p=reject; t=y | La validación sigue siendo fallida; La evaluación después de t=y es cuarentena, en lugar del rechazo declarado. |
| Bandera en ninguno | p=none; t=y | La bandera deja sin cambios el comportamiento de ninguna evaluación y generación de informes. |
| niño inexistente | Una política prevaleciente en el dominio organizacional tiene p=none; sp=quarantine; np=reject, con t=n; el niño se establece como inexistente y no tiene una política directa | La evaluación del niño aplicable es el rechazo, en lugar del valor sp del niño existente. |
Capture la versión del evaluador, los aportes, la validación observada, la evaluación seleccionada y cualquier manejo final por separado. Un dispositivo controlado establece el comportamiento probado; no prueba que todos los receptores de Internet implementen las mismas reglas. Una observación de cuarentena a nivel de políticas no es una promesa universal de colocación en carpetas de spam.
Revise también la idoneidad de las políticas. RFC 9989 sección 7.4 desaconseja el rechazo de dominios de correo electrónico de propósito general porque las rutas indirectas legítimas, incluidas las listas de correo, pueden romperse. Una revisión de la preparación debería identificar esas rutas y evaluar la orientación de interoperabilidad aplicable antes de proponer una política más sólida.
Mantenga los cambios de configuración separados de los cambios de software o procesos. Algunos hallazgos no necesitan una edición DNS inmediata. Otros requieren una actualización del proveedor, una corrección del analizador o una prueba de implementación controlada.
Verifique la interoperabilidad y los límites de un reclamo de preparación
Una afirmación de preparación debe nombrar su alcance. ¿Cubre la cartera de dominios, el evaluador de políticas, el procesador de informes o solo un récord ¿controlar? Son valoraciones distintas.
Utilice el registro para realizar un seguimiento de las versiones de implementación y las diferencias no resueltas. Seleccione casos aplicables de subdominios existentes y no existentes, modos de alineación, correo indirecto y fallas DNS .
Trate la discreción del receptor como parte del modelo operativo. La publicación de una especificación no hace que todos los receptores se comporten de manera idéntica. Una preferencia de rechazo publicada tampoco es prueba de que todos los destinatarios rechazaron todos los mensajes fallidos.
Mantenga controles independientes para cuentas comprometidas, nombres para mostrar engañosos, dominios similares y aprobaciones comerciales confidenciales. La preparación DMARC no convierte la autenticación de dominio en un veredicto sobre la seguridad del contenido de un mensaje.
Realizar y verificar los cambios requeridos
Ante un cambio de producción, preservar el estado anterior, identificar los flujos afectados, obtener la aprobación adecuada y definir las condiciones de recuperación. Luego verifique tanto la configuración publicada como los mensajes representativos a través de la ruta de envío completa.
Si un resultado no coincide con el comportamiento esperado, suspenda la expansión a otros dominios y resuelva o acepte explícitamente el hallazgo de compatibilidad.
Para las identidades subyacentes, utilice el guía de diagnóstico de alineación. Para una configuración inicial, siga el flujo de trabajo de creación y verificación DMARC. Para la capa de informes, utilice el tutorial del informe agregado.
La conclusión práctica
Cerrar la evaluación cuando cada hallazgo aplicable tenga dueño, decisión sustentada y evidencia reproducible. Mantenga visibles las diferencias de implementación no resueltas, verifique los mensajes críticos y el procesamiento de informes, y conserve las condiciones de recuperación aprobadas. Una etiqueta de preparación debe señalar ese registro, no reemplazarlo.