Qué es DKIM y por qué importa en 2026
DKIM (DomainKeys Identified Mail) es un estándar de autenticación de correo definido en la RFC 6376 que permite a un dominio firmar criptográficamente los mensajes salientes. El receptor obtiene la clave pública correspondiente desde DNS, recalcula la firma y confirma que el mensaje fue autorizado por el dueño del dominio y no se alteró en tránsito. Sin DKIM, un suplantador puede falsificar tu From:, dañar tu reputación de remitente y desviar respuestas hacia dominios parecidos — un problema que la mayoría de equipos solo nota cuando la entregabilidad se hunde.
En 2026, DKIM ya no es opcional. Las reglas de remitentes masivos de Gmail y Yahoo — vigentes desde febrero de 2024 y endurecidas durante 2025 — exigen que cualquier dominio que envíe más de 5.000 mensajes al día publique SPF, DKIM y DMARC válidos. Microsoft 365 anunció una aplicación equivalente para remitentes de alto volumen. Un fallo de DKIM ya no solo baja tu tasa de bandeja de entrada; provoca rechazos duros, informes dmarc=fail y, en muchos casos, salida de la lista permitida del destinatario. Validar DKIM cada semana es el seguro de entregabilidad más barato que puedes contratar.
Cómo funciona DKIM — Criptografía de clave pública/privada
DKIM se apoya en criptografía asimétrica estándar. Cuando configuras DKIM, tu plataforma genera un par de claves RSA: una privada que se queda en el servidor de envío y una pública que publicas en DNS. Cada mensaje saliente se hashea (cuerpo + cabeceras seleccionadas), el hash se cifra con la clave privada y el resultado se adjunta como cabecera DKIM-Signature. El receptor recoge tu clave pública desde DNS, descifra la firma, recalcula el hash sobre el mensaje recibido y los compara. Si coinciden, DKIM pasa; si no, la firma está rota y el mensaje se trata como sospechoso.
La cabecera DKIM-Signature lleva los metadatos que el receptor necesita para verificar: v= (versión), a= (algoritmo, normalmente rsa-sha256), d= (dominio firmante), s= (selector), c= (canonicalización, normalmente relaxed/relaxed), h= (cabeceras firmadas), bh= (hash del cuerpo) y b= (la firma). Juntos le dicen al receptor exactamente qué registro DNS pedir y qué bytes están cubiertos.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KX5vRn3...truncated...¿Qué es un selector DKIM?
Un selector DKIM es una etiqueta corta que permite a un dominio publicar varias claves DKIM al mismo tiempo. Los receptores localizan la clave pública combinando el selector y el dominio firmante en un nombre DNS con la forma selector._domainkey.dominio.com. Por ejemplo, Google Workspace usa google._domainkey.example.com, mientras que un mensaje firmado con Mailgun se busca en k1._domainkey.example.com. Los selectores son críticos porque te permiten rotar claves, ejecutar varias plataformas de envío en paralelo (transaccional, marketing, ventas) y desplegar nuevas claves antes de retirar las antiguas — todo sin que dos registros choquen. No hay comodín ni fallback en _domainkey.dominio.com; el selector es obligatorio.
Example DNS record format:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."5 errores comunes de DKIM y cómo arreglarlos
La consulta DNS no devuelve nada
El receptor consultó selector._domainkey.tudominio.com y obtuvo NXDOMAIN. Es el fallo DKIM más común. Causas: nunca se publicó el registro TXT, se publicó con el selector equivocado o se añadió en el ápice (tudominio.com) en lugar del subdominio del selector. Solución: vuelve a publicar el nombre exacto que te dio tu proveedor (p. ej., google._domainkey) como registro TXT y verifica la propagación con dig TXT selector._domainkey.tudominio.com o ejecutando este checker. Deja hasta 48 horas para propagación global.
Clave pública inválida
DNS devuelve un registro pero el valor de p= está mal formado, truncado o el receptor lo rechaza. La causa más frecuente es una clave de 2048 bits dividida en varias cadenas TXT y reensamblada mal — muchas UI de DNS añaden comillas, espacios o saltos de línea sueltos. Solución: copia la clave pública exactamente como te la exportó la plataforma de correo, pégala como un único valor TXT (la mayoría de proveedores autodividen en el límite de 255 bytes) y confirma que el registro contiene v=DKIM1; k=rsa; p=BASE64KEY sin espacios dentro del bloque base64.
Hash del cuerpo no coincide
DKIM firmó bh=ABC pero el receptor calculó bh=XYZ sobre el cuerpo recibido, así que la verificación falla. Eso significa que algo modificó el mensaje tras firmarlo. Culpables habituales: un gateway aguas abajo (antivirus, DLP, lista de correo) reescribe enlaces o añade un pie, un relay SMTP recodifica los finales de línea, o un reenviador elimina adjuntos. Solución: firma con canonicalización relaxed/relaxed (tolera cambios de espacios), retira el middleware que reescribe o — para listas — implementa ARC para preservar la DKIM original entre saltos.
Falló la verificación de la firma
El hash del cuerpo coincidía pero la firma criptográfica no verificó contra la clave pública. Causas: el servidor firmó con una clave privada que ya no encaja con la pública publicada (típico tras una rotación donde se actualizó el DNS pero no la caché del servidor de correo), la clave pública en DNS se editó y se corrompió, o el algoritmo en a= no coincide con el tipo de clave. Solución: vuelve a exportar la clave pública desde la plataforma de envío, republícala literalmente y reinicia el servicio de correo para que recargue su clave privada.
Selector no encontrado o equivocado
Tu servidor firma con el selector s1 pero DNS solo publica s2, o migraste de proveedor y el selector antiguo se retiró. Solución: comprueba la etiqueta s= en la cabecera DKIM-Signature de un correo saliente real (la mayoría de clientes te dejan ver cabeceras completas), confirma que existe un registro TXT exactamente en ese selector y elimina selectores obsoletos sin clave privada — los antiguos con p= vacío provocan fallos duros.
Configuración DKIM paso a paso
- 1
Elige la longitud de clave (1024 vs 2048 bits)
Elige siempre RSA de 2048 bits en 2026. Los receptores siguen aceptando claves de 1024 bits, pero Gmail, Yahoo y Microsoft ahora las marcan como débiles en los informes DMARC, y los equipos de seguridad fallan auditorías que encuentren DKIM de 1024 bits en producción. La única razón para bajar a 1024 es un proveedor DNS legacy que no almacene un TXT de más de 255 bytes — y casi todos soportan ya el split multi-string. Las claves de 2048 bits añaden unos dos milisegundos al firmado, despreciable para cualquier servidor de correo en producción.
- 2
Genera el par de claves
La mayoría de plataformas las genera por ti — Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark y Amazon SES tienen una página DKIM de un clic que produce ambas mitades y te muestra la pública para publicar. Si gestionas tu propio servidor (Postfix + OpenDKIM, Exim o Haraka), usa opendkim-genkey -b 2048 -d tudominio.com -s s1, que escribe s1.private (mantenla en secreto) y s1.txt (publícala). Nunca reutilices una clave entre dominios o plataformas.
- 3
Añade la clave pública como registro TXT
Crea un registro TXT en selector._domainkey.tudominio.com — por ejemplo s1._domainkey.example.com — con valor v=DKIM1; k=rsa; p=MIIBIjANBgkq... pegado del .txt que generó tu herramienta. Muchos proveedores DNS dividen automáticamente el valor en bloques de 255 bytes; está bien, los receptores los reensamblan. Pon TTL de 3600 segundos mientras pruebas y súbelo a 86400 cuando esté estable. No incluyas las comillas que rodean la salida del generador como parte del valor.
- 4
Configura tu servicio de correo para firmar con la clave privada
En plataformas gestionadas es automático en cuanto publicas el registro DNS y haces clic en Verify. En servidores autogestionados, apunta tu milter (OpenDKIM, Rspamd) al fichero .private, fija el selector para que coincida con el registro DNS y reinicia el proceso de correo. Envía un mensaje de prueba a un Gmail y mira el origen — deberías ver Authentication-Results: dkim=pass header.d=tudominio.com. Si ves dkim=none, el servidor aún no firma; si dkim=fail, las claves no coinciden.
- 5
Prueba con un DKIM checker gratuito
Usa este DKIM Checker para confirmar la publicación en DNS, después envía un correo de prueba real a mail-tester.com o a un Gmail tuyo e inspecciona las cabeceras. Esperado: Authentication-Results muestra dkim=pass y el selector coincide con el registro publicado. Vuelve a probar tras cada rotación de claves, cada nueva plataforma de envío y al menos una vez al trimestre. Añade el chequeo a tu herramienta de monitorización para que un fallo silencioso de DKIM no tumbe tu entregabilidad durante semanas.
Selectores DKIM comunes por proveedor
Cada plataforma de correo elige su propia convención de selector. Conocer la convención acelera mucho el troubleshooting — si recibes un mensaje de Google Workspace y DKIM está roto, ya sabes que toca consultar google._domainkey antes de barrer cincuenta alternativas. Aquí los selectores que usan los grandes proveedores en 2026:
Google Workspace — google._domainkey.tudominio.comMailgun — k1._domainkey.tudominio.com (a veces mta._domainkey)SendGrid — s1._domainkey.tudominio.com y s2._domainkey.tudominio.com (basados en CNAME)Mailchimp — k1._domainkey.tudominio.com y k2._domainkey.tudominio.comMicrosoft 365 — selector1._domainkey.tudominio.com y selector2._domainkey.tudominio.comPostmark — pm._domainkey.tudominio.com (o 20XXXXXXX.pm._domainkey)Amazon SES — selectores aleatorios personalizados como abc123._domainkey.tudominio.com (basados en CNAME)Mandrill (de Mailchimp) — mandrill._domainkey.tudominio.comConstant Contact — ctct1._domainkey.tudominio.com y ctct2._domainkey.tudominio.comConvertKit — ck._domainkey.tudominio.comMailjet — mailjet._domainkey.tudominio.comBrevo (antes Sendinblue) — mail._domainkey.tudominio.com
El DKIM Checker de Nova Uptime escanea automáticamente todos los anteriores más 38 selectores adicionales en paralelo, así que no necesitas saber por adelantado cuál usa tu proveedor.
Requisitos de Gmail y Yahoo en 2026
Desde febrero de 2024, Gmail y Yahoo aplican autenticación más estricta a cualquier dominio que envíe más de 5.000 mensajes al día a sus usuarios. Las reglas: cada mensaje debe ir firmado con un registro DKIM válido (recomendado 2048 bits), SPF debe alinearse con el dominio del From: y debe haber una política DMARC publicada — como mínimo p=none — con un rua= alcanzable. Durante 2025 y entrando en 2026, ambos proveedores han bajado el umbral de volumen y empezado a rechazar mensajes en bloque (5.7.26) en lugar de enviarlos a spam. Microsoft 365 inició aplicación equivalente en mayo de 2025. Efecto práctico: un único registro DKIM roto provoca rebotes duros, no solo problemas de bandeja de entrada, y la recuperación lleva días porque los informes DMARC tienen un retraso de 24 horas. La monitorización continua ya no es opcional.