Verificador de claves DKIM — validación de selector y estimación de longitud de clave
Escribe un dominio y un selector. El navegador consulta DNS sobre HTTPS el registro TXT en selector._domainkey.tudominio.com, parsea cada tag de la clave publicada (v, k, p, t, h, s, n), estima el tamaño de la clave pública en bits, y marca los problemas que vemos con más frecuencia — claves 1024-bit débiles, flags de modo testing dejados en producción, datos de clave faltantes, claves revocadas con tag p vacío, errores de sintaxis, y registros truncados que exceden el límite de 255 caracteres por string TXT. Sin cuenta requerida; la consulta corre enteramente en tu navegador.
Verifica un selector DKIM
Introduce el dominio y el selector. Selectores comunes: google (Google Workspace), selector1 / selector2 (Microsoft 365), k1 (Mailchimp), s1 / s2 (la mayoría de ESPs). Si no estás seguro, envíate un mensaje de prueba y verifica el valor s= en la cabecera DKIM-Signature.
DNS sobre HTTPS vía cloudflare-dns.com · Sin datos enviados a nuestros servidores
DKIM es la firma criptográfica sobre el mensaje — la prueba de que las cabeceras y el cuerpo no han sido alterados desde que el MTA de envío los firmó con su clave privada
Cuando un mensaje sale de un remitente correctamente configurado, el MTA saliente computa un hash sobre cabeceras seleccionadas (From, To, Subject, Date, más algunas otras) y el cuerpo del mensaje, firma ese hash con una clave privada, y añade una cabecera DKIM-Signature conteniendo la firma, el dominio firmante, el selector, el modo de canonicalización y unos pocos campos más. Cuando el mensaje llega al receptor, el receptor lee el selector y el dominio firmante de la cabecera DKIM-Signature, consulta DNS selector._domainkey.dominiofirmante.com para recuperar la clave pública, recomputa el hash, y verifica la firma contra la clave pública. Si la verificación tiene éxito, DKIM pasa; si algo en el camino manipuló las cabeceras firmadas o el cuerpo, el hash ya no coincide y DKIM falla.
El registro TXT DKIM en sí es corto. Los tags requeridos son v=DKIM1 (versión, siempre DKIM1) y p=CLAVE_PUBLICA_BASE64 (la clave pública en formato DER codificado base64). Tags opcionales comunes son k=rsa o k=ed25519 (tipo de clave, default rsa por RFC 6376), t=y (modo testing — los receptores tratan los fallos como si no existiera DKIM), t=s (alineación estricta — el dominio firmante debe coincidir exactamente con la identidad i=, sin coincidencia de subdominio), h=sha256 (algoritmos hash permitidos, default permite todos los actuales), s=email (restringe la firma a uso de email), y n=texto (notas para lectores humanos, ignorado por receptores).
La longitud de clave es donde los estándares 2026 divergen de los defaults que aún figuran en documentación más antigua de proveedores. NIST depreció formalmente las claves RSA 1024-bit para aplicaciones nuevas en 2013 y las prohibió por completo para uso federal hacia 2019. RFC 8301 de enero 2018 elevó el mínimo DKIM a 1024 bits y recomendó 2048; los verificadores deben rechazar firmas de claves bajo 1024 bits. La guía de remitentes en volumen de Google de febrero 2024 recomienda 2048-bit, el enforcement de Microsoft Outlook de mayo 2025 hace lo mismo, y Amazon SES rota sus claves gestionadas en 2048-bit. Una clave DKIM 1024-bit no rompe la autenticación directamente en 2026 — la firma aún valida si la matemática funciona — pero se lee a los receptores como una configuración de dominio que no se ha tocado desde antes de 2018, lo que contribuye al scoring de confianza más amplio que decide colocación marginal en bandeja.
Para clientes en LATAM y España el contexto regulatorio refuerza la importancia. La AEPD ha priorizado en sus guías 2024-2025 la autenticación de dominio como medida técnica razonable bajo Art. 32 RGPD, y una clave DKIM 1024-bit obsoleta es exactamente el tipo de configuración que un auditor B2B señalará. La ANPD brasileña, el INAI mexicano, la SIC colombiana y la AAIP argentina convergen en línea similar: mantener firma DKIM de longitud actual es parte del estándar mínimo razonable. Para una fintech mexicana bajo LFPDPPP, una aseguradora chilena bajo Ley 19.628, o un retailer panameño con clientes B2B europeos, una clave en 2048-bit con rotación regular evita el flag que de otro modo aparece en cuestionarios de procurement.
La otra perilla es rotación. RFC 6376 recomienda explícitamente rotar claves DKIM periódicamente; la guía operativa de los receptores principales y vendors de tooling DKIM converge en 6 a 12 meses. La rotación importa porque una clave privada que se filtra (de una brecha del proveedor de hosting, de un backup mal configurado, de un ex-empleado con acceso admin) deja a un atacante firmar mensajes que pasan DKIM por tu dominio hasta que revocas la clave. Rotar limita la ventana de exposición. La herramienta arriba te muestra lo que está publicado actualmente; rotación es lo que haces cuando la clave es más vieja que 12 meses o tienes alguna razón para sospechar compromiso.
Cada tag que el verificador parsea, qué significa, y qué valor deberías típicamente usar
Ejemplo de registro RSA 2048-bit
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA[…+392 chars base64…]QIDAQAB
v=DKIM1 Identificador de versión. Siempre DKIM1. Si está presente, debe ser el primer tag. Los receptores que encuentran este tag con cualquier valor distinto a DKIM1 ignoran el registro completamente.
k=rsa | ed25519 Tipo de clave. Default rsa por RFC 6376. ed25519 por RFC 8463 produce claves y firmas más pequeñas pero el soporte entre receptores es desigual en 2026 — mantén RSA como default seguro.
p=CLAVE_PUBLICA_BASE64 La clave pública, formato DER codificado base64. Un tag p= vacío señala una clave revocada — los receptores tratan cualquier firma que reclame este selector como inválida. Claves RSA 1024-bit son ~216 caracteres base64; 2048-bit son ~392; 4096-bit son ~736.
t=y · t=s · t=y:s Flags. y = modo testing (los receptores no aplican consecuencias de fallo DKIM — dejarlo tras el despliegue es error común). s = alineación estricta entre el dominio firmante y la identidad i=. Quita y una vez en producción.
h=sha256 Algoritmos hash permitidos. RFC 8301 depreció sha1; sha256 es requerido. Omitir h significa "cualquier algoritmo soportado" que efectivamente es sha256 en implementaciones actuales.
s=email | * Tipo de servicio. Default * permite cualquier servicio. email restringe la clave a uso de email. Raramente configurado en práctica — el default sirve para casi todos los remitentes.
n=notas Notas legibles por humanos. Ignorado por receptores. Algunos equipos lo usan para registrar la fecha de rotación o el equipo que posee el selector — útil para ops pero invisible al flujo de correo.
g=identidad Granularidad, restringiendo la clave a firmar para una local-part específica. Depreciado por RFC 6376 e ignorado por receptores modernos — no usar.
Los ocho problemas que vemos con más frecuencia al correr este check contra dominios de cliente
No hay registro en la ruta del selector
La causa más común de un check DKIM fallido. O el nombre del selector no coincide con lo que el MTA emisor está usando, el registro nunca se publicó, o la propagación DNS no se ha completado. Verifica el selector revisando el valor s= en una cabecera DKIM-Signature real de tu dominio. Si el registro se acaba de añadir, deja hasta 48 horas para propagación completa.
Tag p= vacío (clave revocada)
Un registro con p= y nada después es la forma definida por DKIM de revocar una clave preservando el registro. Los receptores tratan cualquier firma reclamando este selector como inválida. Es lo correcto para una clave comprometida o retirada — pero solo una vez que dejaste de firmar con ella. Si el registro está vacío y aún estás firmando con este selector, cada mensaje está fallando DKIM.
Clave RSA 1024-bit
Aún funcional en 2026 pero se lee como obsoleto. NIST depreció RSA 1024-bit para aplicaciones nuevas en 2013 y la prohibió para uso federal hacia 2019. La guía de remitentes en volumen de Google 2024 y el enforcement de Microsoft Outlook de mayo 2025 ambos recomiendan 2048-bit. Rota a 2048: genera nueva clave, publícala bajo un nuevo selector, cambia el envío para firmar con el nuevo selector, deja el registro viejo activo 3-5 días por mensajes en tránsito, luego marca el registro viejo como revocado (p= vacío) y finalmente quítalo.
Flag testing t=y dejado en producción
Común tras un despliegue apurado. Con t=y, los receptores tratan los fallos DKIM como si no existiera DKIM — bien para testing, peligroso en producción porque desactiva las consecuencias de fallo en las que DMARC se apoya para alineación. Quita t=y una vez que tu monitoreo confirme que las firmas validan correctamente.
Clave truncada o partida
Un único string TXT está limitado a 255 caracteres por protocolo DNS. Una clave pública RSA 2048-bit es alrededor de 392 caracteres base64 más los tags circundantes, así que el registro completo corre ~440-470 caracteres. El registro debe publicarse como múltiples strings entrecomillados dentro de un solo registro TXT (la mayoría de proveedores DNS manejan esto transparentemente; algunos requieren división manual exactamente en los 255 caracteres). Si la clave parece terminar a los 255 caracteres sin tag de cierre, ese es el síntoma.
Clave obsoleta pasada la ventana de rotación
Las claves mayores a 12 meses se marcan como candidatas a rotación. El verificador no puede saber la edad de la clave solo del registro — pero si sabes cuándo la generaste y ha pasado más de un año, rota. Genera nueva clave bajo nuevo selector, dual-sign durante una ventana de transición, luego retira el selector viejo.
Errores de sintaxis en el registro
Falta de punto y coma entre tags, caracteres inválidos en el base64 (espacios pegados desde la salida de un generador), valores de flag malformados. Los receptores parsean estrictamente; un error de sintaxis causa que el registro sea ignorado. El error más común que vemos: pegar una clave desde una UI web que envolvió el base64 en múltiples líneas, luego publicar sin quitar los saltos de línea.
Sin registro DKIM en absoluto para ningún selector
Algunos dominios nunca publicaron ninguna clave DKIM — dependen solo de SPF. Desde los requisitos de remitentes en volumen Gmail/Yahoo de febrero 2024, esto ya no es viable para remitentes a escala; ambos receptores requieren firma DKIM para correo en volumen. Microsoft Outlook siguió en mayo 2025. Si tus informes agregados DMARC muestran fallos DKIM en general para tu dominio de envío, la respuesta es configurar firma — no arreglar este registro.
La rotación es dual-sign durante la transición, luego retirar — nunca borres una clave viva y reemplázala en una sola edición DNS
El patrón que funciona sin romper deliverability: genera el nuevo par de claves RSA 2048-bit, publica la clave pública en DNS bajo un nuevo selector (llámalo s2 si el viejo era s1), espera 24-48 horas para propagación DNS, configura tu MTA emisor para firmar con la nueva clave, deja correr producción unas horas, luego confirma vía un check DKIM fresco (la herramienta arriba, o leyendo la cabecera DKIM-Signature en un mensaje entregado) que el nuevo selector resuelve y valida. En este punto estás firmando con la nueva clave y la vieja ya no se usa. Deja el selector viejo vivo 3-5 días más para cubrir cualquier mensaje en tránsito que se firmó antes del cambio. Luego marca el registro viejo como revocado reemplazando la clave con un p= vacío, y después de otros 7 días, quita el registro del DNS entero.
El error a evitar: borrar el registro DKIM viejo al mismo tiempo que cambias la configuración de tu MTA. Los mensajes en tránsito entre MTAs pueden estar en vuelo por horas; mensajes retenidos en colas spool durante caídas pueden estar en vuelo por días. Cualquier mensaje firmado con la clave vieja cuya consulta DNS ocurra después de que borraste el registro falla DKIM, falla alineación DMARC, y aterriza en spam — para correo legítimo que tú mismo enviaste. El patrón dual-sign-then-retire añade dos semanas de overhead y elimina el modo de fallo enteramente.
Lo que los equipos preguntan al correr el verificador DKIM por primera vez
No sé qué selector usa mi servicio de envío. ¿Cómo lo encuentro?
+
Tres formas fiables. Primera: envíate un mensaje de prueba desde el dominio que quieres verificar, luego ve la fuente cruda del mensaje (en Gmail: "Ver original"; en Outlook: "Ver fuente"). Encuentra la cabecera DKIM-Signature y busca el tag s= — su valor es el selector. Segunda: revisa la consola admin del servicio de envío: Google Workspace muestra el selector bajo Admin → Apps → Google Workspace → Gmail → Autenticar Email; Microsoft 365 usa selector1 y selector2 por defecto; la mayoría de ESPs documentan sus selectores en guías de setup. Tercera: si tienes múltiples servicios de envío y quieres encontrarlos todos, corre el verificador contra los comunes para tu stack: Google Workspace usa google, Microsoft 365 usa selector1 y selector2, Mailchimp usa k1 o k2, SendGrid usa s1 y s2.
¿Debería estar en DKIM 2048-bit o 4096-bit?
+
2048-bit. El caso para 4096-bit es real en papel — más entropía, mayor horizonte temporal contra avances en criptoanálisis — pero en la práctica operativa dos cosas empujan en contra. Primero, una clave 4096-bit produce un registro de clave pública de alrededor de 736 caracteres base64; una vez que añades los tags circundantes y consideras el límite de 255 caracteres por string TXT, estás de forma fiable encima del umbral donde algunos proveedores DNS y algunos receptores manejan el registro TXT multi-string de forma inconsistente. Segundo, la mejora marginal de seguridad en 4096-bit sobre 2048-bit no es tractora para ningún modelo de amenaza que DKIM aborda — DKIM firma en la frontera del tránsito de email, donde la ventana de ataque relevante es horas a días, no las consideraciones de escala-década que motivan 4096-bit en otros lugares.
La respuesta práctica: 2048-bit para todo salvo que tengas un requisito específico de compliance que mande 4096. Rota cada 6-12 meses, y la cadencia de rotación hace más por la seguridad de lo que los bits extra harían.
¿Por qué el verificador estima la longitud de bits en lugar de dar un número exacto?
+
Calcular la longitud exacta del módulo RSA requiere decodificar el base64 a ASN.1 DER y parsear el BIT STRING. El verificador corre enteramente en el navegador sin empaquetar un parser ASN.1, así que estima el tamaño de clave desde la longitud del string base64: claves RSA 1024-bit producen ~216 caracteres base64 (más o menos algunos por la cabecera ASN.1), 2048-bit producen ~392, 4096-bit producen ~736. El mapeo es preciso dentro de los tamaños RSA estándar; la estimación te dirá correctamente si estás en 1024, 2048, o 4096, aunque no pueda decirte si el módulo es exactamente 2048 bits o 2080 bits. Para propósitos prácticos — la pregunta es "¿1024 o 2048?" no "¿es exactamente 2048?" — ese nivel de precisión es el que necesitas.
¿Es Ed25519 DKIM seguro para desplegar en 2026?
+
Con cuidado, con dual-signing como red de seguridad. RFC 8463 definió Ed25519 para DKIM en 2018, y la criptografía es genuinamente fuerte — las claves Ed25519 son 256 bits (mucho más pequeñas que RSA), las firmas son 64 bytes, y la verificación es más rápida. El problema es el soporte del lado receptor: no cada MTA, cada filtro antispam, cada gateway enterprise legacy en el mundo se ha puesto al día. Algunos receptores aún tratan un mensaje firmado solo con Ed25519 como DKIM-fail porque su software no sabe cómo verificarlo.
El patrón de despliegue que funciona: firma con ambos RSA-SHA256 (bajo un selector) y Ed25519 (bajo otro). Los receptores que entienden ambos validarán el más fuerte de los dos; los receptores que solo conocen RSA validarán RSA e ignorarán Ed25519. Obtienes los beneficios de criptografía más nueva sin el modo de fallo para receptores más viejos. Configura esto solo después de tener RSA funcionando limpiamente — Ed25519 solo no es seguro para desplegar.
DKIM pasa pero DMARC sigue fallando alineación. ¿Por qué?
+
La alineación DMARC requiere que el dominio firmante (el tag d= en la cabecera DKIM-Signature) coincida con el dominio del header From — exactamente bajo alineación estricta (adkim=s en tu registro DMARC), u organizacionalmente bajo alineación relajada (adkim=r, default, donde mail.ejemplo.com alinea con ejemplo.com). DKIM puede pasar criptográficamente mientras aún falla alineación DMARC si el mensaje es firmado por un dominio diferente enteramente — común cuando un remitente de tercero (una plataforma de newsletter, un CRM que envía en tu nombre) firma con su propio dominio en vez del tuyo.
El arreglo es hacer que ese remitente firme con tu dominio — la mayoría de ESPs transaccionales modernos y plataformas de marketing soportan un modo "firmado con tu dominio", a menudo llamado "branded sending" o "DKIM firmado por cliente". El setup involucra publicar la clave pública DKIM de la plataforma en tu DNS bajo un selector que ellos especifican, luego habilitar su modo de firma correspondiente en su consola admin.
¿Cada cuánto debería correr este check?
+
Cada vez que la clave surja normalmente — en el setup inicial, antes y después de cada rotación de clave, al onboard a un nuevo servicio de envío que necesite su propio selector, y trimestralmente como check de mantenimiento para atrapar fallos silenciosos. La razón más común por la que un registro DKIM previamente funcional deja de funcionar es una migración DNS: el equipo mueve DNS a un nuevo proveedor, la interfaz del nuevo proveedor maneja registros TXT largos de forma distinta al viejo, y el registro se trunca o se entrecomilla incorrectamente durante el import. Un check DKIM trimestral en cada selector que usas atrapa la regresión en semanas en lugar de meses después de que un informe DMARC muestre correo fluyendo a spam.