DKIM "no key for signature": correcciones de selector y rotación (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.

“No key for signature” significa que el receptor consultó el registro DNS al que apunta su firma DKIM — selector._domainkey.sudominio — y no encontró ninguna clave: nunca se publicó, o se borró a mitad de una rotación. Publique el selector que su firmante usa realmente. Solo 10.092.481 dominios — el 3,87% — completan la tríada SPF+DKIM+DMARC, según el censo de Defaults.Exposed sobre 261.086.232 dominios calificados.

La corrección es un registro DNS, que se encuentra en una cabecera. Lea las etiquetas s= y d= de una cabecera DKIM-Signature real para saber con qué selector se firma su correo, publique (o repare) ese registro exacto y prefiera la delegación por CNAME para que su proveedor rote las claves por usted. Después rote siguiendo el procedimiento de abajo — este error suele significar que alguien borró un selector antiguo demasiado pronto.

¿Qué significa “dkim no key for signature”?

Toda firma DKIM lleva dos etiquetas que indican al receptor dónde obtener la clave pública: d= (dominio firmante) y s= (selector). El receptor consulta un solo nombre DNS construido a partir de ellas — s._domainkey.d — para obtener la clave. “No key for signature” significa que esa consulta volvió vacía: la firma existe, pero la clave a la que apunta no.

La redacción aparece en las cabeceras Authentication-Results y en los informes agregados de DMARC — la formulación exacta varía según el receptor, pero hay dos variantes que importan:

Cadena de resultado (fragmento, tal como se observa habitualmente)	Qué ocurrió realmente	¿Transitorio?
`dkim=temperror (no key for signature)`	La consulta DNS falló o expiró — el receptor no pudo obtener respuesta alguna	Sí — los reintentos suelen pasar; investigue solo si persiste
`dkim=permerror (no key for signature)`	La consulta DNS tuvo éxito y la respuesta fue “no existe tal registro” — el selector está genuinamente ausente	No — el registro faltará hasta que usted lo publique

Un temperror aislado es mal tiempo del DNS. Un permerror — o un temperror que se repite durante días y en varios receptores — significa que el registro al que apunta la firma no está en su zona. De eso trata esta guía.

La consecuencia: una firma que no se puede verificar cuenta como si no hubiera DKIM en absoluto, así que DMARC recae solo en SPF — y SPF se rompe con el reenvío. Si la firma está presente pero es inválida en lugar de ausente (body hash, clave estropeada), es un fallo distinto — consulte “DKIM signature not valid”.

¿Cómo averiguo con qué selector se firma mi correo?

No lo adivine a partir de la documentación de su proveedor — léalo en un mensaje real:

Envíe un mensaje desde el sistema afectado a un buzón que usted controle (una dirección de Gmail funciona bien).
Abra el código fuente del mensaje (“Mostrar original” en Gmail, “Ver origen del mensaje” en Outlook).
Busque la cabecera DKIM-Signature: y lea dos etiquetas: s= es el selector, d= es el dominio firmante. Un ejemplo ilustrativo: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
El registro que el receptor consulta es s._domainkey.d — aquí, mail2026._domainkey.yourdomain.com. Compruébelo usted mismo: dig TXT mail2026._domainkey.yourdomain.com +short. Respuesta vacía = el error es real para todos los receptores.
Repítalo por cada sistema emisor. Un mensaje puede llevar varias firmas DKIM — proveedor de buzones, herramienta de newsletters, helpdesk — cada una con su propio par s=/d= y su registro. Arregle la que falla y fíjese en su d=: solo una firma cuyo d= coincida con su dominio From ayuda a DMARC.

¿Por qué falta el registro del selector?

Cuatro causas explican casi todos estos errores — compruébelas en este orden:

Nunca se publicó. El firmante se activó (o venía activado por defecto) con un selector que nadie añadió al DNS. Común con herramientas nuevas y pasarelas que firman sin que se espere.
Se borró a mitad de una rotación. Alguien “hizo limpieza” del selector antiguo mientras los mensajes firmados con él seguían en tránsito, en cola de reintento o pendientes de reenvío. Ese correo ya está firmado con s=old; borrar old._domainkey rompe retroactivamente todos esos mensajes.
Su interfaz de DNS estropeó el destino de un CNAME. Muchos proveedores delegan por CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), y muchos paneles de DNS añaden en silencio su zona al destino — almacenando s1.domainkey.u123.esp.com.yourdomain.com, que no resuelve a nada. Verifique el destino: dig CNAME s1._domainkey.yourdomain.com +short. La misma trampa muerde durante las migraciones de herramientas — consulte DKIM falla tras cambiar de herramienta de correo.
El proveedor rotó, su zona no. Una clave del proveedor pegada como registro TXT estático (en lugar de sus CNAMEs) queda huérfana con su rotación programada — el firmante pasa a un selector que usted nunca publicó. Solo el 51,84% de los 261 millones de dominios del censo presenta una clave DKIM localizable en el momento del análisis (datos a fecha de 2026-06-29).

