La prueba cambia una solicitud, no el resultado de la autenticación
La etiqueta t en actual DMARC es una señal de modo de prueba adjunta al registro de política. No convierte un mensaje no autenticado en uno autenticado y no promete entrega. Su propósito útil es suavizar la evaluación solicitada para el correo que no cumple con DMARC y al mismo tiempo permitir un manejo especial relevante. Por lo tanto, un plan de implementación necesita dos resultados independientes: la interpretación esperada de la política y el comportamiento real del receptor.
RFC 9989 sección 4.7 define t=y y t=n, con n como valor predeterminado. Las pruebas operan según cualquier política de evaluación seleccionada entre p, sp o np. Comience por establecer esa política y si DMARC falló. No aplique una transformación a una etiqueta p arbitraria cuando una anulación de subdominio en realidad gobierna el mensaje.
Genere la expectativa de seis celdas antes de enviar cualquier cosa
Para una política none seleccionada, y y n dejan la evaluación solicitada en none. Para la cuarentena seleccionada, y no solicita ninguna mientras n conserva la cuarentena. Para el rechazo seleccionado, y solicita la cuarentena mientras n retiene el rechazo. El resultado none todavía permite el filtrado normal del receptor; no es una instrucción para eludir los controles anti-abuso ni una garantía de que el mensaje ingresará a una bandeja de entrada.
En un diseño de prueba ficticio, _dmarc.trial.north.example contiene un registro alternativo a la vez, cada uno de los cuales comienza con v=DMARC1 y contiene un valor p seleccionado más un valor t. Las seis alternativas forman una matriz, no seis registros de políticas TXT simultáneos. Múltiples registros de políticas con el mismo nombre de candidato constituyen un problema de descubrimiento diferente e invalidarían la comparación prevista. No se publicaron registros ni se envió ningún correo para este artículo.
Conserve un resultado esperado separado para un mensaje de control de paso DMARC. Las pruebas no reescriben ese resultado para fallar o hacer una falla. SPF pase de resultado. Autenticación, alineación, la evaluación seleccionada y la disposición final deben ocupar campos diferentes en el paquete de evidencia. De lo contrario, una captura de pantalla que diga "entregado" puede oscurecer el comportamiento que el experimento debía establecer.
Incluir un manejo especial sin depender de él.
La definición de prueba permite un manejo especial relevante, como la reescritura desde el campo por parte de un intermediario, junto con una evaluación más suave. Dice que la reducción de la evaluación se aplica independientemente de si se produce ese tratamiento especial. Por lo tanto, el diseño de una prueba debe observar ambas dimensiones en lugar de condicionar la política reducida a una reescritura visible.
RFC 9989 Apéndice A.6 explica la historia: el manejo inconsistente de porcentajes llevó a la eliminación de pct, mientras que prácticas útiles en torno a pct=0 informaron la nueva etiqueta binaria. Ese historial no convierte t=y en un porcentaje de muestreo de tráfico ni en una afirmación de que se reproduce todo el comportamiento histórico del porcentaje. El registro IANA ahora enumera t como activo y el porcentaje como histórico. Las entradas del registro no pueden establecer qué software ejecuta una organización receptora.
Un intermediario puede alterar los identificadores de manera que afecten la alineación posterior. Conserve la evidencia del mensaje previo y posterior al intermediario solo dentro de una prueba aprobada y segura para la privacidad. No infiera el mecanismo simplemente a partir de un nombre para mostrar modificado o una carpeta final. El informe debe identificar el campo exacto que cambió, el salto donde cambió y el resultado de la autenticación visto en sentido descendente.
El rechazo final todavía necesita un análisis más amplio del receptor
Una celda de matriz denominada rechazo describe la evaluación solicitada, no un resultado SMTP automático. RFC 9989 sección 7.4 requiere que los receptores no rechacen únicamente según la política de rechazo del dominio de envío. Deben combinarlo con otros análisis y, sin ese conocimiento adicional, tratar el mensaje fallido como una cuarentena. Una prueba que ignore esta distinción podría considerar erróneamente defectuoso a un receptor conforme.
La misma sección destaca los riesgos de interoperabilidad de reenvío y listas de correo. El rechazo de publicación de dominios no debe depender únicamente del SPF para asegurar un pase DMARC y debe solicitar un permiso válido. DKIM firmas. El modo de prueba no repara una firma rota ni establece que todas las rutas indirectas sean seguras. Incluya la entrega directa y las rutas indirectas representativas aprobadas cuando la implementación real dependa de ellas, en lugar de extrapolar desde un único buzón.
Alcance el reclamo del receptor hasta evidencia que pueda retener
Un RFC publicado es una referencia normativa, no un anuncio de implementación para cada proveedor. Una implementación anterior puede ignorar una etiqueta que no reconoce, lo que podría dejar sin suavizar la cuarentena declarada o la evaluación de rechazo. Se trata de un riesgo que hay que evaluar, no de un hallazgo medido sobre un receptor determinado. Documente las declaraciones actuales del proveedor, las versiones reales del software cuando estén disponibles y las observaciones específicas que respaldan cada conclusión de compatibilidad.
Una ejecución autorizada propuesta debe preservar la instantánea y el tiempo de la política DNS , el nombre exacto del registro, los identificadores de mensajes, las entradas de alineación, las respuestas del receptor y cualquier informe disponible. Registre las anulaciones de políticas locales por separado. Repita la comparación de seis celdas bajo condiciones controladas en lugar de cambiar varias variables de envío a la vez. Incluir condiciones de detención en caso de rechazo inesperado y conservar un plan de reversión aprobado; este artículo no autoriza esas acciones operativas.
La presentación de informes también permanece separada. La etiqueta t en sí no cambia la generación del informe. Las solicitudes agregadas utilizan rua y el RFC 9990 reglas de presentación de informes; La retroalimentación de falla tiene sus propias condiciones y discreción del receptor. La falta de comentarios no puede probar que se ignoró la etiqueta de prueba, y los comentarios por sí solos pueden no explicar el razonamiento completo de la disposición final del receptor.
Deje la puerta de ejecución honestamente abierta
La comisión exacta es: Pruebe t=y y t=n con cada política y conserve los resultados del receptor. Este paquete contiene la matriz esperada original de seis celdas, preparada antes de la redacción, pero no hay resultados del receptor. Por tanto, no cumple dicho requisito de ejecución. La puerta de la evidencia original permanece visiblemente abierta en lugar de ser reemplazada por una afirmación de compatibilidad basada en el texto de las normas.
Antes del lanzamiento, un propietario técnico debe aprobar el dispositivo, un propietario operativo debe autorizar cualquier prueba real y un revisor debe conciliar las observaciones con las especificaciones actuales y el alcance del receptor. Quedan pendientes la verificación de erratas, la aceptación de especialistas, las comprobaciones de la ruta de producción, la revisión visual y el permiso de publicación. La conclusión defendible hoy es lo que la etiqueta actual exige que haga una implementación conforme, junto con la evidencia precisa que aún se necesita para confiar en ella.