Registro DKIM: selectores, rotación de claves y diagnóstico

Si caen las aperturas, no revises solo los asuntos: comprueba también DNS y el registro DKIM. El seguimiento de aperturas es incompleto y su caída no demuestra por sí sola un fallo de autenticación.

SPF verifica la autorización de la IP para una identidad SMTP; DKIM, DomainKeys Identified Mail, permite verificar una firma sobre datos determinados del mensaje. No prueba que todo su contenido permanezca idéntico ni garantiza la identidad visible. Desde 2024, Google y Yahoo exigen DKIM en los envíos masivos comprendidos en sus reglas. Un fallo puede contribuir a rechazo o spam, pero no determina por sí solo el destino del correo.

Para un fundador, configurar DKIM puede parecer una tarea de diez minutos, aunque el plazo varía. Para un proveedor con 500 dominios, implica mantener selectores, rotaciones y sintaxis DNS, incluso cuando un problema aparece a las 9 de la noche de un viernes.

Esta guía operativa explica cómo funciona el registro DKIM en DNS, cómo manejar el límite de 255 octetos por cadena TXT y cómo investigar fallos cuando la verificación del panel no coincide con un envío real.

Qué es un registro DKIM

Un registro DKIM publica una clave pública en un TXT DNS, directamente o mediante la delegación admitida por el proveedor. El receptor la utiliza para verificar una firma asociada al dominio firmante y la integridad de los datos cubiertos según la canonicalización. La firma no demuestra por sí sola autorización del autor visible ni ausencia de contenido malicioso.

La consulta utiliza selector._domainkey.yourdomain.com, donde selector identifica la clave. Este ejemplo está abreviado y no se puede publicar como clave válida:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 declara la versión; k=rsa, el tipo de clave; y p= contiene la clave pública codificada en base64. La privada permanece en la infraestructura firmante y no debe publicarse en DNS. La guía de creación de registros DKIM explica los campos y el proceso completo.

Qué firma DKIM y por qué importa

DKIM no es solo una casilla de configuración. Vincula una firma al dominio firmante y permite comprobar los datos cubiertos, pero no garantiza la identidad humana del remitente ni protege todas las partes del mensaje.

El servidor debe firmar From y puede seleccionar otras cabeceras, habitualmente Subject, Date, To y Message-ID, junto con el cuerpo cubierto. Aplica la canonicalización y un resumen criptográfico, normalmente SHA-256, y firma con la clave privada. La firma viaja en la cabecera DKIM-Signature.

Cuando Gmail, Outlook u otro servidor recibe el mensaje:

1. Lee DKIM-Signature para obtener selector y dominio firmante.
2. Consulta la clave pública en selector._domainkey.yourdomain.com usando los valores de la firma.
3. Verifica criptográficamente la firma con la clave pública; no descifra el contenido del mensaje.
4. Recalcula los resúmenes de los datos recibidos conforme a los parámetros de la firma.
5. Comprueba su correspondencia y las demás condiciones: puede obtener DKIM pass o un resultado de fallo.

Dos propiedades que aporta una validación son la autenticidad de la firma, respecto a la clave del dominio firmante, y la integridad de los datos cubiertos, dentro de la canonicalización utilizada. No exige que cada byte del mensaje completo siga idéntico. La clave pública correcta hace posible la comprobación. La especificación está en el RFC 6376, útil para revisar conformidad y límites del mecanismo.

Reenvío: cuándo puede sobrevivir DKIM

Imagina que el director de un cliente envía una factura a alguien que la reenvía mediante un alias a Gmail. Si conserva el remitente del sobre original y la nueva IP no está autorizada, SPF puede fallar. DMARC solo falla si tampoco existe una firma DKIM válida y alineada; la política local decide el tratamiento, no un rechazo inevitable.

DKIM puede sobrevivir al reenvío si los datos cubiertos permanecen compatibles con la firma y siguen válidas la clave y las demás condiciones. El receptor final consulta DNS del firmante original. Las modificaciones de listas o pasarelas sí pueden invalidar la firma.

Por eso conviene combinar DKIM con una configuración SPF adecuada; la guía de registros SPF para correo explica lo esencial. DMARC necesita SPF aprobado y alineado o alguna firma DKIM válida y alineada, no ambos obligatoriamente.