¿Cómo arreglo “no key for signature”?

Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Lee sus registros DKIM, SPF y DMARC en vivo y muestra lo que los receptores ven realmente — incluido si el selector resuelve y si el destino de un CNAME quedó estropeado.
Publique el selector que el firmante usa realmente — el valor s= de la cabecera, no el de un procedimiento antiguo. Obtenga el registro desde la consola de administración de su proveedor (configuración de DKIM en Google Workspace · configuración de DKIM en Microsoft 365) y añádalo exactamente en s._domainkey.sudominio.com.
Prefiera la delegación por CNAME antes que pegar una clave TXT. Si su proveedor ofrece CNAMEs de DKIM, úselos: la clave vive en la zona de ellos, así que la rotan sin que usted vuelva a tocar el DNS — la causa 4 se vuelve imposible. Casi todas las plataformas de newsletters funcionan así; consulte correos de Mailchimp/Brevo/Klaviyo que fallan DMARC.
Verifique desde fuera de su panel. dig TXT s._domainkey.sudominio.com +short (o dig CNAME … para selectores delegados) desde una máquina fuera de su red. Que el panel muestre el registro no demuestra nada si la zona sirve otra cosa.
Vuelva a analizar y reenvíe el mensaje de prueba. Authentication-Results debería decir ahora dkim=pass. Luego resuelva todo lo demás que el análisis señale en la página de arreglar DKIM — una firma que pasa pero no se alinea con su dominio From sigue fallando DMARC.

¿Cómo roto las claves DKIM sin provocar este error?

La rotación es donde las configuraciones que funcionan se rompen. La regla que lo evita: un selector se borra solo después de que se haya drenado el último mensaje firmado con él — nunca en el momento del cambio. El correo firmado vive más de lo que cree: las colas de reintento duran días, y los mensajes reenviados se vuelven a verificar cada vez que se mueven.

Paso	Acción	Condición antes del paso siguiente
1. Añadir	Publique el selector nuevo (`s2._domainkey…`) junto al antiguo	`dig` confirma que resuelve desde fuera
2. Cambiar	Apunte el firmante al selector nuevo	El mensaje de prueba muestra `s=s2` y `dkim=pass`
3. Esperar	Deje publicado el selector antiguo mientras se drena el tráfico en tránsito, en cola y reenviado	≥ 7 días; vigile los informes agregados de DMARC hasta que el selector antiguo deje de aparecer
4. Retirar	Elimine la clave antigua — o mejor, vuelva a publicarla con una etiqueta `p=` vacía: “retirada”, no “nunca existió”	Nunca empiece esto en el momento del cambio — el borrado prematuro es la causa n.º 1 de “no key for signature”

Con la delegación por CNAME, su proveedor ejecuta este mismo procedimiento dentro de su propia zona y usted nunca lo ve — el argumento más fuerte a favor de delegar.

Preguntas frecuentes

¿“No key for signature” es un temperror o un permerror? Existen ambas cadenas: temperror es una consulta DNS que falló o expiró — transitoria, a menudo desaparece al reintentar — mientras que permerror significa que el DNS respondió “no existe tal registro”. Un temperror que se repite en varios receptores suele resultar ser también un registro genuinamente ausente. Compruébelo con dig y confíe en la respuesta, no en la etiqueta.

¿Este error significa que alguien está suplantando mi dominio? No — un suplantador no firmaría con su selector. Significa que su propio correo lleva una firma que los receptores no pueden verificar, así que cuenta como no firmado y DMARC se apoya solo en SPF. La autenticación completa y alineada es rara: solo 10.092.481 de 261.086.232 dominios (3,87%) completaron la tríada SPF+DKIM+DMARC en el censo de Defaults.Exposed (datos a fecha de 2026-06-29).

¿Puedo borrar sin más el selector antiguo en cuanto el nuevo funcione? No de inmediato. Los mensajes firmados con él siguen en colas de reintento y rutas de reenvío; borrar la clave los rompe retroactivamente. Mantenga el registro antiguo al menos una semana, vigile sus informes DMARC hasta que el selector antiguo deje de aparecer y entonces retírelo — idealmente con un p= vacío en lugar de borrarlo.

El verificador de mi proveedor dice que DKIM está configurado, pero los receptores siguen reportando que no hay clave. ¿Cómo? Casi siempre es la trampa del destino del CNAME: su panel de DNS añadió su zona al destino (…esp.com.yourdomain.com), así que el registro existe pero no apunta a ninguna parte. dig CNAME selector._domainkey.yourdomain.com +short muestra el destino almacenado tal cual — compárelo carácter por carácter con lo que el proveedor pidió.

Envíe el informe al propietario

Si está arreglando esto para un cliente o para su empresa, cierre el círculo con pruebas. Vuelva a ejecutar el análisis gratuito cuando el selector resuelva y reenvíe el informe calificado al propietario del negocio: fechado, en lenguaje claro, con DKIM verificando. Es el documento que necesitarán para la renovación del ciberseguro y el próximo cuestionario de seguridad de proveedores — prueba de un control que funciona, no solo un ticket cerrado.

Compruebe su DKIM gratis

Vea si sus selectores resuelven — y exactamente qué corregir — de forma privada y solo para el propietario.

Compruebe su dominio → · “DKIM signature not valid” → · Arreglar DKIM → · Configurar DKIM en Google Workspace → · Solo datos agregados. Datos almacenados y procesados en la UE.