Este verificador DKIM comprueba los registros DKIM de un dominio como los encuentran los servidores de correo receptores, o verifica la firma de un correo pegado: qué selectores responden, quién firma, qué tan fuerte es cada clave y si se alinea con DMARC.
Fuentes: 140 selectores comunes de 67 proveedores de correo, consultados a través de Google Public DNS (con Cloudflare detrás) · comprobaciones de claves de la RFC 6376 y la RFC 8301 · correos verificados en su navegador · no se guarda nada sobre usted
Consulta los 140 selectores que usan los proveedores de correo en selector._domainkey. más el dominio, porque el DNS no puede listarlos
o suelte un archivo .eml en este cuadro
Comprobado en su navegador: el correo se queda en este dispositivo, salvo que tenga una firma Ed25519 que este navegador no puede comprobar y usted elija enviarlo a nuestro servidor. Solo el nombre de la clave (s._domainkey.d) va al DNS público, y los dominios From y de firma van a dnsrobot.net para consultar su política DMARC.
Pruebe
Lo que verá
Cada DKIM-Signature: quién firmó, con qué clave, sobre qué encabezados
El hash del cuerpo y la firma de los encabezados comprobados por separado, para que un pie añadido en el camino no se tome por una falsificación
Si d= se alinea con el dominio From para DMARC
Riesgos que un pass puede ocultar: l=, From sin sobrefirmar, una clave de menos de 2048 bits
Qué sale de este dispositivo al verificar
Este dispositivo
El correoComprobacionesWebCrypto
selector._domainkey.d TXT?el nombre de la clave
From · d=dominios From y d=
DNS público
Cloudflare, Google como respaldo
dnsrobot.net
la política DMARC
El correo en sí se queda detrás de la línea verde: solo salen nombres, y sus respuestas vuelven. La única excepción es decisión suya: una firma Ed25519 que este navegador no puede comprobar se puede enviar a nuestro servidor, que la comprueba en memoria y no guarda nada.
Un correo inventado firmado por example.com, para ver cada parte
Publicidad
Cómo comprobar un registro DKIM
Escriba el dominio arriba: el verificador consulta los 140 selectores que usan los proveedores de correo, muestra cada clave que encuentra con su tamaño y proveedor, y dice con honestidad cuando no encuentra ninguna. ¿Conoce el selector? Elija Dominio + selector y se comprueba primero.
A mano necesita el selector, porque el DNS no puede listarlos: dig +short TXT selector._domainkey.example.com, o nslookup -type=TXT con el mismo nombre en Windows. El selector es el s= de la DKIM-Signature de cualquier correo (RFC 6376 §3.6.2.1).
dig muestra el texto, no lo que significa: no decodifica el tamaño de la clave, no sigue el CNAME del proveedor y no distingue un espacio en espera de uno roto. Eso es lo que añade este verificador de registros DKIM.
% dig +short TXT selector._domainkey.example.com
Cada cadena TXT en el nombre: únalas para leer la clave.
1El nombre es selector._domainkey.dominioSin selector no hay respuesta: el DNS no tiene un «listar todas las claves».
2Dos cadenas, un registroUna cadena TXT admite 255 bytes, así que una clave de 2048 bits se divide; los receptores la unen sin nada entre las partes.
3El tamaño real de la claveopenssl decodifica p=: 2048 bits es lo que pide la RFC 8301.
4Un CNAME hacia el proveedorSin TXT detrás: el espacio en espera de Microsoft 365, no un error.
La clave de google.com y el selector1 de microsoft.com como los devolvió Cloudflare DNS el 25 de octubre de 2026.
Leer el resultado: el barrido de selectores
La respuesta va primero, como una frase. Debajo, quién firma y la clave en sí, cada tag coloreado sobre sus caracteres exactos con el tamaño de la clave en la escala de la RFC 8301; sobre azul marino, cada selector que consultó la comprobación, para que vea qué se intentó.
Sin nota: una clave retirada o el selector en espera vacío de un proveedor es normal, y «no encontrado entre los selectores comunes» nunca significa «ningún DKIM».
El veredictoUna frase: cuántas claves hay y qué hay que hacer.Quién firmaUna tarjeta por proveedor, encontrado por su CNAME o un selector documentado. Cada chip de selector abre su clave.La claveCada tag coloreado sobre sus caracteres, y el tamaño de la clave en la escala de la RFC 8301.El barrido de selectoresCada nombre consultado, iluminado al responder: verde una clave, ámbar 1024 bits, punteado un espacio en espera.Alineación DMARCSi una clave con el d= de este dominio se alinea con su política DMARC.
Una verificación DKIM de github.com: el veredicto, quién firma, la clave dividida en tags con su tamaño y, sobre azul marino, cada selector que consultó la comprobación. Seleccione un número para ver qué muestra cada parte.
Publicidad
¿Qué es DKIM?
DKIM (DomainKeys Identified Mail) es una firma que un servidor emisor añade a cada mensaje y que los receptores comprueban con una clave pública que el dominio publica en el DNS (RFC 6376). Una firma válida demuestra dos cosas: el dominio de d= la firmó, y las partes firmadas no han cambiado desde entonces.
El remitente calcula el hash del cuerpo en bh= y firma los encabezados elegidos más ese hash con su clave privada en b=. El receptor lee d= y s=, obtiene la clave en s._domainkey.d y rehace ambos cálculos. Un byte cambiado en el cuerpo, o en un encabezado firmado, y falla.
DKIM no dice nada sobre qué hacer cuando falla, y cualquier dominio puede firmar. Esa es la tarea de DMARC: pide una firma válida cuyo d= coincida con el dominio From:.
Un mensaje, firmado en el remitente y comprobado en el receptor
El servidor de example.comfirma con su clave privada
El mismo mensaje, con su Subject cambiado en el camino
El hash del cuerpo coincide con bh=
La firma de los encabezados no se verifica
dkim=fail (signature-mismatch)
Ambos resultados son del motor, a partir del correo de ejemplo de esta página y del mismo correo con su Subject cambiado después de firmarse. RFC 6376 §3.7, RFC 8301.
¿Qué es un selector DKIM y cómo encuentro el mío?
Un selector es el nombre de una clave DKIM: el s= de una firma y la primera etiqueta del nombre DNS donde vive la clave (s1._domainkey.github.com). Un dominio puede tener los que quiera: uno por proveedor, por servidor, por año (RFC 6376 §3.1).
Para encontrar el suyo, abra cualquier correo que envió el dominio y mire el original: en Gmail, Más (⋮) › Mostrar original lista la DKIM-Signature, y su s= es el selector. O pegue el correo en Verificar un correo arriba.
La mayoría de los proveedores usan nombres fijos, así que un barrido los encuentra. Amazon SES, Postmark, SparkPost y HubSpot generan un nombre por cuenta, que solo un correo o el panel del proveedor le dice.
De la firma a la clave, y los nombres que usan los proveedores
32 caracteres aleatorios cada uno: no se pueden adivinar
Postmark
20240101000000pm
una fecha y «pm»: no se pueden adivinar
SparkPost
scph + MMYY
scph y el mes en que se creó la clave
HubSpot
hs1-<HubID>
su número de cuenta
El s1 de github.com como lo devolvió Cloudflare DNS el 25 de octubre de 2026. Nombres de los proveedores tomados de su propia documentación (67 proveedores, 140 selectores en el barrido).
Formato de un registro DKIM: cada tag explicado
Un registro DKIM es un registro TXT de pares tag=valor separados por punto y coma; solo p=, la clave pública, es obligatorio.v=DKIM1 es opcional pero, si está presente, debe ir primero (RFC 6376 §3.6.1).
k= indica el tipo de clave (rsa salvo que diga ed25519), t= lleva indicadores (y pruebas, s estricto), h= limita los hashes y s= los servicios. Un p= vacío revoca la clave a propósito.
Los nombres de tag distinguen mayúsculas de minúsculas y un tag repetido invalida el registro. Los tags desconocidos se ignoran.
Qué longitud tiene p= y cuántas cadenas TXT necesita
RSA 1024216 caracteres · 1 cadena TXT
RSA 2048392 caracteres · 2 cadenas TXT
RSA 3072564 caracteres · 3 cadenas TXT
RSA 4096736 caracteres · 3 cadenas TXT
Ed2551944 caracteres · 1 cadena TXT
límites de las cadenas TXT de 255 bytes (contando «v=DKIM1; k=rsa; p=»)
Las longitudes de p= son de claves SubjectPublicKeyInfo medidas. yahoo.com publica su clave de 2048 bits en 4 cadenas: sirve cualquier división, porque los receptores las unen sin nada entre ellas (RFC 6376 §3.6.2.2).
Publicidad
Claves DKIM de 1024 o 2048 bits, y cómo rotarlas
Use RSA de 2048 bits. La RFC 8301 sigue exigiendo a los verificadores que acepten claves de 1024 bits, pero pide a quienes firman al menos 2048 y a los verificadores que rechacen las claves de menos de 1024 bits. M3AAWG llama a 1024 bits «al borde del ataque» e informa de una clave de 512 bits rota en unas 72 horas por unos 75 $.
Una clave Ed25519 es pequeña (44 caracteres de p=) y, por compatibilidad con versiones anteriores, la RFC 8463 permite a quienes firman añadir una firma RSA junto a ella: dos selectores, dos firmas (RFC 8463).
Rote publicando la clave nueva en un selector nuevo, cambiando la firma, conservando la clave antigua de 7 a 30 días para el correo en tránsito y vaciando luego su p=. M3AAWG sugiere cada seis meses. Proveedores como Fastmail y Microsoft 365 lo hacen por usted con selectores en espera.
Dónde están las claves reales en la escala de la RFC 8301
512102420484096
FallaVálida, pasar a 2048BuenaPuede fallar en algunos receptores
microsoft.com · selector2
github.com · k1
google.com · 20251104
fastmail.com · fm2
archlinux.org · dkim-rsa
archlinux.org · dkim-ed25519 (Ed25519)
Rotación sin interrupción (M3AAWG)
Día 0Publicar la clave nueva en un selector nuevo
Día 1+Cambiar la firma a ella
+7–30 díasConservar la clave antigua para el correo en tránsito
LuegoVaciar el p= antiguo; no reutilizar el nombre
fastmail.comfm1p= vacíofm22048fm3p= vacíotres CNAME, uno lleno: la rotación es un cambio de DNS por parte de Fastmail
Tamaños de clave leídos del DNS el 25 de octubre de 2026, decodificados de cada p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).
¿Por qué falla DKIM? Hash del cuerpo, reenvío y listas de correo
DKIM falla cuando los bytes firmados cambiaron, cuando no se encuentra la clave o cuando la clave no coincide con la firma. El reenvío que deja el mensaje sin cambios mantiene DKIM intacto (a diferencia de SPF); las listas de correo suelen romperlo, porque añaden pies o etiquetan el asunto.
El verificador de esta página comprueba por separado el hash del cuerpo y la firma de los encabezados, así que puede distinguir un pie añadido en el camino de una falsificación.
El hash del cuerpo no se verificó
clavecuerpoencabezados
Una lista de correo añadió un pie de 153 bytes. Los encabezados aún se verifican con la clave de project.example, así que no es una falsificación.
Solución Listas que mantienen el cuerpo intacto, o ARC (RFC 8617) para que los receptores posteriores vean el resultado original.
body-hash-mismatch
La firma no se verificó
clavecuerpoencabezados
Un encabezado firmado cambió después de firmarse (una lista que añade su nombre al Subject), o el selector ahora contiene otra clave.
Solución No reescriba los encabezados firmados; publique una clave nueva en un selector nuevo en lugar de reemplazar una.
signature-mismatch
Sin clave para la firma
clavecuerpoencabezados
s=2023old._domainkey.shop.example es NXDOMAIN: el selector se eliminó mientras aún había correo firmado con él en tránsito.
Solución Mantenga publicadas las claves antiguas de 7 a 30 días tras el cambio; vacíe p= en lugar de eliminar.
key-not-found
Reenvío: un reenvío que pasa el mensaje sin cambios mantiene DKIM válido, por lo que DMARC suele sobrevivir al reenvío gracias a DKIM aunque SPF falle.
DKIM frente a SPF y DMARC
SPF dice qué servidores pueden enviar por un dominio, DKIM demuestra que un dominio firmó el mensaje y que no se modificó, y DMARC une ambos a la dirección From: y dice qué hacer cuando fallan.
Responden preguntas distintas, así que necesita los tres: Gmail y Yahoo exigen SPF y DKIM a los remitentes masivos, además de un registro DMARC, y la RFC 9989 pide a los dominios con p=reject que firmen con DKIM en lugar de depender de SPF.
Tres registros, tres preguntas
Tres registros, tres preguntas
SPF
DKIM
DMARC
Qué demuestra
Este servidor puede enviar por el dominio MAIL FROM
Los registros de github.com tal como se leyeron el 25 de octubre de 2026.
Cómo leer el encabezado DKIM-Signature de un correo
Abra el mensaje original y busque el encabezado DKIM-Signature: d= es quién firmó, s= qué clave, h= lista los encabezados firmados, y bh= y b= son los dos hashes que comprueba un receptor.
El veredicto del receptor es un encabezado aparte que se añade al llegar: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. La página «Mostrar original» de Gmail (en inglés) lo resume como «DKIM: 'PASS' with domain example.com».
Un mensaje puede llevar varias firmas, una por firmante (su dominio y su servicio de correo, o una lista de correo). Basta una sola firma válida cuyo d= coincida con el dominio From: para DMARC.
El correo de ejemplo inventado que carga esta página (example.com, una clave creada para él), verificado por el motor.
Verificador DKIM: preguntas frecuentes
¿Qué es un registro DKIM?
Un registro DKIM es un registro TXT que publica la clave pública de un dominio en selector._domainkey.dominio, como google._domainkey.example.com. Contiene pares tag=valor: p= es la clave en base64 y es obligatoria, k= el tipo de clave, t= indicadores. Los receptores lo obtienen para comprobar la DKIM-Signature del correo entrante. Un dominio puede publicar muchos, uno por selector, normalmente uno por servicio de envío.
¿Cómo encuentro mi selector DKIM?
Abra cualquier correo que envió el dominio, vea el mensaje original y busque el encabezado DKIM-Signature: el valor después de s= es el selector, y d= el dominio. En Gmail use Más (⋮) › Mostrar original; en Outlook en la web, View › View message source. O pegue el correo en Verificar un correo arriba, que lee s= y d= por usted.
¿Por qué el verificador no encuentra ninguna clave si mi correo está firmado?
Porque el DNS no puede listar selectores: una clave solo se encuentra pidiendo su nombre exacto. El verificador consulta los 140 nombres que usan los proveedores; si su dominio firma con otro (Amazon SES y Postmark generan uno por cuenta), el barrido no lo ve. Añada el selector del s= de un correo y se comprueba primero, o verifique un correo en su lugar.
¿Sigue siendo aceptable una clave DKIM de 1024 bits?
Todavía funciona: la RFC 8301 exige a los verificadores que acepten claves RSA de 1024 a 4096 bits, y Gmail y Yahoo fijan 1024 bits como mínimo. Pero la RFC 8301 pide a quienes firman al menos 2048 bits, y M3AAWG llama a 1024 al borde del ataque. Planifique una rotación: Microsoft 365 y Google Workspace ofrecen ambos claves de 2048 bits. La RFC 8301 indica a los verificadores que rechacen las claves de menos de 1024 bits.
¿Qué significa un p= vacío?
Un p= vacío significa que la clave está revocada: las firmas con ese selector fallan, exactamente como si faltara la clave. Normalmente es deliberado. Google mantiene así sus antiguos selectores con fecha, y Fastmail y Microsoft 365 mantienen selectores en espera vacíos para rotar hacia ellos. Solo es un problema si es el selector con el que su correo se firma hoy.
¿Qué significa t=y en un registro DKIM?
t=y marca la clave como en pruebas: los receptores deben tratar el correo firmado con ella como sin firmar, aunque la firma se verifique. Está pensado para una primera configuración y a menudo se olvida. t=s es distinto: significa estricto, así que el i= de las firmas debe ser exactamente el dominio de firma, no un subdominio. Algunos servicios de correo publican t=s en sus claves; las claves de SendGrid para github.com lo llevan.
¿Por qué falla DKIM con «body hash did not verify»?
El cuerpo que el receptor calculó no coincide con el valor bh= de la firma, así que el cuerpo cambió después de firmarse. Lo causan las listas de correo que añaden un pie, las pasarelas de seguridad que reescriben enlaces y los avisos legales que añade un servidor. Si la firma de los encabezados aún se verifica, el mensaje es genuino pero modificado; el verificador de esta página comprueba ambas cosas por separado.
¿Sobrevive DKIM al reenvío de correo?
Normalmente, sí. Un reenvío que pasa el mensaje sin cambios mantiene la firma válida, porque DKIM firma el contenido, no la ruta. Esa es la diferencia con SPF, que falla en la dirección IP del reenviador. Los reenvíos que alteran el mensaje, como las listas de correo que añaden pies o etiquetas en el asunto, rompen DKIM; ARC les permite dar fe del resultado original.
¿Necesito DKIM si ya tengo SPF?
Sí. SPF se rompe cuando se reenvía el correo y solo cubre la dirección MAIL FROM oculta, mientras que DKIM sobrevive al reenvío y puede alinearse con el dominio From: que comprueba DMARC. Gmail y Yahoo exigen ambos a los remitentes masivos, Outlook.com desde mayo de 2025, y la RFC 9989 pide a los dominios con p=reject que firmen su correo con DKIM.
¿Con qué frecuencia debo rotar las claves DKIM?
M3AAWG recomienda al menos cada seis meses. Publique la clave nueva en un selector nuevo, cambie la firma a ella, mantenga publicada la clave antigua de 7 a 30 días para que el correo en tránsito aún se verifique y luego vacíe su p= en lugar de eliminarlo. No reutilice nunca el nombre de un selector. Los proveedores alojados con selectores CNAME rotan las claves por usted.
¿Se sube mi correo cuando lo verifico aquí?
No. Este validador DKIM comprueba el correo en su navegador: al DNS público solo se le piden los nombres de las claves (s._domainkey.d), y a dnsrobot.net solo la política DMARC del dominio From y de los dominios de firma. La única excepción es una firma Ed25519 que un navegador no puede comprobar: entonces la página pregunta antes de enviar el correo una vez a nuestro servidor, que lo comprueba en memoria y no guarda nada.
¿Puedo usar una clave DKIM Ed25519?
Sí. La RFC 8463 la define y exige a los verificadores que la admitan. Por compatibilidad con versiones anteriores, publíquela en su propio selector junto a una clave RSA y firme cada mensaje dos veces, como hace archlinux.org con dkim-ed25519 y dkim-rsa: los receptores que no pueden verificar Ed25519 aún tienen la firma RSA. Microsoft 365 y Google Workspace solo ofrecen claves RSA.