Comprobador DKIM:
¿su clave es suficientemente fuerte?

Escriba su dominio arriba — el selector es opcional. Consultamos el registro TXT en selector._domainkey.sudominio (sondeando diez selectores habituales si lo deja en blanco), analizamos cada etiqueta según la RFC 6376 y después validamos la propia clave: el valor p= se decodifica en base64, la estructura DER interna se recorre campo a campo, y el módulo se mide y se califica — menos de 1024 bits es débil, 1024 aceptable, 2048 o más recomendado. Gratis, sin registro.

El selector es el nombre que va delante de ._domainkey — lo elige quien configuró la firma, y ningún listado DNS lo muestra. Tres formas de encontrar el suyo: abra un mensaje que haya enviado y lea la etiqueta s= en la cabecera DKIM-Signature («Mostrar original» en Gmail); pegue esa cabecera completa en esta herramienta y la extraemos; o deje el selector en blanco y sondeamos los diez valores más habituales — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Encontrar dos selectores activos es normal — así es como funciona la rotación.

Aceptable, aunque anticuada, y conviene ir programando su retirada. Nadie factorizó públicamente el RSA-1024 — pero el NIST lo prohibió para firmas nuevas ya en 2013, la RFC 8301 indica a los firmantes DKIM que deberían usar 2048, y los grandes proveedores de correo firman ellos mismos con 2048. El 1024 no es la emergencia — esa es el 512, factorizado en 2012 con cómputo en la nube alquilado. Es la clave que rota según su calendario en lugar de, tarde o temprano, según el de un atacante.

Modo de pruebas. La RFC 6376 §3.6.1 indica a los verificadores que traten el correo de un dominio en modo de pruebas exactamente igual que el correo sin firmar — incluso cuando la firma verifica perfectamente. Existe para poder probar DKIM en seco durante el despliegue, sin consecuencias. El problema es que funciona demasiado bien: nada se rompe mientras está activo, así que nunca se retira. Su dominio pasa entonces años firmando correo para nada. Si esta herramienta encuentra uno, la solución es borrar cuatro caracteres.

Una revocación deliberada. La RFC 6376 define un p= vacío como «esta clave pública fue revocada». Es la lápida correcta para un selector que retiró, y más clara que borrar el registro, que se ve igual que una errata. De ahí se siguen dos lecturas. Si ya rotó fuera de este selector y nada firma con él, es higiene: déjelo así. Si algún remitente sigue firmando con él, todos esos mensajes están fallando el DKIM ahora mismo. Revise sus informes DMARC en busca de dkim=fail con este selector.

Los verificadores deben admitir hasta 4096 bits (RFC 8301). Pero una clave de 4096 bits produce un valor TXT tan largo que necesita dividirse en varias cadenas, algo que algunas interfaces de proveedores DNS estropean. No le da ninguna seguridad práctica adicional frente a 2048 para una clave que de todos modos debería rotar, así que 2048 es el punto óptimo. La otra vía es k=ed25519 (RFC 8463): claves diminutas de 32 bytes, criptografía moderna. El soporte de los verificadores todavía no es universal, así que los despliegues que lo usan suelen firmar también con RSA en paralelo. Esta herramienta lee k= y le dice cuál publicó.

Por sí sola, no — y preferimos decirlo claramente. DKIM demuestra dos cosas: que el mensaje no se alteró tras firmarse, y que el dominio d= lo respalda. No demuestra que la línea From: que ve su destinatario coincida con ese dominio — un falsificador puede firmar perfectamente con su propio dominio mientras muestra el suyo. Cerrar ese hueco es trabajo de DMARC (la alineación), y decir qué servidores pueden enviar siquiera es trabajo de SPF. La pila que funciona es SPF + DKIM + DMARC. Esta herramienta se asegura de que la parte DKIM sea real — una clave revocada o en modo de pruebas deja cojas, en silencio, a las otras dos.