Verificador DKIM

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

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.

Lo que muestra dig, y lo que no

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1El nombre es selector._domainkey.dominioSin selector no hay respuesta: el DNS no tiene un «listar todas las claves».
  2. 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.
  3. 3El tamaño real de la claveopenssl decodifica p=: 2048 bits es lo que pide la RFC 8301.
  4. 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».

Verificación DKIM de github.com: doce claves de seis proveedores, el barrido de selectores y el medidor de tamaño de claveVerificación DKIM de github.com: doce claves de seis proveedores, el barrido de selectores y el medidor de tamaño de claveEl 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.

¿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 mensaje, con su DKIM-Signature
El receptorGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

El mensaje tal como se envió

  • El hash del cuerpo coincide con bh=
  • La firma de los encabezados se verifica

dkim=pass header.d=example.com

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

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegoogleel administrador puede cambiar el prefijo
Microsoft 365selector1 · selector2CNAME hacia el tenant; uno activo, uno en espera
Twilio SendGrids1 · s2CNAME hacia u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAME hacia dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3tres CNAME, uno lleno a la vez
Proton Mailprotonmail · 2 · 3CNAME hacia domains.proton.ch
Amazon SES3 tokens aleatorios32 caracteres aleatorios cada uno: no se pueden adivinar
Postmark20240101000000pmuna fecha y «pm»: no se pueden adivinar
SparkPostscph + MMYYscph y el mes en que se creó la clave
HubSpoths1-<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.

El registro, tag por tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagDefineValoresPor defectoNota
v=VersiónDKIM1DKIM1recomendado; primero si está presente
k=Tipo de claversa · ed25519rsatipos desconocidos: clave ignorada
p=Clave pública (base64)la clave, o vacíoobligatoriovacío = revocada
t=Indicadoresy pruebas · s estrictoningunoy: tratado como sin firmar
h=Hashes permitidossha256 (sha1 prohibido)todossha1 solo falla (RFC 8301)
s=Tipo de servicio* · email*solo otros servicios: ignorado
n=Notas para personascualquier texto–el software nunca lo lee

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).

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

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)

  1. Día 0Publicar la clave nueva en un selector nuevo
  2. Día 1+Cambiar la firma a ella
  3. +7–30 díasConservar la clave antigua para el correo en tránsito
  4. 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ó

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ó

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

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 preguntasSPFDKIMDMARC
Qué demuestraEste servidor puede enviar por el dominio MAIL FROMEl dominio d= firmó; partes firmadas sin cambiosFrom: coincide con un dominio que pasó SPF o DKIM
Dónde estáTXT en github.comTXT en s1._domainkey.github.comTXT en _dmarc.github.com
github.com hoyv=spf1 … ~all12 claves, 6 proveedoresp=quarantine; sp=reject
Sobrevive al reenvíoNo: la IP del reenviador no está listadaSí, cuando el mensaje llega sin cambiosSí, mediante un pass de DKIM alineado
Se rompe cuandoun servicio de envío nuevo no está en el registrocambia el cuerpo o un encabezado firmadoninguno de los dos pasa para el dominio 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.

La firma del correo de ejemplo, tag por tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Versión v=siempre 1
  2. 2Algoritmo a=rsa-sha256 (o ed25519-sha256)
  3. 3Canonicalización c=relaxed tolera el replegado de líneas
  4. 4Dominio de firma d=comparado con From: para DMARC
  5. 5Selector s=la clave en s._domainkey.d
  6. 6Firmado a las t=hora Unix: 24 oct 2026, 9:12
  7. 7Encabezados firmados h=from dos veces = sobrefirmado
  8. 8Hash del cuerpo bh=SHA-256 del cuerpo canónico
  9. 9Firma b=sobre los encabezados de h= y este campo

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

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.