SRS, según la configuración de reenvío de TrekMail, reescribe la identidad del sobre para que SPF pueda verificar el dominio del intermediario; no restaura la alineación SPF con el From original. Confirma también qué rutas de salida firma TrekMail o tu SMTP externo, sin presumir cobertura universal por defecto.

Selectores y gestión de varias claves DKIM

El selector DKIM indica qué clave pública debe consultar el receptor. Un selector incorrecto es una causa posible de fallos, aunque no se dispone aquí de una proporción medida de todos los problemas.

SPF admite una política aplicable por nombre, no un único TXT de cualquier tipo. DKIM permite publicar claves bajo selectores distintos, como selector._domainkey.yourdomain.com, sujeto a las capacidades DNS y del proveedor. Puedes mantener diez selectores simultáneos si los necesitas, por ejemplo uno por servicio.

Por qué usar varios selectores

Si envías con Google Workspace y Mailchimp, suele ser más práctico y seguro mantener claves distintas por servicio. Compartir la misma clave privada aumenta el alcance de una exposición y muchos proveedores no lo permiten. Cada servicio utiliza su selector:

• Google Workspace: Puede usar google y publicar en google._domainkey.yourdomain.com; confirma el valor asignado.
• Mailchimp: Puede indicar k1 o k2, por ejemplo en k1._domainkey.yourdomain.com. Sigue sus instrucciones actuales.
• TrekMail: Puede proporcionar un selector como tm1 en tm1._domainkey.yourdomain.com, mediante TXT o CNAME según la configuración indicada.

Separar claves permite revocar k1 si se expone el servicio de marketing sin revocar necesariamente la clave corporativa. Aun así, exige revisar firmas en tránsito, dependencias y efectos; los selectores no son una barrera absoluta de reputación ni garantizan continuidad. La guía de selectores explica nombres y cómo identificar los valores asignados.

Un error habitual de publicación

Algunos paneles añaden automáticamente el dominio: puedes intentar crear google._domainkey.yourdomain.com y acabar con google._domainkey.yourdomain.com.yourdomain.com. Una consulta del nombre esperado puede devolver NXDOMAIN aunque exista el otro registro. Contrasta el panel con DNS y envíos reales. La guía de comprobación del estado DNS muestra cómo investigarlo con una consulta dig.

Longitud de clave y rotación

La clave influye en la seguridad de DKIM. Una configuración de hace cinco años merece revisión, pero su edad por sí sola no demuestra debilidad o compromiso. Comprueba algoritmo, longitud, custodia y requisitos actuales.

Claves de 2048 bits

Las claves RSA de 1024 bits se usaron durante años. Google mantiene un mínimo de esa longitud y recomienda 2048 bits cuando sea posible; comprueba por separado los requisitos actuales de Yahoo. Si una instalación antigua de cPanel o Postfix utilizaba 1024 bits antes de 2019, revisa su política y planifica la actualización; no deduzcas un fallo únicamente por la fecha.

Una clave de 512 bits es inadecuada. Si aparece dkim=perm_fail con un motivo como clave débil o política, comprueba la causa concreta. Genera una nueva clave de 2048 bits si corresponde, publica un nuevo selector antes de firmar con él y conserva la clave pública anterior mientras haga falta verificar mensajes en tránsito. Consulta las directrices de Google para remitentes.

Frecuencia de rotación

Una rotación anual es una política operativa posible, no un requisito universal de DKIM. Si se expone la clave privada por una intrusión, mala gestión de secretos o acceso excesivo, actúa según el incidente: alguien podría firmar mientras la clave siga aceptada. No esperes a que se deteriore la reputación del dominio.

Trata la clave privada como un secreto sensible. Mantener la misma durante cinco años exige justificar y revisar la política, no asumir automáticamente que está comprometida. La custodia y la respuesta a incidentes importan tanto como el calendario.

El límite DNS de 255 octetos y cómo gestionarlo

Al pasar a claves de 2048 bits, un valor público de 2048 bits en base64 puede rondar los 400 caracteres según su codificación. Cada cadena TXT admite 255 octetos. Los paneles pueden dividir, rechazar o manejar de otra forma valores largos; no presupongas truncamiento silencioso universal.

