21 sep 20264 minutos leídos
SendmarcFallo de Verificación de DKIM: Una Guía para Equipos Empresariales
Resumen del fallo de verificación de DKIM:
- Un registro DKIM válido aún puede fallar en producción. Las discrepancias de canonicalización son la causa habitual.
- Usa
c=relaxed/relaxedpor defecto. La canonicalizaciónsimplese rompe tras cualquier reformateo en tránsito. - Asigna selectores por plataforma. Esto limita la exposición si una clave se ve comprometida.
dkim=failes un fallo de verificación de DKIM.dkim=permerrorsignifica que el registro no existe.- La mayoría de los fallos de verificación de DKIM son operativos, no técnicos.
Un registro DKIM válido puede parecer correcto en tu DNS hoy y convertirse en un fallo de verificación de DKIM en producción mañana. La canonicalización de encabezados que no sobrevive a cómo se mueve realmente el correo en tu entorno es la causa habitual de un fallo de verificación de DKIM, y una mala nomenclatura de selectores suele ser la razón por la que ese fallo es difícil de rastrear hasta su origen.
Este artículo repasa ejemplos reales de registros DKIM, patrones de diseño de selectores, reglas de canonicalización y los diagnósticos del encabezado Authentication-Results que necesitas para encontrar y solucionar fallos. Asume que estás familiarizado con el DNS, entiendes lo que hace DKIM a un nivel general y buscas confianza en las decisiones de diseño en lugar de una introducción al protocolo.
Cómo Se Ve un Registro DKIM Listo para Producción
La estructura básica es sencilla. Un registro DKIM TXT se publica en selector._domainkey.yourdomain.com y contiene la clave pública.
Un ejemplo de registro DKIM mínimo y funcional se ve así:
| Host | Tipo | Valor |
|---|---|---|
selector._domainkey.yourdomain.com | TXT | v=DKIM1; k=rsa; p=[public key] |
En la práctica, los registros de producción incluyen campos adicionales:
| Host | Tipo | Valor |
|---|---|---|
selector._domainkey.yourdomain.com | TXT | v=DKIM1; k=rsa; h=sha256; t=1751035051; p=[public key] |
h=sha256especifica el algoritmo hash aceptado.t=1751035051proporciona la marca de tiempo de la firma DKIM.
Estrategia de Selectores
Los despliegues con un solo selector crean riesgo. Un selector apunta al registro DNS que un receptor verifica para validar una firma DKIM. Asignar el mismo selector a más de una clave activa genera ambigüedad.
Una estrategia más defendible asigna selectores por categoría de remitente o tipo de plataforma:
marketing._domainkey.yourdomain.comtransactional._domainkey.yourdomain.comhr._domainkey.yourdomain.comsupport._domainkey.yourdomain.com
Dividir la firma entre varios selectores limita qué plataformas de envío quedan expuestas si una clave se ve comprometida y facilita ver qué servidores están autorizados a enviar en nombre del dominio.
Canonicalización de DKIM
Aquí es donde las pruebas pasan y producción falla.
DKIM firma una versión canonicalizada de los encabezados y el cuerpo del mensaje. El algoritmo de canonicalización determina cómo se normalizan los espacios en blanco, los saltos de línea y las diferencias de mayúsculas antes de firmar. Las dos opciones son simple y relaxed:
| Host | Tipo | Valor |
|---|---|---|
selector._domainkey.yourdomain.com | TXT | v=DKIM1; k=rsa; c=relaxed/relaxed; p=[public key] |
El formato es c=header/body. La canonicalización relaxed tolera el colapso de espacios en blanco y los nombres de encabezado en minúsculas. La canonicalización simple no lo hace.
Por qué esto causa fallos en producción pero no en las pruebas:
Muchos sistemas de correo reformatean los mensajes en tránsito. Si tu configuración de firma usa c=simple/simple, cualquier transformación romperá la firma DKIM. Esta es una de las causas raíz más comunes detrás de una discrepancia de canonicalización.
La canonicalización relaxed tolera ciertas transformaciones. Para la mayoría de los entornos de producción, c=relaxed/relaxed es el valor predeterminado correcto, a menos que tengas una razón específica para exigir una verificación estricta.
Cómo Leer los Resultados de DKIM
Los servidores receptores registran los resultados de DKIM en el encabezado Authentication-Results. Leer el encabezado Authentication-Results detecta con precisión la mayoría de los fallos en producción.
Un resultado exitoso:
Authentication-Results: mx.receiver.example; dkim=pass header.d=yourdomain.com
Un fallo con una señal útil:
Authentication-Results: mx.receiver.example; dkim=fail (la firma del mensaje no superó la verificación) header.d=yourdomain.com
Un fallo causado por un registro DNS faltante:
Authentication-Results: mx.receiver.example; dkim=permerror (sin clave para la firma) header.d=yourdomain.com
La distinción en el encabezado Authentication-Results importa. dkim=fail significa que el registro está publicado, la clave se encontró, pero la firma no superó la validación debido a una discrepancia de canonicalización, una clave incorrecta o una modificación del mensaje. dkim=permerror significa que el registro no existe, generalmente por un descuido en el despliegue, un error de rotación o un error tipográfico en el nombre del selector.
Lista de Verificación de DKIM para Equipos Empresariales
La mayoría de los fallos de verificación de DKIM no son técnicos; son operativos. Se rota una clave, pero la plataforma de envío no se actualiza. Una integración de terceros empieza a firmar con un selector obsoleto. Un subdominio se activa sin un registro DKIM porque nadie se dio cuenta de que se necesitaba uno.
Una lista de verificación mínima para el riesgo de fallo de verificación de DKIM cubre cuatro áreas:
1. Ciclo de vida de las claves
- Todas las claves activas están documentadas con su fecha de creación, plataforma y fecha de rotación programada.
- Existe un proceso definido para la revocación de emergencia.
- Las claves retiradas se revocan con
p=en lugar de eliminarse por completo.
2. Supervisión de selectores
- Cada plataforma de envío tiene su propio selector.
- Los nombres de los selectores son lo suficientemente descriptivos como para rastrearlos hasta un remitente.
3. Monitoreo
- Los reportes agregados de DMARC se revisan según un cronograma, no solo cuando surge un problema.
- Se establece un umbral de alerta para las caídas en la tasa de autenticación exitosa.
4. Gestión de cambios
- Existe un proceso documentado para agregar una nueva plataforma de envío.
- Las rotaciones de claves se registran en un historial de cambios con detalles de antes y después.
Cómo Ayuda Sendmarc
Los equipos de seguridad y TI sobrecargados no tienen la capacidad de inspeccionar e interpretar manualmente los encabezados en cada plataforma de envío.
Para empresas que gestionan entornos de envío complejos y distribuidos, Sendmarc te ayuda a identificar qué sistemas están firmando, qué selectores están en uso y dónde está fallando la verificación, todo sin sumar carga de trabajo a tu equipo, para que no tengas que rastrear manualmente una discrepancia de canonicalización o un registro faltante.
Descubre nuestra solución de gestión de DKIM para ver cómo mantenemos visibles los estados de autenticación en cada dominio y remitente, de modo que los problemas de DKIM salgan a la luz antes de llegar a una bandeja de entrada o aparecer en una auditoría.
Leave a reply Cancelar respuesta
Your email address will not be published. Required fields are marked *