Una puerta de enlace de seguridad saliente o un servicio de firma corporativa pueden inspeccionar y modificar el correo después de que la aplicación ya lo haya firmado. un establo DKIM El diseño coloca el paso final de firma autorizado después de los cambios de contenido requeridos y verifica toda la ruta. La pregunta importante es qué componente emite el mensaje final, no qué producto muestra primero una configuración DKIM habilitada.
Dibujar el orden de procesamiento real
Envío de mapas, inspección de contenido, descargo de responsabilidad o inserción de firma, serialización MIME , firma DKIM y entrega externa. Incluya rutas alternativas utilizadas por las aplicaciones y conmutación por error de emergencia. No asuma que el correo del buzón de los empleados y el correo de la solicitud siguen el mismo camino.
Para cada componente, registre si cambia el cuerpo, los encabezados seleccionados, la identidad del sobre o solo los metadatos de enrutamiento. Un bloque de firma de correo electrónico corporativo es el contenido del cuerpo; no tiene relación con el criptográfico DKIM-Signature encabezado a pesar de la palabra compartida "firma". La reescritura de URL, el manejo de archivos adjuntos y la reconstrucción de HTML también pueden afectar el contenido cubierto.
RFC 6376 §5.3 y RFC 6376 §5.5 exigir al firmante que opere según la representación transmitida prevista y modificar a los firmantes para que realicen cambios antes de volver a firmar. El diseño debe hacer que esa secuencia sea visible y comprobable.
Elija el dominio y el propietario de la clave
Una puerta de enlace puede agregar una firma válida bajo su propio dominio. Eso no satisface automáticamente DKIM alineación para su dominio de autor en RFC 9989 §4.4.1. Si el diseño requerido utiliza firma de dominio personalizada, verifique la capacidad documentada del producto, los valores DNS generados y la custodia de la clave privada. no inventes selector nombres o copiar la configuración de otro inquilino.
Decida quién puede cambiar la configuración de firma, rotar claves y alterar el canal de contenido final. Proteja las claves privadas para que no se exporten a notas de incidentes o paquetes de prueba. La publicación de una clave pública es sólo una parte de la configuración; Los mensajes salientes reales deben llevar una firma coincidente creada después del procesamiento final.
Pruebe la tubería con dos controles.
Diseño ilustrativo A firma primero y luego agrega un bloque de contacto corporativo. La firma original de cuerpo completo puede fallar. El diseño B inserta el bloque, completa la serialización MIME y luego firma con un dominio alineado autorizado. La firma deseada puede sobrevivir si el procesamiento posterior deja intactos los datos cubiertos. Estas son expectativas de prueba, no una afirmación sobre un proveedor determinado.
Envíe texto sin formato, HTML, contenido que no sea ASCII y un archivo adjunto a través de la ruta prevista. Incluya mensajes generados por la aplicación y una ruta de conmutación por error compatible cuando sea relevante. Capture el mensaje después del último procesador y en un receptor externo confiable. Asocie cada resultado con d y s en lugar de aceptar una etiqueta de aprobación indiferenciada.
Mantener controles de seguridad en el diseño.
Mover la firma más tarde no debería mover silenciosamente la inspección fuera del flujo de trabajo protegido ni evitar el escaneo requerido. Si el firmante final no puede ejecutarse después de un servicio de reescritura obligatorio, evalúe las integraciones admitidas o un límite de firma autorizado diferente. Evite utilizar l para excluir contenido posterior simplemente para generar un recuento de pases; RFC 6376 §8.2 explica los riesgos del contenido sin firmar.
Una nueva firma posterior puede coexistir con una anterior fallida. Confirme qué firma proporciona la alineación deseada y cómo lo informa el servicio receptor. No elimine la evidencia del fallo anterior de los registros de prueba.
Operar el límite como un servicio controlado por cambios
Conserve el diagrama de ruta, los propietarios responsables, el plan de retención de claves y el conjunto de pruebas de formato. Vuelva a realizar la prueba después de las actualizaciones de la puerta de enlace, los cambios en la plantilla de marca, los cambios de enrutamiento y la activación de la conmutación por error. El éxito requiere el contenido previsto, una ruta de autenticación alineada válida y una entrega correcta, con la aprobación humana aún separada del resultado técnico.
Registre la siguiente decisión
Para un mensaje hipotético, registre el orden del procesador, los cambios de contenido esperados, cada par d/s, el veredicto del receptor y la alineación. Si la puerta de enlace firma solo como un dominio de proveedor no relacionado, marque DKIM alineado como no resuelto incluso si su firma pasa. Si mover al firmante evitaría la inspección, detenga ese cambio de diseño y busque una integración compatible. Estos son criterios de planificación, no pruebas de ruta ejecutadas.