Una clave larga puede ocupar varias cadenas entrecomilladas dentro de un único TXT. El RFC 6376 indica que el receptor las concatena sin insertar espacios antes de interpretar la clave.

Ejemplo abreviado de una cadena larga: no publicable como clave completa:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

Ejemplo estructural con dos cadenas que concatena el receptor; sustituye el contenido abreviado:

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

La entrada depende del proveedor DNS. Algunos admiten notación de archivo de zona con paréntesis; otros manejan cadenas en el panel. No las publiques como TXT independientes. Consulta la configuración DNS con proveedores habituales para Cloudflare, Route 53, GoDaddy y otros.

Una delegación CNAME admitida por TrekMail puede evitar gestionar localmente el TXT largo: publicas el alias corto, inferior a 255 caracteres en el ejemplo, y el proveedor administra el destino. Comprueba registros exactos, aislamiento por dominio y estrategia de selectores; un alias estable no garantiza que toda rotación resulte transparente.

Comprobación de la configuración

No dependas solo del indicador «Verificado». Un panel puede mostrar datos de hace horas o días. Combina consultas DNS autoritativas y de resolvedores relevantes con pruebas de firma reales; una consulta aislada tampoco confirma todo el proceso.

Paso 1: comprobar el nombre DNS

En Linux o macOS utiliza el terminal; en Windows puedes abrir la consola y usar nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Sustituye selector por el asignado al envío y yourdomain.com por tu dominio.

Un resultado con v=DKIM1 puede mostrar la versión, aunque su ausencia no invalida automáticamente la clave si se aplica el valor predeterminado. NXDOMAIN no es lo esperado: NXDOMAIN indica que el nombre no existe en esa respuesta. Revisa nombre, publicación y cachés. Esperar 30 minutos es una sugerencia ilustrativa, no un plazo de propagación garantizado.

Paso 2: validar el contenido de la clave

Si el nombre existe y persisten errores, examina el contenido:

dig txt selector._domainkey.yourdomain.com +short

Comprueba dos aspectos:

• Truncamiento: Si la cadena base64 de la clave tiene menos de 200 caracteres y esperabas RSA de 2048 bits, investiga si está incompleta. La longitud es una pista, no una prueba; concatena correctamente todas las cadenas y valida la clave.
• Caracteres alterados: Revisa la cadena base64, saltos, espacios y escapes según el formato TXT y la interpretación DKIM. Algunos espacios permitidos no cambian la clave; otros errores sí invalidan la codificación. Compara el valor interpretado con la clave pública proporcionada.

Paso 3: enviar y leer las cabeceras

Envía a un Gmail que controles, abre el menú de tres puntos y «Mostrar original». Busca Authentication-Results añadido por el servidor receptor de confianza, no por un emisor arbitrario:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass confirma esa comprobación. Si esperabas una firma válida y ves fail, neutral, perm_fail o temperror, investiga el motivo completo; los nombres y significados pueden depender del servidor. La guía de configuración DKIM describe el proceso y puedes consultar la lista de primera configuración para otros pasos de autenticación.

Fallos DKIM: tres escenarios

Puede existir la clave correcta en DNS y aun así fallar una firma. Comprueba la firma concreta, los datos recibidos y toda la ruta; «debería funcionar» no basta como evidencia.

La guía de diagnóstico DKIM amplía motivos y resultados. Estos tres escenarios son ejemplos prácticos, no una clasificación medida de las causas más frecuentes.

Escenario 1: el resumen del cuerpo no coincide

Un fallo del hash del cuerpo puede afectar a la entregabilidad. Indica que el resumen calculado no coincide con el declarado, por cambios incompatibles en los datos cubiertos u otros problemas de procesamiento. No demuestra por sí solo que la firma de las cabeceras sea criptográficamente válida.

Posibles causas:

• Avisos de remitente externo: Una pasarela añade «CORREO EXTERNO - PRECAUCIÓN» antes de verificar DKIM. El cambio puede invalidar el cuerpo firmado. Revisa el orden de verificación y modificación, incluso en Microsoft 365 con reglas de flujo.
• Avisos legales: Una pasarela añade un pie de 15 líneas después de que el servidor haya firmado. Puede alterar el hash. Firma la versión final del contenido bajo tu control, tras revisar cobertura y configuración.
• Reescritura de URL: Mimecast, Proofpoint o Defender for Office 365 pueden transformar google.com en protect.mimecast.com/s/.... Cambios incompatibles con la canonicalización y cobertura pueden invalidar el hash; no toda modificación de bytes lo hace.

