Una clave DKIM de 1024 bits cabe en una sola cadena TXT del DNS. Una de 2048 no, y ese único hecho explica casi todo lo que sale mal cuando un dominio actualiza: el registro tiene que publicarse como varias cadenas entrecomilladas que un verificador vuelve a unir, y las herramientas que hay por medio no siempre colaboran. La clave que sale por el otro lado es más corta que la que generaste, y nada en tu flujo de correo te lo dice.
El RFC 8301 lo dijo en voz alta en 2018. Exige a los firmantes usar al menos 1024 bits y recomienda al menos 2048, y explica en el mismo documento por qué las claves más fuertes siguieron siendo raras: el software de aprovisionamiento de DNS que solo maneja una cadena de 255 bytes en un registro TXT no puede alojarlas.
La longitud de la clave es el valor p=, y solo el valor p=
Un registro DKIM es un registro TXT en <selector>._domainkey.<domain> que contiene una clave pública. La etiqueta p= la lleva, codificada en base64, y su longitud es la longitud de la clave. Nada más en el registro indica la fuerza: no hay etiqueta de bits, ni tamaño de algoritmo, ni campo que un panel de DNS pudiera enseñarte.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Para una clave RSA, p= contiene una estructura SubjectPublicKeyInfo: un contenedor anidado que lleva el identificador del algoritmo y después el módulo y el exponente. La longitud en bits es la anchura de ese módulo, y por eso leerla significa analizar la estructura en vez de medir la cadena.
Eso importa más de lo que parece, porque la longitud de la cadena y la longitud de la clave se separan en cuanto algo trunca el valor.
2048 bits no caben en una sola cadena del DNS
Un registro TXT del DNS se compone de cadenas de caracteres, cada una de 255 bytes como máximo. Los valores más largos se publican como varias cadenas entrecomilladas que un receptor concatena sin separador entre ellas. Medido sobre claves recién generadas, esto es lo que cuesta cada tamaño.
| Clave | Valor p= en base64 | Registro completo | Cadenas DNS necesarias |
|---|---|---|---|
| RSA 1024 | 216 caracteres | 234 | 1 |
| RSA 2048 | 392 caracteres | 410 | 2 |
| RSA 4096 | 736 caracteres | 754 | 3 |
| Ed25519 | 44 caracteres | 66 | 1 |
El registro de ejemplo del propio RFC 8463 publica una clave RSA en cuatro cadenas entrecomilladas, y un verificador las concatena sin nada en medio. Eso es DNS correcto, y un verificador lo maneja sin dificultad.
El fallo está antes del verificador. Un panel de aprovisionamiento que solo acepta una cadena se queda en silencio con los primeros 255 caracteres. Un panel que acepta el valor entero pero mete un espacio o un salto de línea donde estaban las comillas produce un base64 con un carácter que no pertenece al alfabeto. Una exportación y reimportación por fichero de zona puede perder el entrecomillado entero. Todos estos casos producen un registro que sigue empezando por v=DKIM1; k=rsa; p= y sigue viéndose bien en un navegador.
Una clave truncada se lee como un 2048 rotundo si te fías del registro
Esta es la parte que conviene cuidar, porque decide si un comprobador sirve de algo.
La longitud de un módulo RSA se declara dentro de la estructura de la clave. Un lector que se fía de la longitud declarada encuentra la cabecera del módulo, lee el número de bytes que dice tener e informa del tamaño que representarían esos bytes. Si el valor quedó cortado después de esa cabecera, la longitud declarada sigue valiendo 2048 bits aunque los bytes no estén, así que el lector responde "2048" sin dudarlo. Corta una clave real en cada desplazamiento de byte y la inmensa mayoría de esos cortes se informan como una clave intacta del tamaño previsto.
Nuestro propio comprobador DKIM exige que cada longitud anidada de la estructura termine exactamente donde termina su contenedor. Una clave truncada en cualquier punto, o con basura al final, no se puede analizar en vez de informar de un tamaño menor o del previsto, y una clave inanalizable se informa como un fallo y no como una clave ausente. Una clave que no verifica nada y una clave que no está publicada son problemas distintos con soluciones distintas, y un comprobador que los informa igual te manda al sitio equivocado.
En los dominios que probamos para el Unspam 2026 Email Deliverability Benchmark, el 90% firma con una clave DKIM que funciona, así que esto no es un hueco de adopción. Es una categoría de rotura silenciosa dentro de ese 90%.
Un p= vacío es una revocación, no una clave ausente
v=DKIM1; k=rsa; p= sin nada detrás del signo igual es un registro válido, y significa que la clave ha sido revocada. El RFC 6376 lo define así a propósito, para que una clave comprometida pueda retirarse sin borrar el registro y dejar a los verificadores adivinando si el nombre simplemente no resolvió.
Trata la diferencia como real. Un selector revocado es una decisión que tomó alguien; un selector ausente es un despliegue que no se terminó. Se parecen muchísimo en una consulta DNS y piden respuestas opuestas.
Lo mismo vale para una rotación. Los selectores existen para que un dominio pueda llevar varias claves a la vez, y que s1._domainkey y s2._domainkey estén vivos juntos es la forma de rotar sin hueco. La firma nombra el selector que usó y un verificador consulta solo ese, así que publicar la clave nueva antes de cambiar el firmante es el orden seguro, y quitar la vieja antes de que se haya entregado el último mensaje firmado con ella es el orden peligroso.
Las claves Ed25519 son 32 bytes en crudo, no una estructura de clave
El RFC 8463 añadió la firma Ed25519, y el registro para ella no tiene la forma del de RSA. Con k=ed25519, el valor p= es la clave pública de 32 bytes en crudo, no un SubjectPublicKeyInfo, y por eso se codifica en 44 caracteres base64 y siempre cabe en una cadena del DNS.
La consecuencia práctica es que cualquier otra longitud no es una clave. Un fragmento de 30 bytes, un valor truncado o una clave RSA entera olvidada bajo una etiqueta ed25519 son todos inservibles, y un comprobador que informa "Ed25519, presente" ante cualquier valor no vacío no te dice nada. Verifica la longitud, no la presencia.
La adopción sigue siendo lo bastante escasa como para que Ed25519 se publique normalmente junto a RSA y no en su lugar, porque un verificador que no lo admite trata la firma como no verificable en vez de recurrir a la otra.
t=y hace que la firma no cuente para nada, sea cual sea la clave
La etiqueta t lleva banderas, y t=y significa que el dominio está en pruebas. El RFC 6376 le dice a un verificador que "MUST NOT treat messages from Signers in testing mode differently from unsigned email", que es más fuerte que ignorar los fallos: la firma no aporta absolutamente nada, así que DKIM no puede alinearse, y un dominio que depende de la alineación DKIM no obtiene ningún pase de DKIM mientras la bandera esté puesta.
Las banderas de prueba deberían quitarse al final de un despliegue, y muchas veces no se quitan. Si un dominio publica una clave perfecta de 2048 bits, firma todos los mensajes y aun así acumula fallos de DMARC que no se explica, revisa esta etiqueta antes que nada.
La otra bandera de la misma etiqueta es más discreta. t=s prohíbe que la identidad firmante sea un subdominio de d=, lo cual es un endurecimiento deliberado y no un defecto, y también es la diferencia entre un firmante que funciona y uno que deja de funcionar el día que alguien apunta un subdominio a la misma clave.
Qué comprobar en una clave que ya publicaste
Seis comprobaciones, en el orden que encuentra problemas más rápido.
- Que la clave se pueda analizar. No que exista un registro en el selector, sino que el valor de dentro sea una clave completa. Esta es la comprobación que caza una actualización truncada.
- Que la fuerza sea de al menos 1024 y preferiblemente 2048. Por debajo de 1024 un verificador no debe tratar la firma como válida; entre 1024 y 2048 es válida y está por debajo de lo que recomienda el RFC 8301.
- Que
p=no esté vacío, salvo que lo revocaras a propósito. - Que no haya
t=y. Si el despliegue terminó, la bandera de pruebas debería haber desaparecido. - Que cada plataforma que envía como tú tenga su propio selector vivo. Tu ESP, tu CRM, tu servicio de soporte y tu herramienta de facturación publican uno cada uno, y los añaden personas distintas en momentos distintos.
- Que el selector de la firma resuelva. Una clave publicada bajo un nombre que el firmante no usa es invisible.
Que DKIM pase es necesario y no suficiente, porque DMARC necesita que el dominio firmante se alinee con la dirección de tu cabecera From, y un mensaje puede ir firmado a la perfección por el dominio propio de una plataforma y aun así fallar. Nuestra guía sobre firmas DKIM cubre el formato del registro, nuestra guía sobre autenticación del correo cubre cómo dependen unos de otros los tres registros, y la misma forma de fallo silencioso en el lado de SPF es el tema de nuestra guía sobre el mecanismo include de SPF.
Para ver la clave que lee de verdad un receptor, junto al resultado de la firma en un mensaje real, haz una prueba de spam gratis.
