Una configuración de DKIM correcta es fundamental para autenticar el correo de un dominio propio y favorecer su entrega. Una clave ausente, dañada o truncada, o una firma de un dominio incorrecto, puede perjudicar la llegada a la bandeja de entrada. Esta guía explica el procedimiento operativo: generar la clave, publicar el registro DNS, comprobarlo desde la línea de comandos y detectar errores de alineación que todavía pueden hacer fallar DMARC aunque el panel muestre una comprobación favorable.
Si necesitas una configuración completa con MX, SPF, buzones y clientes de correo, empieza por crear correo con tu dominio. Si primero estás eligiendo una plataforma, correo empresarial explica la decisión general.
El problema es sencillo. La mayoría de los fallos al configurar DKIM no se deben a la criptografía. Surgen al copiar registros DNS, en paneles que añaden el dominio dos veces, por claves de 2048 bits dañadas o porque un proveedor de envío firma con su dominio en lugar del tuyo. Puedes perder horas buscando la causa equivocada. La solución es un procedimiento repetible.
Qué hace realmente la configuración de DKIM
Configurar DKIM consiste en publicar una clave pública en el DNS y permitir que el servidor de correo firme cada mensaje con la clave privada correspondiente. Los servidores receptores verifican la firma, comprueban la responsabilidad del dominio firmante y detectan si se han modificado las cabeceras firmadas o el contenido del cuerpo durante el tránsito.
DKIM utiliza criptografía asimétrica. El sistema de envío guarda la clave privada y el DNS publica la pública. Al salir del servidor, el mensaje recibe una cabecera DKIM-Signature con un dominio firmante (d=) y un selector (s=). El receptor consulta ese selector en el DNS y valida la firma frente al contenido del mensaje. El mecanismo está definido en el RFC 6376.
Desde febrero de 2024, Google ha endurecido los requisitos para remitentes masivos. Indica que deben configurar SPF y DKIM, y que al menos uno debe alinearse con el dominio de la cabecera From visible para superar la alineación DMARC. Consulta la redacción vigente en las preguntas frecuentes sobre las directrices de Google para remitentes.
Esto importa porque una firma técnicamente válida no siempre cumple el objetivo. Una configuración de DKIM incorrecta o sin alinear puede dejar problemas de spam, fallos DMARC o ambas cosas.
Antes de modificar el DNS
Una buena configuración empieza por identificar quién firma realmente el correo. Parece evidente, pero es donde suelen surgir interrupciones durante migraciones, cambios de reenvío o de proveedor. El lugar adecuado para generar u obtener registros DKIM depende por completo de la ruta de envío.
Primera pregunta: ¿quién envía el correo saliente de este dominio?
- Si lo envía Google Workspace, genera la clave DKIM en Google Admin.
- Si lo envía Microsoft 365, activa DKIM allí.
- Si lo envían SendGrid, Mailgun o Amazon SES, autentica el dominio en ese proveedor.
- Si lo envía TrekMail Managed SMTP, usa los valores DKIM que muestra TrekMail.
- Si TrekMail aloja los buzones pero usas SMTP externo, sigue las instrucciones de firma de ese proveedor y configura SMTP en TrekMail si hace falta.
TrekMail contempla ambas rutas según el plan. Nano utiliza BYO SMTP; los planes de pago pueden usar SMTP gestionado. La documentación de Bring Your Own SMTP incluye ejemplos de SES, SendGrid y Mailgun. La documentación de diagnóstico también señala que Managed SMTP firma con la clave DKIM de tu dominio, lo que puede ayudar a mantener DMARC en reenvíos y relés si la firma permanece válida y alineada.
Ejemplo: el buzón está en TrekMail, pero el correo sale por SendGrid. SendGrid debe realizar la firma. TrekMail puede almacenar el buzón, pero no configura automáticamente el DKIM de SendGrid por ti.
Primera regla: genera las claves en el sistema que firma el mensaje. Si las generas en otro lugar, el registro puede existir en el DNS sin servir para nada.
Tipos de registro DKIM: TXT frente a CNAME
Normalmente se publica un TXT que contiene la clave pública. Algunos proveedores piden uno o varios CNAME que apuntan a claves alojadas por ellos. Ambos métodos funcionan. Lo importante es usar exactamente los valores que proporciona tu sistema de envío.
La configuración clásica utiliza un TXT en:
selector._domainkey.example.comEl valor tiene este aspecto:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...Los servicios gestionados suelen usar CNAME para poder rotar las claves sin pedirte otro cambio DNS. Con TXT tienes control directo, pero también debes actualizar el registro cuando corresponda rotar la clave.
| Método | Qué publicas | Adecuado para | Riesgo principal |
|---|---|---|---|
| TXT | Clave pública completa en el DNS | Google Workspace y muchas configuraciones autogestionadas o directas | Claves largas truncadas o copiadas incorrectamente |
| CNAME | Alias a un registro DKIM alojado por el proveedor | Plataformas gestionadas y rotación de claves más sencilla | Destino incorrecto o falta de alguno de los registros |
La trampa está en el campo de nombre. Si el dominio es example.com y el selector es k1, normalmente se introduce:
k1._domainkeyNo esto:
k1._domainkey.example.comMuchos paneles DNS añaden automáticamente el dominio raíz. Si introduces el nombre completo en uno de ellos, publicas k1._domainkey.example.com.example.com. El registro no queda donde los receptores lo buscan.
Como referencia de la capa DNS necesaria en TrekMail, consulta registros DNS necesarios. También explica que algunos proveedores requieren dividir el TXT DKIM en partes entre comillas.
Configuración de DKIM paso a paso en el DNS
El procedimiento es breve: obtener el selector, publicar el registro, esperar a que el DNS se actualice, comprobar la respuesta exacta y activar la firma si el proveedor requiere un último ajuste. Sin comprobarlo, solo estás suponiendo que funciona.
Sigue este procedimiento.
- Abre el proveedor de envío y genera o muestra el registro DKIM.
- Copia el selector exactamente. No lo cambies salvo que el proveedor lo permita.
- Crea el registro DNS en
selector._domainkey. - Pega el TXT completo o el destino CNAME tal como se proporciona.
- Establece el TTL en 3600 salvo que tengas otro motivo.
- Espera a la propagación.
- Comprueba con
digonslookupantes de enviar correo de producción. - Activa la firma en el proveedor si hay un interruptor final de activación.
Ejemplo con TXT:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."Ejemplo con CNAME:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.La propagación DNS puede ser rápida, pero no es instantánea. La guía de diagnóstico de TrekMail indica que muchas actualizaciones aparecen en unos 5 a 15 minutos, aunque el tiempo puede variar con el TTL y las cachés. Si el estado no cambia después, revisa el formato, los registros duplicados y el nombre publicado; no descartes tampoco una caché todavía vigente.
DKIM y el problema de las claves de 2048 bits
Una configuración moderna debería usar claves RSA de 2048 bits cuando el proveedor y el alojamiento DNS las admitan. Son más resistentes, pero también más largas y pueden causar problemas en paneles antiguos. Una clave truncada resulta engañosa: parece publicada, pero la verificación falla.
Las directrices de Google recomiendan claves de 2048 bits cuando se admitan y contemplan las de 1024 bits como alternativa para alojamientos que no aceptan registros largos. A menudo el problema no está en el DNS, sino en el panel que lo administra.
Una configuración DKIM de 2048 bits dañada suele presentar uno de estos problemas:
- El panel recorta el valor sin avisar.
- Exige fragmentos entre comillas, pero no lo explica.
- Introduce saltos de línea en la clave base64.
- Escapa caracteres de una forma que el proveedor no espera.
Si el proveedor DNS exige dividir las cadenas, publica el valor así:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"El receptor concatena las partes entre comillas. Es normal. Añadir espacios dentro de la clave no lo es: un carácter adicional puede invalidar la configuración.
Si gestionas muchos dominios, aquí aparece el coste operativo. Un registrador maneja bien los TXT largos; otro no; un tercero los modifica. Por eso las agencias suelen reducir el número de registradores o utilizar firmas con CNAME alojados por el proveedor cuando sea posible. Para entornos con varios clientes, alojamiento de correo multidominio explica el modelo operativo general.
Comprobar que DKIM funciona de verdad
Que un panel muestre «activo» no basta. Una comprobación real consulta el DNS público directamente, revisa el registro devuelto y confirma en las cabeceras de mensajes reales el dominio firmante y el selector esperados. Lo demás es una comprobación parcial.
Empieza por la línea de comandos.
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.comDebes ver el registro v=DKIM1 completo o los fragmentos entre comillas que forman la clave completa. Si la respuesta está vacía, comprueba en este orden:
- Que el selector sea correcto.
- Que el dominio no esté duplicado en el nombre.
- Que el tipo de registro coincida con el solicitado.
- Que el valor esté completo y no truncado.
- Que el registro anterior no siga en caché.
Después envía una prueba a Gmail u otro buzón donde puedas inspeccionar las cabeceras. Busca los resultados de autenticación y la línea de firma DKIM.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...Si el DNS parece correcto pero el correo sigue llegando a spam, revisa otros factores. La guía de correo que llega a spam de TrekMail explica la importancia del DNS, del calentamiento del dominio, de la calidad de la lista y del contenido. DKIM resuelve una parte de la autenticación, pero no proporciona reputación por sí solo.
Ten en cuenta también el reenvío. SPF suele fallar cuando se reenvían mensajes. DKIM puede mantener DMARC válido en muchos de esos casos si la firma sigue intacta y alineada. Si usas reenvío, consulta reenvío de correo para no confundir un fallo SPF causado por el reenvío con un fallo completo de autenticación.
La trampa de la alineación DKIM
La alineación es donde muchas configuraciones «funcionales» dejan de cumplir el objetivo. La firma puede validarse y no aportar un resultado DMARC satisfactorio si el dominio firmante no se alinea con el From visible. Solo a veces es un problema DNS; suele ser un ajuste del proveedor.
Fallo habitual:
From: ceo@example.com
Firmante DKIM:d=sendgrid.net
Resultado: DKIM puede pasar, pero la alineación DMARC puede fallar porque el dominio firmante no se alinea conexample.com.
Google indica que, para remitentes masivos, el dominio From visible debe alinearse con SPF o DKIM a nivel de dominio organizativo. Si tu proveedor firma con su propio dominio, la firma puede ser válida, pero no servir para la alineación DKIM que necesitas.
La solución suele llamarse autenticación de dominio, marca blanca o configuración de return-path personalizado, según el proveedor. Para DKIM, lo importante es que el dominio de la firma quede alineado; cambiar solo el return-path afecta a SPF. La firma final debería verse así:
DKIM-Signature: ... d=example.com; s=s1; ...Esta configuración puede contribuir a DMARC y a la llegada a la bandeja de entrada. Una firma sin alinear no completa esa parte del trabajo.
Enfoque anterior y enfoque nuevo para DKIM
El enfoque anterior es manual y frágil: cada dominio, proveedor, selector y peculiaridad DNS se gestiona por separado. El nuevo consiste en estandarizar: elegir un modelo de envío repetible, centralizar las comprobaciones DNS y no reconstruir la misma solución para cada dominio.
| Enfoque anterior | Enfoque nuevo |
|---|---|
| Generar claves en herramientas distintas esperando que coincidan con el remitente | Generar DKIM en el sistema de envío real |
| Pegar TXT individualmente y esperar las incidencias | Usar firma gestionada cuando sea posible y comprobar con CLI |
| Tratar cada dominio como un caso único | Aplicar un procedimiento común a dominios de clientes y equipos |
| Investigar el spam después de que falle una campaña | Revisar DNS, alineación y cabeceras antes del primer envío de producción |
TrekMail puede encajar en este modelo. Según el plan vigente, permite administrar varios dominios propios desde un panel, usar almacenamiento compartido sin cargos por buzón, migrar buzones mediante IMAP y elegir BYO SMTP o SMTP incluido. Los planes de pago descritos parten de $3.50/mes; comprueba los precios actuales. La plataforma está orientada a equipos, pymes, agencias y MSP que buscan reducir el trabajo de administración del correo.
Si el problema principal es el proceso y no el DNS, consulta gestión del correo de clientes. En entornos multidominio, la falta de responsabilidades claras puede estar detrás de los problemas de entregabilidad, además de los registros.
Lista final para configurar DKIM
Una configuración sólida usa el sistema firmante correcto, el nombre DNS adecuado, la clave completa, comprobaciones de DNS público y una firma alineada para DMARC. Un fallo en cualquiera de estas piezas debilita el conjunto.
- Confirma qué sistema firma el correo saliente.
- Publica exactamente el selector y el tipo de registro del proveedor.
- Usa
selector._domainkeyen el nombre, salvo que el alojamiento DNS pida el nombre completo. - Conserva intactas las claves de 2048 bits. Divide en cadenas entre comillas solo si el panel lo exige.
- Comprueba con
digonslookup. - Envía una prueba y busca
dkim=passy unheader.dalineado en las cabeceras. - Revisa DMARC después de ponerlo en producción.
Eso es todo. Configurar DKIM no requiere complicaciones, sino precisión. Para reducir dependencias, estandariza los dominios y la ruta de envío en TrekMail cuando encaje con tus necesidades, mantén el DNS visible en un lugar y evita repetir tareas manuales costosas.