En salida, firma después de las modificaciones del contenido que controlas. En recepción, verifica antes de alterarlo y conserva resultados de confianza. Firmar al final de tu pasarela no evita cambios posteriores en otros sistemas. Confirma las rutas y el orden aplicables en TrekMail; consulta el diagnóstico de errores de envío.

Escenario 2: falta de alineación

Puedes encontrar este resultado en las cabeceras:

dkim=pass (signature was valid)

DKIM pasa, pero DMARC puede fallar por falta de alineación DKIM, si tampoco existe otra vía válida y alineada. El destino posterior depende del receptor.

DMARC compara el dominio d= de una firma válida con Header From. El modo estricto exige coincidencia exacta; el relajado permite el mismo dominio organizativo. Cualquier firma DKIM válida y alineada puede aportar la vía necesaria.

Ejemplo ilustrativo:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

La firma es válida para sendgrid.net. La política DMARC del dominio del autor se evalúa respecto a yourcompany.com: sendgrid.net != yourcompany.com. Esa firma no está alineada, pero DMARC aún puede pasar mediante SPF aprobado y alineado u otra firma DKIM alineada.

El proveedor puede ofrecer autenticación de dominio o firma personalizada. Configura una clave DKIM para tu dominio según sus instrucciones, de modo que d= use yourcompany.com en lugar de sendgrid.net cuando corresponda. La compatibilidad y publicación TXT o CNAME varían. Comprende la alineación DMARC antes de cambiar flujos de producción.

Escenario 3: claves débiles o no aceptadas

dkim=perm_fail con un motivo de política o clave débil requiere comprobar la clave real. Claves de 512 o 768 bits son inadecuadas para los requisitos actuales relevantes, pero el texto de error no prueba por sí solo esa longitud. Un fallo permanente de autenticación tampoco indica que todo el mensaje sea irrecuperable o que no haya otras firmas válidas.

Planifica una nueva pareja de 2048 bits y un selector distinto: publica, comprueba, cambia la firma y conserva la clave pública anterior mientras corresponda verificar mensajes antiguos. Si hay compromiso, adapta la revocación al incidente. No borres primero la única clave activa. Consulta las recomendaciones de generación local y la guía de generadores DKIM.

Generadores de claves y precauciones

Para publicar DKIM necesitas una pareja de claves. Si encuentras un generador web que muestra la privada, comprueba dónde se genera y quién puede acceder antes de usarlo en producción.

Mostrar una clave en el navegador no demuestra por definición que haya sido comprometida: puede generarse localmente. Pero un servicio remoto o código no confiable puede conocerla o exponerla. Si alguien la obtiene, podría firmar mientras siga aceptada; no lo hace necesariamente para siempre. Prefiere generación local o infraestructura de un proveedor confiable.

Comparar métodos de generación

Si administras tu servidor, puedes generar localmente con OpenSSL, protegiendo antes permisos y acceso:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

La privada no debe salir sin una necesidad autorizada y un canal seguro. Para DNS usa la pública en el formato correspondiente: cat solo muestra el PEM, no elimina sus cabeceras ni lo convierte automáticamente en el valor requerido. Una petición de enviar la privada por correo para «verificarla» es una señal de riesgo que debes rechazar.

Fundadores y agencias pueden delegar la generación en un proveedor confiable cuando el servicio lo ofrece. Confirma custodia, rotación, revocación y alcance, en lugar de asumir que cualquier gestión delegada ofrece los mismos controles.

Gestión manual y automatizada

La rotación hace visible el trabajo operativo de DKIM. Revisa periódicamente cada clave y sus dependencias. Este ejemplo anual sirve para comparar procesos, no establece un calendario obligatorio.

Ejemplo de rotación manual anual por dominio

