Pasar a una política de cumplimiento es una decisión importante de control de dominio, no el fin del fraude por correo electrónico. Informe con precisión el límite alcanzado: el dominio solicita un tratamiento más estricto de los mensajes que fallan DMARC. Luego, explique las amenazas que aún pueden autenticar o quedar fuera de ese límite de identidad, junto con el trabajo operativo necesario para mantener el correo legítimo en funcionamiento.
Declarar la protección sin garantía
DMARC combina la autenticación de dominio alineada con un marco de informes y preferencias de manejo publicado. El manejo real del receptor puede involucrar la política local. No prometa que cada mensaje fallido será rechazado en todas partes o que un pase significa que el mensaje es seguro. RFC 9989.
Los mensajes de dominios similares, la suplantación de nombres para mostrar y los remitentes legítimos comprometidos pueden seguir siendo peligrosos después de la aplicación de la ley. Un proveedor autenticado aún puede enviar una solicitud de pago no autorizada. SPF Una autorización que sea más amplia de lo previsto también puede dejar disponible una ruta de adelantamiento alineada. Éstas son razones para mantener controles complementarios, no razones para abandonar la autenticación de dominio.
Verifique las rutas legítimas antes del cambio.
Mantenga una matriz remitente por remitente con el servicio, propietario responsable, dominio del autor, dominios autenticados, alineación evidencia, destinatarios críticos y fecha de la última prueba. Incluya sistemas de bajo volumen como escáneres y alertas. Una ruta tranquila no necesariamente está sin uso. Resuelva los remitentes desconocidos antes de considerar el inventario como completo.
Documente la diferencia de política propuesta y quién la aprueba. un cambio de p=none a p=reject Es un ejemplo, no un valor para publicar a ciegas. Revise los dominios y dependencias aplicables, planifique la ventana de observación y defina los desencadenantes de recuperación para fallas legítimas importantes. Utilice valores generados específicos del servicio en lugar de las identidades de demostración de este artículo.
Examinar un libro de contabilidad de preparación escrito
Para el cambio propuesto p=none a p=reject a continuación, suponga un único De visible válido por mensaje y evidencia de autenticación del receptor estipulada. No se realiza ningún cambio real ni prueba del receptor.
- Facturación: propietario propuesto Operaciones de Facturación; De invoice@billing.brand.test ; Pase SPF para bounce@billing.brand.test ; DKIM pasar con d=billing.brand.test. Ambos identificadores se alinean exactamente, por lo que el mensaje hipotético pasa. Aún no se proporcionan pruebas reales de destinatarios críticos ni aprobación de cambios.
- Apoyo: Operaciones de Apoyo al propietario propuesto; De agent@support.brand.test ; Pase SPF para bounce@support.brand.test ; Pase DKIM con d=support.brand.test. Ambos se alinean exactamente, por lo que pasa el mensaje hipotético. Aún no se proporcionan pruebas reales de destinatarios críticos ni aprobación de cambios.
- Escáner heredado: propietario no confirmado; De, SPF , DKIM y cobertura del destinatario desconocido. No se puede deducir ningún veredicto del mensaje. Asigne un propietario responsable y obtenga evidencia de ruta antes de declarar que está listo.
No se ha establecido la preparación general para la implementación. Incluso los dos pases estipulados no son pruebas de producción observadas. El propietario del cambio propuesto debe mantener el cambio en espera hasta que se resuelvan las incógnitas, las aprobaciones, los desencadenantes de recuperación y las comprobaciones de ruta. No se ejecutó ningún código, consulta DNS o verificación de firma para este libro mayor.
La sección 7.4 RFC9989 requiere firmas DKIM válidas al publicar p=reject y desaconseja el rechazo de dominios cuyos usuarios puedan publicar en listas de correo. Esos dominios primero deben evaluar los datos agregados con p=none durante al menos un mes, luego p=quarantine por un período igualmente largo. Elija la política teniendo en cuenta esas limitaciones de interoperabilidad; un ejemplo limpio de envío directo no resuelve el riesgo de correo indirecto.
Verificar el comportamiento después de una implementación aprobada
En un cambio real, capture la política publicada, el tiempo, las diferencias aprobadas y las pruebas para cada ruta crítica. Compare los resultados del receptor confiable y el manejo real, y revise los informes agregados disponibles con sus límites de cobertura. Los informes faltantes no son prueba de que no se envió ningún correo o de que no se produjo ninguna falla. RFC 9990. Investigar excepciones legítimas por ruta en lugar de debilitar ampliamente la protección sin un propietario.
Explique el riesgo de fraude restante en los mismos términos comerciales utilizados antes de la ejecución. Los cambios de pago aún requieren verificación independiente; El compromiso de la cuenta aún requiere una respuesta de seguridad de la cuenta; los imitadores requieren detección y presentación de informes con el alcance adecuado. La guía de verificación de pagos del FBI sigue siendo relevante incluso cuando el dominio se autentica. orientación del FBI.
Una declaración de finalización sólida nombra la política observada, las rutas probadas, las excepciones no resueltas y los controles residuales. No debería decir phishing está solucionado. Mantenga activa la propiedad y la revisión periódica a medida que cambian los servicios, las claves y los procesos comerciales.