Si envías correo desde tu propio dominio, necesitas publicar registros DKIM en el DNS. Configurarlos correctamente es importante para la autenticación y puede contribuir a la entregabilidad. Sin una firma DKIM verificable, los receptores no pueden comprobar mediante este mecanismo si el contenido firmado ha cambiado durante el tránsito. Google, Yahoo y Microsoft establecen requisitos de autenticación para determinados remitentes, especialmente los de envío masivo; también conviene usar DKIM en dominios de bajo volumen.
Esta guía explica todo el proceso: generar las claves, publicar el registro DNS, activar la firma y comprobar el resultado. Sin rodeos: pasos, sintaxis y errores habituales. Tanto si creas los registros manualmente como si utilizas una plataforma gestionada, los fundamentos son los mismos.
¿Qué es un registro DKIM?
Un registro DKIM es un TXT DNS que contiene la parte pública de un par de claves criptográficas. El servidor de correo firma los mensajes salientes con la clave privada. El receptor obtiene la clave pública del DNS y verifica la firma para comprobar la responsabilidad del dominio firmante y la integridad del cuerpo y de las cabeceras firmadas. DKIM está definido en el RFC 6376 y es un componente esencial de la autenticación moderna del correo.
Cómo crear registros DKIM en 4 pasos
Paso 1: genera el par de claves DKIM
Antes de crear el registro, necesitas un par de claves: una privada que permanece en el sistema firmante y otra pública que se publica en el DNS. El método de generación depende de tu configuración.
Si usas un servicio de correo alojado (Google Workspace, Microsoft 365, Zoho), el proveedor genera las claves. Debes copiar los registros DNS que proporcione. En Google Workspace, ve a Consola de administración > Aplicaciones > Google Workspace > Gmail > Autenticar correo electrónico y pulsa «Generar nuevo registro»; los nombres de las opciones pueden variar.
Si administras tu propio servidor de correo (Postfix, Exim, OpenDKIM), genera el par desde la línea de comandos:
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pemUsa claves de 2048 bits cuando el sistema las admita. Algunas guías antiguas mencionan las de 1024 bits, que ofrecen un margen de seguridad menor en 2026. La aceptación de firmas de 1024 bits depende del receptor y de sus políticas; no conviene elegirlas si puedes usar claves más resistentes.
También debes elegir un selector: una etiqueta que identifica esta clave concreta. Los selectores permiten rotar claves o utilizar claves diferentes para cada servicio. Son habituales google, s1, mail2026 o el nombre del servicio, como sendgrid.
Paso 2: añade la clave pública al DNS
Aquí publicas el registro DKIM en el DNS del dominio. El procedimiento suele ser sencillo. Accede a tu proveedor DNS (Cloudflare, Route 53, GoDaddy, Namecheap) y añade un TXT nuevo, o el tipo de registro que indique tu proveedor de envío.
Campo de host o nombre:
selector._domainkey.yourdomain.comSustituye selector por el nombre elegido en el paso 1. Si el selector es s1 y el dominio es example.com, el nombre completo es:
s1._domainkey.example.comCampo de valor:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickeyLa etiqueta p= contiene la clave pública completa como cadena base64. Elimina las cabeceras PEM (-----BEGIN PUBLIC KEY-----) y los saltos de línea: los datos de la clave deben formar una cadena continua. El valor de ejemplo está abreviado y no sirve como clave real.
Importante: Cada cadena de un TXT DNS tiene un máximo de 255 caracteres de un byte. Una clave RSA de 2048 bits supera ese tamaño al codificarse. Algunos proveedores dividen automáticamente el valor en varias cadenas entre comillas; otros requieren que lo hagas manualmente en fragmentos de hasta 255 caracteres entre comillas dobles. El verificador concatena las cadenas del mismo registro.
Paso 3: activa la firma DKIM en el servidor
Publicar el registro DNS no basta. El servidor debe firmar activamente los mensajes salientes con la clave privada correspondiente.
Google Workspace: Pulsa «Iniciar autenticación» en el panel donde generaste la clave, según la interfaz vigente.
OpenDKIM (Postfix/Exim): Edita /etc/opendkim.conf:
Selector s1
KeyFile /etc/opendkim/keys/example.com/dkim_private.pem
Domain example.com
Socket inet:8891@localhostDespués añade el milter a Postfix en /etc/postfix/main.cf:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891Reinicia ambos servicios tras validar los ajustes para tu instalación:
sudo systemctl restart opendkim
sudo systemctl restart postfixLos proveedores de envío externos (SendGrid, Mailgun, Amazon SES) tienen sus propios procesos de activación. El patrón habitual es recibir registros CNAME o TXT, publicarlos en el DNS y después pulsar «Verificar» en su panel; sigue siempre las instrucciones actuales del servicio.
Paso 4: comprueba el registro
No supongas que funciona. Compruébalo desde el principio.
Desde la línea de comandos:
dig TXT s1._domainkey.example.com +shortLa respuesta debería contener la clave pública. Si está vacía, revisa el nombre, el tipo de registro y el DNS autoritativo, además de las cachés. Algunas guías aconsejan esperar hasta 48 horas, aunque muchos cambios TXT son visibles en minutos; el plazo depende del TTL y no garantiza que un registro incorrecto aparezca.
Con un mensaje de prueba: Envía a una dirección Gmail e inspecciona las cabeceras originales. Busca:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1Si ves dkim=pass, la firma de esa prueba se ha validado. Si aparece dkim=fail o dkim=neutral, investiga la configuración y el motivo concreto del resultado; la siguiente sección recoge errores habituales.
Sintaxis del registro DKIM
Entender la sintaxis ayuda a crear registros correctos, sobre todo la primera vez. Estos son sus componentes:
v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...| Etiqueta | Obligatoria | Significado |
|---|---|---|
v=DKIM1 | Sí | Versión. Si se incluye, debe ser DKIM1 y aparecer al principio. |
k=rsa | No | Tipo de clave. RSA es el valor predeterminado y habitual. La compatibilidad con Ed25519 debe comprobarse en los sistemas implicados. |
p= | Sí | Clave pública en base64. Un p= vacío indica que la clave se ha revocado. |
t=s | No | Restringe el dominio de la identidad AUID de la firma al dominio firmante. No establece la alineación con el From visible; sin esta restricción se permiten subdominios de esa identidad. |
t=y | No | Modo de prueba. Los receptores no deben penalizar los fallos de esta firma más que un mensaje sin firma. Elimínalo cuando hayas comprobado la configuración. |
Errores frecuentes al crear registros DKIM
Los equipos que configuran DKIM por primera vez suelen repetir los mismos errores.
1. Saltos de línea en la clave pública. Es muy habitual. Copiar una clave PEM con saltos de línea al valor DNS puede invalidarla. Elimina los saltos y los espacios de los datos base64.
2. Selector incorrecto en el nombre DNS. Generaste la clave con s1, pero el servidor utiliza default. El receptor busca default._domainkey.example.com, no encuentra la clave y DKIM falla. El selector DNS debe coincidir exactamente con el utilizado al firmar.
3. Varios registros DKIM con el mismo selector. A diferencia de SPF, que requiere un único registro de política por dominio, DKIM permite varias claves con selectores diferentes. Publicar dos TXT separados para s1._domainkey puede invalidar la consulta de clave, no debe dejarse al receptor la elección de uno.
4. Olvidar activar la firma. Añadiste el registro y creíste que bastaba. El DNS solo publica la clave pública; el servidor debe firmar los mensajes con la privada. Sin firma, el registro no autentica el correo.
5. Usar claves de 1024 bits. Pueden seguir siendo aceptadas, pero las directrices de Google para remitentes recomiendan claves de 2048 bits cuando se admitan. Para actualizar, genera otro par, publica la clave pública con un selector nuevo y cambia la configuración de firma. Conserva la clave anterior durante el tránsito de mensajes ya enviados y después revócala dejando vacío su p=.
DKIM, SPF y DMARC: el conjunto completo
DKIM no actúa de forma aislada. Es una parte de un marco de autenticación con tres componentes.
SPF comprueba que la IP del servidor remitente esté autorizada por el dominio evaluado. Es importante, pero puede fallar al reenviar correo porque cambia la IP de envío. Si aún no lo configuraste, consulta la guía de configuración de SPF y cómo funciona SPF en el correo para entender el límite de 10 términos que generan consultas y otras restricciones.
DKIM puede sobrevivir al reenvío porque firma el contenido, no la IP remitente, siempre que los datos firmados permanezcan intactos. Por eso complementa SPF.
DMARC relaciona ambos mecanismos. Indica al receptor una política para los mensajes que no superan DMARC: cuarentena, rechazo o ninguna acción solicitada. Para pasar, al menos SPF o DKIM debe validarse y alinearse con el dominio From visible.
Un objetivo puede ser que SPF pase y se alinee, que DKIM pase y se alinee y, tras revisar todos los remitentes legítimos, aplicar p=reject en DMARC. Esto puede contribuir a una buena reputación del dominio, pero no garantiza una mejor ubicación en la bandeja de entrada.
Para una empresa, este conjunto es una base importante de las operaciones de correo seguras, no una garantía de seguridad completa.
Cómo puede ayudarte TrekMail con DKIM
Para un único dominio, crear registros manualmente suele ser manejable. Con decenas de dominios, la automatización puede reducir el trabajo: rotar claves, coordinar selectores entre servicios y detectar configuraciones incorrectas antes de que perjudiquen la entregabilidad.
El enfoque de TrekMail consiste en mostrar los registros SPF/DKIM/DMARC necesarios al conectar un dominio y comprobar su configuración. La generación y gestión de las claves depende de la ruta de envío: con SMTP gestionado corresponde a la plataforma; con SMTP externo debes obtener los valores del proveedor firmante. Estas comprobaciones pueden señalar problemas, pero no garantizan detectar todas las incidencias antes de que afecten al correo.
- Plan Nano ($0): BYO SMTP (Amazon SES, Mailgun, etc.). Usa los registros DKIM del proveedor que firma. Se presenta sin tarjeta de crédito; comprueba las condiciones actuales.
- Starter ($3.50/mes): SMTP gestionado; comprueba la generación y rotación de claves DKIM disponibles. La oferta descrita incluye una prueba gratuita de 14 días con tarjeta.
- Pro ($10/mes): Varios dominios de envío con sus propios selectores DKIM, según las funciones vigentes. Prueba gratuita de 14 días en la oferta descrita.
- Agency ($23.25/mes): Administración centralizada de dominios de clientes, con una referencia de 100+ dominios. Comprueba los límites y las funciones de rotación y monitorización. Prueba gratuita de 14 días en la oferta descrita.
No se trata solo de comodidad. Un registro DKIM incorrecto puede pasar desapercibido hasta que se observen fallos de autenticación o entrega. La validación automatizada ayuda a detectar problemas, aunque no sustituye las pruebas con mensajes reales.
Conclusión
Para crear registros DKIM correctamente necesitas cuatro elementos: un par de claves de 2048 bits cuando se admita, un TXT DNS bajo el selector correcto, un servidor que firme activamente y una comprobación del resultado. La configuración de un dominio sencillo puede requerir unos diez minutos de trabajo, sin contar esperas ni diagnóstico.
Después de configurar DKIM, añade SPF y DMARC para reforzar la autenticación del dominio. Trabajar sin el conjunto completo puede limitar las señales de confianza y la protección frente a la suplantación, pero configurarlo no garantiza entrega ni seguridad absolutas.
Si prefieres reducir la administración manual del DNS, prueba TrekMail gratis según las condiciones vigentes y utiliza el asistente como apoyo para la configuración.
