Separando DKIM Las claves por flujo de correo pueden facilitar la rotación, la contención de incidentes y la resolución de problemas. No crea automáticamente reputaciones de dominio separadas ni limita una clave a una categoría de mensajes. Diseñe en torno a la autoridad que recibe cada firmante y los servicios reales que la utilizan.
Definir las corrientes operativamente
Enumere las aplicaciones y proveedores detrás de mensajes transaccionales, campañas y correo de empleados. Incluya trabajos programados y mensajes críticos de bajo volumen. Para cada ruta, registre el dominio De origen, el dominio de firma esperado, selector, custodio de clave privada, propietario DNS y requisitos de recuperación empresarial.
Utilice selectores distintos donde las plataformas los admitan. Bajo RFC 6376 §3.1, un selector identifica los datos de verificación bajo el dominio de firma, por lo que diferentes selectores pueden evitar que las claves administradas de forma independiente colisionen en un nombre de búsqueda. No asuma que cambiar el nombre de un selector crea una nueva clave privada o que una plataforma permite rotar cada flujo de forma independiente.
Decidir si los dominios también necesitan separación
Los selectores organizan la búsqueda de claves, no el propósito del mensaje. Una clave privada autorizada bajo d=brand.example no está restringida por la etiqueta del selector a facturas o campañas. Si se necesitan límites de autoridad más precisos, considere la posibilidad de firmar subdominios compatibles junto con controles de acceso y opciones explícitas de dominio De.
DMARC alineación debe seguir siendo parte de ese diseño. Una firma de un subdominio puede alinearse con un dominio de autor principal bajo reglas relajadas cuando la relación organización-dominio califica. La alineación estricta requiere el dominio exacto bajo RFC 9989 §3.2.10.2. El descubrimiento del dominio organizacional debe seguir RFC 9989 §4.10.2 en lugar de una ingenua comparación de las dos últimas etiquetas.
Trabajar a través de un ejemplo de aislamiento
Diseño ilustrativo: el correo transaccional usa el selector tx1, las campañas usan mk1 y el correo del personal usa emp1, todos con d=brand.example pero con claves privadas distintas. Para revocar mk1 no es necesario eliminar las claves públicas de tx1 o emp1. Sin embargo, un atacante que posea la clave privada mk1 aún puede firmar mensajes en brand.example ; el nombre mk1 no exige un permiso exclusivo de marketing.
Esto significa que los selectores separados reducen parte del acoplamiento operativo y al mismo tiempo dejan la autoridad de dominio compartido. Se necesitan credenciales separadas, controles de remitente aprobados y posiblemente dominios de firma para lograr límites más estrictos. Estos son controles propuestos, no una afirmación de que todos los proveedores los exponen.
Planificación de rotación y recuperación de fallas por flujo.
Asigne a cada secuencia una ventana de cambio independiente y un conjunto de prueba. Las pruebas transaccionales deben incluir mensajes de cuenta urgentes; las pruebas de campaña deben incluir plantillas y procesamiento de cancelación de suscripción; Las pruebas de los empleados deben ejercitar las puertas de enlace de salida relevantes. Asegúrese de que los componentes que cambian el contenido actúen antes que el firmante final previsto.
Para rotaciones ordinarias, conserve el material de verificación antiguo necesario hasta que se cumplan las condiciones de cola y caducidad aprobadas. Para las claves comprometidas, deje que los requisitos de contención determinen el retiro en lugar de retener ciegamente la superposición. Una clave privada compartida anula gran parte de los beneficios de los nombres de selector separados.
Mide el límite que construiste
Mantenga un registro de ruta a la clave y evidencia fechada de los mensajes recibidos. Pruebe si la rotación de una secuencia afecta a otra, pero no afirme que esto sucedió a menos que realmente haya ejecutado la prueba. Revise la baja del proveedor tanto para los registros del selector como para los permisos de la cuenta.
El éxito es un conjunto explicable de custodios independientes, cambios y caminos de recuperación. La reputación y la ubicación en la bandeja de entrada requieren su propia evidencia; una arquitectura de selector DKIM tampoco puede prometer nada.
Verifique un modelo de aislamiento concreto.
Un registro sintético asigna tx1/key-T al equipo de la aplicación, mk1/key-M al proveedor de la campaña y emp1/key-E a las operaciones de correo. Todos firman como brand.example . En este modelo de inventario ilustrativo, la eliminación de mk1 deja a tx1 y emp1 en el conjunto retenido. Esta revisión no ejecutó una rotación real ni inspeccionó claves privadas. No prueba que las claves privadas difieran en un inquilino real o que esas rutas aún se envíen. Si todos los selectores usaran la misma clave privada, esta separación a nivel de inventario no proporcionaría una contención independiente del material clave.
La recepción oportuna no es evidencia del aislamiento de la clave DKIM . Valide la custodia de claves, los controles de rotación admitidos y los resultados de los mensajes recibidos para cada flujo real antes de tratar el diseño como probado.
Evidencia necesaria para la próxima decisión
Antes de aprobar el ejemplo, pregunte si tx1, mk1 y emp1 tienen material de verificación pública distinto, acceso a firmas controlado por separado y soporte de rotación independiente. Las huellas dactilares públicas pueden comparar material, pero no pueden probar que un proveedor tenga credenciales o custodia privada aislada. Si la administración es compartida, documente la ruta de falla común restante en lugar de llamar a las transmisiones completamente aisladas.