Comience con un comportamiento, no con un registro de reemplazo
Una migración de estándares se vuelve manejable cuando cada decisión de implementación tiene una especificación nombrada y un propietario responsable. Un editor DNS , un alineación El motor y un analizador de informes agregados no realizan el mismo trabajo. Llamando a los tres”DMARC "soporte" oculta dependencias que importan cuando un componente cambia y otro permanece en una implementación anterior. El resultado práctico es un mapa de componentes a requisitos, con versiones, interfaces y evidencia de aceptación retenida, en lugar de una declaración de que todo el conjunto ha sido actualizado.
El conjunto de documentos actual se publicó en mayo de 2026. RFC 9989 define el mecanismo central y queda obsoleto RFC 7489 y RFC 9091 . RFC 9990 cubre informes agregados; RFC 9991 cubre informes de fallas y también actualiza RFC 6591 . Los registros nuevos del Editor RFC identifican RFC 9989 y RFC 9990 como Normas Propuestas. El texto RFC 9991 publicado identifica su categoría Standards Track. Estas son especificaciones publicadas, no borradores inacabados, pero la publicación no establece la implementación de un receptor en particular.
Dale al motor central un contrato preciso
Asignar análisis de registros, descubrimiento de políticas, descubrimiento de dominio organizacional y alineación de identificadores a RFC 9989 secciones 4.7–4.10. El dominio de autor proviene del dominio del mensaje. RFC5322 .De campo. Un dominio de políticas descubierto puede diferir de ese dominio de autor, y el dominio organizacional utilizado para la alineación relajada es otro resultado explícito. Perder esas distinciones en una interfaz puede hacer que un analizador correcto alimente un motor de decisión incorrecto.
El registro DNS todavía comienza con v=DMARC1. “DMARCbis" es un nombre para el trabajo de estándares, no un permiso para inventar DMARC2. El descubrimiento actual utiliza el árbol DNS delimitado en lugar de tratar una lista de verificación histórica de lista de sufijos públicos como el algoritmo completo. Las etiquetas psd, np y t requieren una cobertura de decisión separada. registro IANA marcas pct, rf y ri historic; no certifica si un producto implementado los ignora, interpreta o expone.
Preservar las distinciones entre una falla DMARC normal, información DNS no disponible, una política no válida y la disposición final del mensaje del receptor. La sección 4.10.1 RFC 9989 contiene un manejo especial para etiquetas de políticas no válidas cuando permanece un URI de informe agregado sintácticamente válido. Una regla simplista de que “toda política mal formada se convierte en ninguna” borraría sus condiciones. Registre la sección exacta al lado del caso del analizador que lo ejercita.
Trate la retroalimentación agregada como su propia implementación
Asigne el productor agregado, el validador XML, el consumidor de informes, el manejo de duplicados y la integración de entrega a RFC 9990 secciones 3–4 y Apéndice A. La interfaz de informes necesita la política realmente evaluada, los resultados de la autenticación, el recuento de mensajes y el contexto del período del informe. Un panel que muestra XML no es prueba de que el receptor ascendente seleccionó la política correcta o de que todos los remitentes relevantes aparecieran en los datos.
Los destinos de informes externos merecen su propia fila de componentes. La autorización de destino es un control técnico anti-abuso, no un consentimiento para transmitir datos organizativos arbitrarios. Coloque la generación de informes, la verificación del destino y las decisiones de acceso/retención bajo distintos criterios de aceptación. La sección 7 RFC 9990 aborda la privacidad, mientras que la sección 8 advierte sobre el contenido de informes falsos o maliciosos. Por lo tanto, el refuerzo del analizador y la confianza en la fuente pertenecen al mapa junto con la validez del esquema.
No reutilice un analizador agregado para informes de errores
La retroalimentación sobre fallas es un canal diferente con diferentes riesgos de divulgación. RFC 9991 rige su generación y formato, trabajando con las especificaciones de informes de fallas de autenticación a las que se hace referencia. La solicitud ruf y las condiciones fo no son equivalentes a la agregación rua. Un receptor puede rechazar el informe de fallas y la ausencia de un informe de falla No hay evidencia de que todos los mensajes hayan pasado.
Una integración de informe de falla puede encontrar encabezados de mensajes o contenido que un canal agregado no está diseñado para transportar. Identifique quién puede solicitarlo, dónde se puede enviar, cómo se contiene el material entrante y qué revisión de privacidad se aplica. Nunca lo habilite simplemente para que una matriz de funciones parezca completa. Los requisitos básicos de participación, los informes de fallas opcionales y las capacidades anunciadas de un producto comercial son afirmaciones diferentes que requieren evidencia diferente.
Trabajar a través de un inventario de componentes ficticios.
Considere un servicio ficticio con seis módulos: decodificador de políticas, solucionador de descubrimientos, evaluador de alineación, generador de agregados, consumidor XML y recolector de fallas. Los primeros tres se asignan al RFC 9989 . Los dos siguientes se asignan principalmente a RFC 9990 . El recopilador se asigna principalmente a RFC 9991 . Los controles de seguridad y almacenamiento compartido heredan los requisitos de cada ruta de generación de informes que manejan. Este inventario es un ejemplo documental original, no una afirmación sobre la arquitectura de EmailAuth .
Para cada módulo, conserve su identificador de construcción real, las secciones relevantes, el contrato de entrada/salida, el propietario y el dispositivo de aceptación. Un dispositivo de descubrimiento ficticio puede pasar una política seleccionada y su dominio de origen a un dispositivo agregado ficticio; la fila de informes debe preservar esa distinción en lugar de sustituir silenciosamente el dominio visible De. Luego introduzca una solicitud de informe de falla y confirme que el diseño la dirige a una ruta de procesamiento autorizada por separado. Se trata de comprobaciones propuestas, no de ejecuciones completadas.
Mantenga separados el estado, las erratas y la implementación
La comisión exacta es: asignar cada componente de implementación a RFC 9989 , 9990 o 9991 y verificar las erratas. No se ha proporcionado la cobertura de implementación real. La recuperación de erratas actual falló y se detuvo, por lo que este borrador no puede afirmar que los documentos no tengan erratas. La discusión del RFC 9989 sobre las erratas resueltas RFC 7489 es un contexto histórico, no una nueva verificación de erratas para los tres nuevos documentos.
Antes del lanzamiento, el propietario de la implementación debe conciliar el inventario real, el propietario de los estándares debe resolver las erratas actuales y el propietario de las pruebas del receptor debe preservar la evidencia de interoperabilidad del alcance de la versión. También permanecen abiertas la revisión especializada, los controles de la ruta de producción, la aceptación visual y la aprobación de la publicación. El resultado útil hoy es un mapa revisable que expone la evidencia faltante sin convertir un estándar actualizado en una afirmación infundada de implementación universal.