El reenvío no se interrumpe automáticamente DKIM. Un reenviador que conserve el contenido del mensaje cubierto puede dejar válida la firma original. Un reenviador que reescribe los encabezados cubiertos o el contenido del cuerpo puede invalidarlo. Diagnosticar lo que realmente hace el servicio de reenvío en lugar de tratar toda la entrega indirecta como un modo de falla.
Traza identidades y transformaciones por separado
En el receptor final, SPF evalúa el sistema de conexión y la identidad SMTP relevante. El reenvío puede cambiar la IP de conexión incluso cuando el cuerpo del mensaje no se modifica. En cambio, DKIM verifica el contenido del mensaje cubierto con la clave del dominio de firma. Por tanto, estos mecanismos pueden divergir en el mismo mensaje reenviado.
Registre el dominio De visible, cada dominio de firma DKIM , selector y resultado, la identidad del sobre y el salto de reenvío. DMARC requiere una ruta de autenticación aprobada alineada con el dominio del autor. Un alineado intacto firma DKIM puede proporcionar esa ruta bajo una política aplicable cuando el reenvío interrumpe SPF, como se especifica en RFC 9989 §4.4.1. Una firma recién agregada bajo un dominio de reenvío no relacionado no se alinea automáticamente.
Comparar muestras directas y reenviadas
Envíe un mensaje controlado a una bandeja de entrada de prueba directa y a través de la ruta de reenvío a otra bandeja de entrada de prueba. Conserve los mensajes sin procesar y los resultados del receptor confiable. Utilice un marcador de prueba único para que las muestras se puedan asociar sin depender únicamente del sujeto. No infieras igualdad a partir del cuerpo renderizado.
Inspeccione los cambios en el cuerpo, Asunto y otros campos seleccionados en h. Marque c y cualquier etiqueta l antes de interpretar las diferencias. Estándar canonicalización puede tolerar ciertos cambios de formato, mientras que la reescritura sustancial puede cambiar la representación firmada. Los encabezados de transporte agregados no invalidan inherentemente una firma que no cubría esas nuevas apariciones; La selección de encabezados repetidos y la sobrefirma pueden ser importantes en RFC 6376 §5.4.2.
Trabajar por dos caminos
La ruta ilustrativa A reenvía el mensaje sin cambiar el contenido cubierto. La firma original puede seguir siendo válida. La ruta B agrega un cartel de advertencia al cuerpo firmado, lo que provoca que falle la firma original de cuerpo completo. La conexión puede ser idéntica en ambas rutas, por lo que las observaciones SPF por sí solas no pueden explicar la diferencia DKIM .
Un transportista también podría reescribir el remitente del sobre mejorar su propia autorización SPF . Eso no restaura una firma DKIM rota ni necesariamente crea SPF alineación con el dominio De original visible. Mantenga las tres preguntas separadas: qué identidad pasó SPF , qué firma pasó DKIM y si alguna de las rutas está alineada.
Seleccione un remedio con alcance
Si la preservación del contenido es compatible con las obligaciones de seguridad del servicio, revise las configuraciones admitidas que eviten modificaciones innecesarias. Si se requiere modificación, evalúe la firma documentada del servicio y el manejo del correo indirecto. No otorgue a reenviadores arbitrarios sus claves de firma ni los autorice ampliamente en SPF para hacer desaparecer un síntoma.
Un receptor administrativo puede utilizar evidencia confiable adicional o una política local para el correo indirecto, pero esa es una decisión de aceptación separada. No reporte dicha aceptación como restauración de la firma original. Conserve los requisitos comerciales y cualquier propietario de excepción junto con el resultado técnico.
Cerrar con prueba específica de ruta
Repita las pruebas de reenvío directo versus reenvío para texto sin formato, HTML y archivos adjuntos después de un cambio. Registre qué firmas originales sobreviven, si aparece una nueva firma y el DMARC final y los resultados de la entrega. Mantenga la ruta de reenvío en las pruebas de regresión porque un banner posterior o un cambio de escaneo pueden alterar el resultado sin ningún cambio DNS en el remitente.
Lea dos resultados hipotéticos a nivel de mensaje
Asuma una política DMARC aplicable y un dominio de autor example.com :
- Ruta conservada: SPF falla después del reenvío, pero la firma original d=example.com aún se verifica. Esa identidad DKIM exactamente alineada proporciona el pase DMARC .
- Ruta modificada: la firma DKIM original falla; la única firma de paso nueva y la identidad SPF pertenecen a forwarder.example.net . Suponiendo que ese dominio no está relacionado con example.com , ninguno proporciona alineación, por lo que DMARC falla. El receptor aún puede tomar una decisión de manejo local por separado.
No combine el pase de la nueva firma con el dominio de la firma anterior. Estos casos ilustran las condiciones en RFC 9989 §5.3.5; no son resultados capturados del receptor ni garantías sobre cada servicio de reenvío.