¿Cómo se comprueba DKIM en el correo de una aplicación?

Trate la comprobación de DKIM como cuatro pruebas separadas

Una consulta DNS por sí sola no es una comprobación completa de DKIM. Primero, confirme que el mensaje contiene un campo DKIM-Signature e identifique la firma que quiere probar. Segundo, obtenga y analice el registro de clave pública que nombra esa firma. Tercero, verifique que los encabezados firmados y el cuerpo canonicalizado siguen coincidiendo con la firma criptográfica. Cuarto, determine si un dominio de firma que pasa se alinea con el dominio From visible para DMARC. Estas capas responden preguntas distintas. Un registro publicado puede no usarse, un mensaje puede hacer referencia a un selector inexistente, una firma puede fallar tras una modificación del contenido y un resultado criptográfico correcto puede seguir sin alinearse con el dominio del autor. Registre cada resultado en lugar de mostrar un único indicador verde. Mantenga también separados los estados de transporte y de buzón: la aceptación por el proveedor, la aceptación por el servidor receptor y la llegada a la bandeja de entrada no son resultados de la verificación DKIM.

Empiece por la firma de un mensaje real

Obtenga el mensaje sin procesar de un destinatario controlado, alcanzado por la ruta normal de la aplicación. En cada campo DKIM-Signature, anote el dominio de firma `d=`, el selector `s=`, el algoritmo `a=`, los modos de canonicalización `c=`, la lista de encabezados firmados `h=`, el hash del cuerpo `bh=`, los datos de la firma `b=` y las marcas de tiempo, si existen. El RFC 6376 define las etiquetas de dominio de firma y de selector, y las usa para localizar la clave pública. No adivine el selector a partir del panel de un proveedor ni consulte `_domainkey` sin él. Un mensaje puede llevar varias firmas de un remitente, un intermediario o un sistema de listas de correo, así que conserve el resultado de cada firma. Evite pegar mensajes de producción en verificadores públicos: los encabezados y cuerpos sin procesar pueden exponer destinatarios, identificadores de mensaje, detalles de enrutamiento, tokens de baja y contenido de la aplicación. Use almacenamiento restringido y una copia de diagnóstico anonimizada cuando no necesite el contenido completo.

Consulte el selector y el dominio de firma exactos

Construya el nombre DNS a partir de la firma como `<selector>._domainkey.<signing-domain>`. Si el encabezado contiene `s=app2026` y `d=notify.example.test`, consulte el registro TXT en `app2026._domainkey.notify.example.test`. Anote el nombre original, el resolvedor, la respuesta, el TTL y cualquier cadena de CNAME. Analice el registro de etiquetas y valores resultante en lugar de buscar un fragmento de texto. El registro puede declarar su versión, el tipo de clave, una restricción de servicio, indicadores, algoritmos de hash y los datos de la clave pública. Un valor de clave pública vacío revoca la clave. Distinga entre NXDOMAIN, una respuesta vacía, contenido malformado, un algoritmo no admitido, una clave inutilizable y un fallo transitorio del resolvedor. Repita una consulta que haya cambiado después de que venza el TTL, a través de un resolvedor independiente, pero no suponga que todos los receptores se actualizaron de inmediato. Una respuesta DNS correcta solo demuestra que se devolvió un registro en ese momento; no demuestra que el mensaje probado se verifique ni que el proveedor esté firmando el tráfico actual con ese selector.

Verifique los encabezados, el hash del cuerpo y la firma

La verificación DKIM sigue las reglas de canonicalización declaradas en la firma. El verificador canonicaliza el cuerpo, calcula su hash y lo compara con `bh=`. También canonicaliza los encabezados firmados que se nombran en `h=`, incorpora el campo DKIM-Signature según lo especificado y verifica `b=` con la clave pública. Use una biblioteca de verificación mantenida o el resultado de autenticación de un receptor de confianza, en lugar de recrear estas transformaciones con operaciones de cadenas. Una discrepancia en el hash del cuerpo suele indicar que el cuerpo cambió después de la firma, mientras que un fallo en la firma de los encabezados puede indicar la modificación de un encabezado firmado, una clave incorrecta, datos de firma dañados o un error de implementación. Registre qué fase falló. Revise si campos importantes como From, Subject, Date y Message-ID estaban firmados, pero no invente una política universal de encabezados firmados. La canonicalización tolera cambios de formato definidos; no hace seguras la inserción arbitraria de pies de página, la reescritura del MIME, los daños en los finales de línea ni las modificaciones durante el transporte.

Lea los resultados del receptor dentro de su límite de confianza

El RFC 8601 define el encabezado Authentication-Results y los resultados DKIM none, pass, fail, policy, neutral, temperror y permerror. Un pass significa que el receptor encontró una firma aceptable que superó las pruebas de verificación. Un temperror puede reflejar una condición que probablemente cambie, como un fallo temporal en la consulta de la clave; un permerror difícilmente tendrá éxito en un intento posterior sin una corrección. Anote el servicio de autenticación que informa, el dominio de firma, el selector y el algoritmo, cuando se indiquen. Confíe solo en los resultados insertados dentro del límite documentado del sistema receptor, porque un remitente puede agregar un campo Authentication-Results falsificado antes de la transmisión. Examine el resultado de confianza más alto para el entorno receptor final y tenga en cuenta los saltos intermedios. Si distintos receptores no coinciden, compare la versión exacta del mensaje, la vista del DNS, el momento de la evaluación, los algoritmos admitidos y la política local. No convierta `dkim=pass` en la afirmación de que el proveedor de buzón respaldó el contenido o lo colocó en la bandeja de entrada.

Compruebe la alineación DMARC por separado del pass de DKIM

