Bajo RFC 9989 §5.4, un mensaje puede fallar DMARC y aún así ser aceptado. Otro puede pasar DMARC y ser rechazado. Esas observaciones no son suficientes para concluir que el receptor ignoró la autenticación o que el registro DNS del dominio está roto.
DMARC le brinda al receptor evidencia de autenticación de dominio y una política de propietario de dominio a considerar. El receptor también controla su propio manejo de correo. Una investigación debe separar esas capas antes de proponer una solución.
Utilice tres columnas en lugar de un estado
Registre la política publicada, el resultado de la validación DMARC del mensaje y la acción real del receptor por separado. Cada uno responde una pregunta diferente.
- Capa: Política del propietario; Pregunta que responde: ¿Qué valoración solicitó el registro de dominio aplicable?; Evidencia útil: registro de políticas exacto y ruta de descubrimiento en el momento relevante
- Capa: Validación; La pregunta responde: ¿Se alineó una identidad autenticada pasajera con De?; Evidencia útil: resultados de autenticación del receptor y las identidades relevantes
- Capa: Manipulación; Pregunta que responde: ¿Qué hizo este receptor con este mensaje?; Evidencia útil: respuesta SMTP , evidencia de entrega o registros del receptor
Una política de ninguno no significa que SPF, DKIM y otros filtros están desactivados. Un pase no fuerza la ubicación de la bandeja de entrada. Una política de rechazo no elimina el análisis del receptor de rutas indirectas legítimas u otra evidencia relevante.
Por ejemplo, un remitente puede corregir DKIM correctamente y aun así recibir un rechazo causado por una regla de receptor independiente. Cambiar repetidamente DNS DMARC en esa situación crea un riesgo de cambio sin abordar el motivo devuelto.
Trabajar a través de un fracaso aceptado
Considere un mensaje sintético con De notices@accounts.example . Sus solicitudes de política aplicables se rechazan, pero el receptor final registra una falla DMARC después de una ruta indirecta. El mensaje se acepta según el manejo local del receptor.
La primera investigación es si el mensaje fue una entrega indirecta legítima, un defecto de configuración o un uso no autorizado. Conserve la fuente de conexión, la identidad SPF , los dominios y resultados DKIM , el reenvío relevante o el comportamiento de la lista y cualquier motivo de anulación de políticas disponible.
RFC 9989 RFC 9989 §7.4 analiza el análisis del receptor más allá del rechazo, incluida la interoperabilidad del correo indirecto. Por lo tanto, la aceptación no es prueba de una validación DMARC exitosa. Del mismo modo, el hecho de que el receptor haya aceptado el mensaje no prueba que el mensaje fuera benigno.
El propietario del control debe resolver la ruta legítima, si existe, documentar los hallazgos específicos del receptor y evitar afirmar que la política garantiza la misma acción en todas partes. El tutorial del informe agregado ayuda a mantener distintos los campos de autenticación y disposición.
Trabajar a través de un pase rechazado
Consideremos ahora un mensaje sintético diferente. esta alineado firma DKIM pasa y el receptor registra el pase DMARC , pero la respuesta SMTP identifica otra política o problema de abuso.
DMARC ha respondido correctamente a la pregunta de autenticación de dominio. La siguiente tarea es examinar el rechazo real, incluido el texto completo de la respuesta y la evidencia de servicio relevante del remitente. Un contenido, destinatario, reputación u otra regla local puede afectar el manejo sin cambiar el resultado DMARC .
No agregue infraestructura de envío no relacionada a SPF solo para que todos los mecanismos mostrados se vuelvan verdes. Primero establezca qué identidad y ruta evaluó el receptor y qué motivo impidió la entrega. Un cambio amplio de permiso puede crear un nuevo problema y dejar el rechazo sin cambios.
Trate cuidadosamente los resultados faltantes y de error
No todos los mensajes arrojan una calificación normal de aprobado o reprobado. Un registro aplicable faltante difiere de una falta de autenticación bajo un registro existente. Un problema de disponibilidad DNS difiere de una política permanentemente mal formada.
RFC 9989 RFC 9989 §9.2 separa estas condiciones de resultado. Bajo RFC 9989 §5.3.6, si los errores DNS impiden la validación DMARC requerida, no se puede establecer una aprobación o falla normal y el manejo recae en otras decisiones del receptor. Capture el error y la consulta afectada, en lugar de tratarlos como prueba de que el remitente es malintencionado.
Un rechazo temporal puede invitar a otro intento de entrega; un intento posterior puede ver un estado DNS diferente. Es por eso que una captura de pantalla del registro de hoy es una evidencia débil sobre un mensaje procesado ayer.
Solicitar evidencia que pueda resolver la diferencia.
Para cada mensaje en disputa, recopile un pequeño registro de caso:
- Identificadores de mensajes e intentos de envío, con datos confidenciales redactados adecuadamente para su clasificación. Mantenga un original no modificado controlado por separado si es necesaria una nueva verificación DKIM , ya que cambiar el contenido firmado puede afectar la verificación según RFC 6376 §3.7.
- Marca de tiempo y receptor, incluida la respuesta SMTP completa, si está disponible.
- Visible desde el dominio, el dominio evaluado por SPF y todos los dominios de firma DKIM relevantes.
- Resultados de autenticación de receptor confiable, dónde se entregó un mensaje o registros disponibles.
- Política aplicable y respuestas DNS asociadas con esa ventana de procesamiento.
- Ruta indirecta conocida y cualquier anulación disponible o explicación de regla local.
Una transacción rechazada puede no proporcionar entrega encabezados de mensajes en absoluto. Utilice los registros de intentos del remitente, la respuesta y la asistencia del receptor en lugar de requerir una muestra de encabezado que no puede existir para ese intento. Bajo RFC 8601 §7.1, evite tratar los encabezados no confiables agregados antes del límite de recepción como la propia conclusión del receptor.
Cerrar el caso con el cambio más pequeño admitido
La solución podría ser corregir la identidad del remitente, solucionar un defecto DNS , reparar un recopilador de informes o abordar un problema específico del receptor. También puede ser una decisión de interoperabilidad documentada para una ruta legítima particular.
Vuelva a probar el flujo afectado después del cambio y conserve la nueva evidencia. Si el resultado aún difiere entre los receptores, registre lo que cada uno observó realmente y qué implementación o diferencia de política local permanece sin confirmar. No generalice a partir de la respuesta de un receptor a todo el ecosistema.
Una explicación útil identifica la política del propietario, el resultado de la validación y la decisión de manejo por separado, y luego señala la evidencia que los conecta. Eso es suficiente para convertir una aparente contradicción en una investigación con un propietario y una siguiente acción.
Registrar una decisión que pueda ser revisada
Para el caso de fracaso aceptado, escriba p=reject, dmarc=fail y aceptado como observaciones separadas. Para el caso de pase rechazado, conserve dmarc=pass y el motivo real del rechazo devuelto; no fabrique una reparación DMARC . RFC 9990 §3.1.1 y RFC 9990 §3.1.6 Asimismo, separe la información agregada de evaluación, disposición y anulación. Ambos casos son registros hipotéticos del receptor, no capturados.