Publicación p=reject es un hito político, no el fin de DMARC operaciones. Los servicios de envío cambian, aparecen nuevas aplicaciones y los receptores conservan sus propias decisiones de manejo. Los informes agregados aún ayudan a identificar regresiones de autenticación, fuentes recientemente observadas y diferencias entre la política solicitada y el tratamiento informado.
Mantenga los informes configurados y monitoreados después del cambio de política. La idoneidad aún depende del uso del dominio: RFC 9989 §7.4 advierte contra el rechazo de dominios cuyos usuarios pueden publicar en listas de correo de Internet y exige que los dominios rechazados utilicen dominios válidos. DKIM en lugar de depender únicamente de SPF. La evidencia sigue estando limitada por los receptores participantes y sus observaciones. Una política de rechazo no es prueba de que se bloquearon todos los intentos de suplantación o de que se entregaron todos los mensajes legítimos.
Lea la política, la evaluación y la disposición por separado.
Referencias: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
La política publicada expresa el tratamiento solicitado por el propietario del dominio para el correo que no cumple con DMARC . La evaluación pregunta si un identificador SPF o DKIM autenticado se alinea con el dominio del autor. La disposición informada describe el tratamiento relacionado con DMARC informado por el receptor, con información de anulación cuando se proporciona.
Estos campos no deben colapsarse en un solo estado. Un récord mostrar p=reject junto con la disposición none no tiene un formato incorrecto automáticamente: es posible que haya pasado un mensaje o que el manejo del receptor haya diferido de la acción solicitada. Examine los resultados alineados y los motivos disponibles en lugar de hacer conjeturas basándose únicamente en la política. RFC 9989 preserva la discreción del receptor, y RFC 9990 define los campos agregados.
Esté atento a las regresiones por rutas legítimas
Referencias: RFC 9989 §5.3.5.
Mantenga un inventario mantenido de aplicaciones y propietarios. Compare las observaciones actuales con sus identidades esperadas e investigue un cambio. selector, camino de retorno o dominio de autor antes de que los usuarios informen de correo perdido. Incluya rutas estacionales y de bajo volumen que puedan permanecer invisibles durante largos períodos.
Caso ilustrativo: una aplicación de facturación previamente verificada se traslada a una nueva plataforma y pierde su alineación firma DKIM. SPF todavía pasa bajo un dominio de servicio no relacionado. Asuma una póliza válida aplicable y verificaciones completadas. Sin otra ruta de paso alineada, el mensaje falla en DMARC en este ejemplo sintético. La respuesta útil es reparar la identidad del remitente admitida, no asumir que la aplicación de la ley ha hecho innecesaria la incorporación futura.
Interpretar fallas continuas no autorizadas.
Los remitentes no autorizados pueden continuar usando el dominio en From incluso después de la aplicación de la ley. Los informes pueden mostrar la autenticación fallida observada y el tratamiento del receptor para ese tráfico. El volumen persistente de fallas no demuestra por sí solo que la aplicación de la ley sea ineficaz; un control puede estar rechazando el tráfico que continúa llegando.
Por el contrario, no cuente cada falla como un ataque evitado confirmado. La atribución, la intención, la cobertura del receptor y el manejo real necesitan evidencia. Un recuento de informes es un recuento de observaciones y la disposición informada no es una auditoría de entrega posterior completa.
Conciliar excepciones y cobertura faltante
Referencias: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
Revisar los registros en los que el correo fallido recibió un tratamiento diferente al de la política solicitada. Investigue los motivos de anulación proporcionados y el comportamiento de reenvío o intermediario relevante. No asuma que cada receptor aplica la misma política local o que cada excepción tiene suficiente explicación en un informe agregado.
Verifique el proceso de generación de informes en sí: propiedad del destino, autorización externa cuando sea necesaria, errores de ingesta y cambios en los receptores contribuyentes. Un panel silencioso después de la aplicación de la ley puede reflejar un problema de cobranza. Mantenga una prueba controlada de rutas críticas y compare la evidencia del receptor con los registros de la aplicación al investigar la entrega.
Mantener un ritmo operativo posterior a la aplicación de la ley.
Asigne la responsabilidad de la incorporación de nuevos remitentes, la revisión periódica del inventario, los cambios DNS y la clasificación de informes. Utilice un proceso de aprobación y vencimiento para cualquier relajación temporal de la política. Verifique que el cambio propuesto aborde una causa respaldada y no afecte innecesariamente a remitentes no relacionados.
Cierre cada revisión con las rutas legítimas probadas, las fuentes desconocidas investigadas, las desviaciones del receptor examinadas y las lagunas en los informes aún presentes. Se mantiene el objetivo después de p=reject , cobertura de autenticación explicable. La cadena de políticas por sí sola no puede proporcionar esa seguridad.
Encuadernado la conclusión y la siguiente acción.
Para el traslado de plataforma ficticia, conserve el pase SPF sin formato bajo la identidad de servicio no relacionada por separado del DKIM alineado faltante. Se debe probar una reparación de firma admitida posterior en la ruta afectada. Una disposición de ninguna información reportada sigue siendo evidencia de manejo, no prueba de que se recuperó la autenticación o que una bandeja de entrada recibió el mensaje.