Un pass de DKIM autentica el dominio de firma de `d=`; no exige que ese dominio sea igual al dominio From visible del RFC 5322. El RFC 9989 usa un identificador autenticado por DKIM que pasa solo cuando se alinea con el dominio del autor según el modo de alineación estricto o relajado que corresponda. Por ejemplo, un mensaje de `billing.example.test` firmado con `d=provider.test` puede pasar DKIM pero seguir sin alinearse. Una firma válida de `d=example.test` puede alinearse en modo relajado, según el cálculo del dominio organizativo y la política. Informe tres campos: resultado de DKIM, dominio de firma y decisión de alineación. Un mensaje también puede pasar DMARC mediante SPF alineado cuando DKIM falla o no está alineado, así que un pass de DMARC no demuestra que esa firma DKIM concreta haya pasado. Las pautas actuales de Gmail para remitentes incluyen requisitos de autenticación y alineación para el tráfico aplicable, pero cumplirlos sigue sin garantizar la aceptación por el servidor receptor ni la llegada a la bandeja de entrada.

Compruebe los algoritmos actuales y la rotación de claves

El RFC 8301 actualiza los requisitos criptográficos de DKIM: los firmantes deben usar `rsa-sha256`, los verificadores deben admitirlo y no debe usarse `rsa-sha1`. También exige claves de firma RSA de al menos 1024 bits y explica por qué son preferibles claves más grandes cuando sea operativamente posible. Un verificador debe identificar el algoritmo y señalar el material obsoleto o inutilizable, sin afirmar que la longitud de la clave por sí sola hace confiable un flujo de correo. Los flujos de cada proveedor son distintos. Amazon SES documenta que Easy DKIM usa claves de 2048 bits de forma predeterminada y advierte que cambiar de método de firma sin un paso intermedio puede crear un periodo en el que los mensajes no se firman con DKIM. Planifique la rotación con dos selectores válidos o con el mecanismo de superposición documentado por el proveedor, confirme que los mensajes nuevos usan el nuevo selector, conserve la clave pública anterior mientras todavía pueda llegar correo retrasado y elimínela solo después del periodo de superposición. Nunca publique la clave privada de firma en el DNS, en logs, en tickets ni en prompts.

Diagnostique los fallos desde el mensaje hacia afuera

Cuando una comprobación falla, conserve el mensaje sin procesar y el resultado del receptor antes de cambiar el DNS. Confirme que el mensaje lo generaron realmente la aplicación y el proveedor esperados. Si no hay firma, revise si la firma estaba habilitada para esa identidad, región, tenant o clase de mensaje. Si falla la consulta del selector, compare los valores exactos de `d=` y `s=`, la zona DNS, el destino del CNAME, el TTL y cualquier rotación reciente. Si la clave se analiza bien pero el hash del cuerpo falla, revise gateways, pies de página de listas, reescrituras de seguimiento, transformaciones MIME, finales de línea y productos de seguridad que puedan modificar el contenido después de la firma. Si la firma criptográfica falla con un hash del cuerpo coincidente, revise cambios en encabezados firmados, discrepancias de clave y la implementación de la firma. Si DKIM pasa pero DMARC falla, pruebe la alineación en lugar de volver a publicar la misma clave. Vuelva a probar con destinatarios controlados después del TTL o de la propagación de la configuración correspondiente, y registre evidencia para cada clase de mensaje en lugar de dar por corregido todo el dominio a partir de una sola muestra correcta.

Mantenga un registro auditable de las comprobaciones de DKIM

Para cada mensaje controlado, conserve un identificador de correlación no sensible, el sistema de envío, la cuenta o el espacio de trabajo del proveedor, el dominio From visible, el sistema receptor, la hora del mensaje y el resultado completo de cada firma. Incluya `d=`, `s=`, `a=`, la canonicalización, los encabezados firmados, el nombre de la consulta DNS, la hora y el TTL de la respuesta DNS, el estado del registro de clave, el resultado del hash del cuerpo, el resultado de la firma, el valor de Authentication-Results de confianza, la decisión de alineación DMARC y el responsable de la corrección. Guarde los mensajes sin procesar solo donde haya controles de acceso y retención adecuados. Agregue el escenario de prueba: envío normal de la aplicación, migración de proveedor, rotación de claves, ruta por un gateway o caso de reenvío. Así las regresiones se pueden comparar y se evita que una captura de pantalla se convierta en prueba permanente después de que cambien los selectores o el procesamiento de mensajes. Vuelva a comprobar tras cambios en la configuración del proveedor, en el DNS, en el método de firma o en el enrutamiento, o cuando aparezca una nueva clase de mensaje. Un panel operativo debe mostrar explícitamente los estados desconocidos y no disponibles, en lugar de tratarlos en silencio como pass o fail.

Cómo encaja SendHQ en la comprobación

SendHQ requiere un dominio From verificado y proporciona eventos de entrega. Para una comprobación de DKIM, envíe un mensaje controlado a través de la ruta de aplicación prevista, inspeccione la firma recibida, consulte los valores reales de `d=` y `s=` y registre la alineación por separado. No infiera un selector, longitud de clave, algoritmo de firma, llegada a la bandeja de entrada ni garantía de entrega solo a partir de la documentación del producto.

Preguntas frecuentes

Fuentes

• RFC 6376: Firmas DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8301: Actualización del algoritmo criptográfico y el tamaño de clave para DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601: campo de encabezado Authentication-Results — RFC Editor
• RFC 9989: Autenticación, informes y conformidad de mensajes basada en dominios (DMARC) — RFC Editor
• Pautas de Gmail para remitentes de correo — Google
• Easy DKIM en Amazon SES — Amazon Web Services
• Contrato OpenAPI de SendHQ — SendHQ