1. Genera una pareja RSA con un selector nuevo, por ejemplo s2026.
2. Publica la clave pública en s2026._domainkey.yourdomain.com.
3. El ejemplo reserva 48 horas; comprueba publicación y cachés, sin asumir ese plazo universal.
4. Solo tras verificar la nueva clave, configura la salida con la nueva privada.
5. El ejemplo mantiene ambas claves públicas durante 7 días; ajusta el solapamiento a las colas y mensajes aún verificables.
6. Retira el selector anterior cuando ya no sea necesario y conforme a la política de incidente.
7. Destruye de forma segura la privada retirada cuando no deba conservarse, incluidas las copias pertinentes.

Son 7 pasos por dominio en este ejemplo: con 50 dominios, 350 operaciones antes de pruebas adicionales. Omitir el paso 5 puede afectar a mensajes en tránsito; omitir el 6 puede mantener una clave pública innecesaria. La publicación pública no expone por sí sola la privada, y el proceso puede automatizarse con controles.

Para un único dominio, el trabajo manual puede ser asumible. Con 50, la automatización y un registro de cambios ayudan a evitar olvidos, aunque no garantizan que nunca debas diagnosticar un fallo un viernes.

Cómo encaja TrekMail en la gestión DKIM

TrekMail se dirige a quienes administran varios dominios, desde un fundador con cinco proyectos hasta un proveedor con 800 dominios de clientes. Comprueba que la implementación disponible cubra tus rutas y necesidades.

Delegación CNAME y rotación

El asistente puede indicar un CNAME como este al añadir un dominio. Es un ejemplo del texto, no un destino que debas reutilizar sin validación:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Una delegación estable permite al proveedor administrar el TXT de destino. Cambiar una clave bajo el mismo selector puede invalidar firmas antiguas o en tránsito y afecta a las cachés. Confirma una rotación coordinada con solapamiento y nuevos selectores cuando corresponda, sin presumir ausencia de interrupciones. Una cartera de 80 dominios requiere seguimiento incluso si se reducen ediciones DNS.

El ejemplo de Pro a $8 al mes para 100 dominios estima 700 operaciones manuales evitadas al año. Es una comparación ilustrativa del proceso, no un precio actual verificado ni un ahorro garantizado; las pruebas y controles siguen siendo necesarios.

Asistente DNS

El asistente TrekMail puede reunir recomendaciones para MX, SPF, DKIM y DMARC y sus verificaciones disponibles. Todo resolvedor puede tener caché, así que confirma resultados, inventario y envíos reales antes de confiar en un estado verificado. Consulta los registros DNS necesarios.

Modelo sin tarifa por usuario

El modelo descrito cobra por la plataforma dentro de límites. El texto cita Starter a $3.50 al mes con 50 dominios y 100 usuarios por dominio, Pro a $8 al mes con 100 dominios y 300 usuarios por dominio, y Agency con 1,000+ dominios. Verifica precios, almacenamiento compartido, firma DKIM y límites actuales; añadir cuentas no implica coste ilimitadamente invariable.

La configuración DNS y DKIM indicada depende de las rutas y funciones del plan. Confirma disponibilidad y responsabilidades, sin asumir que toda autenticación queda gestionada por defecto en cualquier transporte.

Comparación de gestión DKIM

Conclusión

Un registro DKIM correcto es importante para la autenticación en 2025 y después, especialmente en los envíos sujetos a requisitos de proveedores. Su ausencia no implica siempre fallo DMARC, pues SPF válido y alineado puede aportar otra vía, pero reduce la capacidad de verificar firmas y puede afectar al tratamiento del correo.

Empieza por una clave RSA de 2048 bits cuando corresponda, el selector correcto, el TXT concatenado adecuadamente y la alineación con From. Después define rotación, revocación y política DMARC con inventario y pruebas, complementados por Google Postmaster Tools cuando haya datos disponibles.

La comparación de SPF, DKIM y DMARC explica sus relaciones y el orden de preparación. Si investigas entregabilidad, la guía para evitar que los mensajes vayan a spam ayuda a priorizar según las evidencias.

Con varios dominios, documenta y automatiza donde resulte útil: una clave incompleta o una firma no alineada puede afectar a los flujos correspondientes. La delegación CNAME de TrekMail puede reducir tareas, pero no elimina todas las causas de fallo. Consulta los planes y verifica la opción gratuita descrita para 10 dominios sin tarjeta de crédito y sus condiciones actuales.