dkim=fail reason="key not found in DNS"

La clasificación depende del verificador (`fail` en OpenDKIM, `neutral (no key)` en mailauth; ambos reproducidos), y por eso el mismo mensaje puede verse distinto en los encabezados de tu propio servidor y en los de los grandes proveedores de correo; los encabezados de Gmail suelen decir `dkim=neutral (no key for signature)`, una redacción propia de un servicio en producción que no se puede reproducir en un contenedor. Si la consulta DNS agota el tiempo de espera en lugar de no encontrar el registro, el resultado es `dkim=temperror`.

Qué significa

El mensaje lleva una firma DKIM para el selector `s=` y el dominio `d=`, pero el registro TXT `<selector>._domainkey.<domain>` no existe, así que el receptor no puede verificar nada. OpenDKIM lo notifica como `dkim=fail` con este motivo; otros verificadores clasifican la misma situación de otra manera: mailauth como `dkim=neutral (no key)` y algunos como `dkim=permerror`. A efectos de DMARC, ninguna de estas clasificaciones cuenta como un resultado pass de DKIM.

Por qué ocurre

• El registro del selector nunca se creó

  frecuente

  Una nueva clave de firma (o un nuevo proveedor de correo) empezó a firmar con un selector antes de que se añadiera su registro TXT. Los proveedores de envío de correo (ESP) como Google Workspace, Microsoft 365 o SendGrid solo empiezan a firmar correctamente una vez que sus registros existen.

• El registro existe con un nombre ligeramente distinto

  frecuente

  Los paneles de DNS que añaden el nombre de la zona generan `s2026._domainkey.example.com.example.com`; tampoco se encuentra un registro creado en la zona padre cuando un subdominio está delegado en otro lugar.

• El destino del CNAME o el registro dividido está roto

  ocasional

  Los proveedores que usan registros CNAME que apuntan a sus propios registros de clave (`s1._domainkey → s1.domainkey.u123.wl.sendgrid.net`) fallan si el CNAME falta o apunta a un destino eliminado.

• La clave se eliminó mientras el correo aún la usa

  ocasional

  Eliminar el selector antiguo justo después de la rotación de claves rompe los mensajes que siguen en cola o que se vuelven a verificar más tarde (reenvío, ARC).

Cómo solucionarlo

1. 1.

   Consultar el nombre exacto del registro

   Construye el nombre a partir de `s=` y `d=` del encabezado de firma y consúltalo desde fuera de tu red.

   # s= and d= from the DKIM-Signature header name the record: <s>._domainkey.<d>
   dig +short TXT s2026._domainkey.example.com
   dig +short TXT s2026._domainkey.example.com @1.1.1.1   # bypass local caches

2. 2.

   Publicar la clave y conservar un tiempo los selectores antiguos

   Publica el nuevo selector antes de firmar con él y conserva el anterior durante unos días después del cambio.

   ; zone example.com - long keys are split into several quoted strings of at most 255 characters
   s2026._domainkey  IN TXT ( "v=DKIM1; k=rsa; "
                              "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

← Explorar toda la base de datos de errores de firma