SPF, DKIM y DMARC: guía práctica para administradores

Hace unos años configurar un servidor de correo era instalar Postfix y listo. Hoy, si no tienes SPF, DKIM y DMARC bien configurados, tus correos acaban en spam — o peor, alguien puede enviar correos suplantando tu dominio sin que puedas hacer nada.

Los tres son registros DNS. Los tres sirven para autenticar el correo. Pero hacen cosas distintas y se despliegan en un orden concreto. Este artículo explica cómo funcionan, cómo se configuran y cómo se verifica que todo está bien.

El contenido de este artículo tiene fines educativos. Las técnicas descritas están pensadas para su uso en sistemas propios o con autorización. El autor no asume responsabilidad por usos que contravengan la legislación aplicable.

El problema que resuelven

El protocolo SMTP no tiene autenticación de origen. Cualquier servidor puede enviar un correo diciendo que viene de @tu-empresa.com. Esto es spoofing, y es trivial de hacer.

SPF, DKIM y DMARC son tres capas de defensa que los servidores receptores (Gmail, Outlook, tu servidor de correo) consultan para decidir si un correo es legítimo:

Sin los tres, tu dominio está expuesto. Con solo SPF o DKIM, sigues teniendo huecos. DMARC es lo que los une y les da dientes.

SPF — quién puede enviar en tu nombre

Qué hace

SPF (Sender Policy Framework) es un registro TXT en tu DNS que lista qué servidores IP están autorizados a enviar correo desde tu dominio. Cuando llega un correo de @ejemplo.com, el servidor receptor consulta el DNS de ejemplo.com y comprueba si la IP del servidor que lo envió está en esa lista.

Sintaxis básica

v=spf1 [mecanismos] [modificador final]

Un SPF típico para una empresa que usa Google Workspace y tiene un servidor propio:

v=spf1 include:_spf.google.com ip4:203.0.113.45 ~all

Los mecanismos más usados:

El modificador final determina qué pasa si la IP no está en la lista:

Errores comunes

Demasiados lookups DNS. SPF tiene un límite de 10 consultas DNS por evaluación. Cada include: cuenta como una. Si superas 10, el registro falla con PermError. Si usas varios servicios de email (marketing, CRM, transaccional), puedes llegar al límite fácilmente.

# Verificar cuántos lookups tiene tu SPF
dig TXT ejemplo.com | grep spf

Dos registros SPF. Solo puede haber uno. Si tienes dos registros v=spf1, la validación falla. Si necesitas añadir servidores, edita el existente.

Usar -all antes de validar en producción. Si pones -all desde el principio y hay un servidor legítimo que no has incluido, tus correos se rechazan. Empieza con ~all, verifica que todo funciona, y entonces pasa a -all.

Crear el registro

En tu panel DNS, crea un registro TXT en la raíz del dominio (@ o ejemplo.com):

Tipo: TXT
Nombre: @
Valor: v=spf1 include:_spf.google.com ip4:203.0.113.45 ~all
TTL: 3600

Verificar

# Consulta directa
dig TXT ejemplo.com +short

# Con nslookup
nslookup -type=TXT ejemplo.com

DKIM — la firma digital del correo

Qué hace

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada correo que envías. El servidor que recibe el correo consulta tu DNS para obtener la clave pública y verifica que la firma es válida. Si alguien modifica el correo en tránsito (cabeceras, cuerpo), la firma no coincide y el correo falla DKIM.

A diferencia de SPF, que valida el servidor que envía, DKIM valida la integridad del contenido.

Cómo funciona

1. Tu servidor de correo tiene un par de claves RSA: privada (en el servidor) y pública (en tu DNS)
2. Al enviar un correo, el servidor firma parte de las cabeceras y el cuerpo con la clave privada
3. La firma viaja en la cabecera DKIM-Signature del correo
4. El servidor receptor descarga la clave pública de tu DNS y verifica la firma

Generación de claves

Si usas Postfix con opendkim:

# Instalar
apt install opendkim opendkim-tools

# Generar par de claves para el selector "mail" del dominio ejemplo.com
opendkim-genkey -t -s mail -d ejemplo.com

# Genera dos ficheros:
# mail.private — clave privada (va en el servidor)
# mail.txt     — registro DNS con la clave pública

El fichero mail.txt contiene algo así:

mail._domainkey IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."  )

Publicar en DNS

El registro DKIM va en un subdominio específico: selector._domainkey.ejemplo.com

Tipo: TXT
Nombre: mail._domainkey
Valor: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
TTL: 3600

El selector (mail en este caso) es un nombre que tú eliges. Puedes tener varios selectores activos — útil para rotar claves o tener distintos selectores para distintos servicios de envío.

Configurar Postfix + opendkim

# /etc/opendkim.conf
Domain                  ejemplo.com
KeyFile                 /etc/opendkim/keys/mail.private
Selector                mail
Socket                  inet:12301@localhost

# /etc/postfix/main.cf — añadir al final
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12301
non_smtpd_milters = $smtpd_milters

systemctl restart opendkim postfix

Si usas un servicio externo

Google Workspace, Microsoft 365, Mailchimp, Brevo — todos generan sus propias claves DKIM y te dan el registro DNS que tienes que publicar. Solo tienes que copiar y pegar. El proceso de generación manual solo aplica si gestionas tu propio servidor de correo.

Verificar

# Consultar el registro
dig TXT mail._domainkey.ejemplo.com +short

# Enviar un correo a [email protected]
# Te responden con un informe completo de SPF/DKIM/DMARC

Rotación de claves

DKIM usa RSA. Las buenas prácticas dicen rotar las claves cada 6-12 meses:

1. Generar un nuevo par con un selector distinto (mail2, 202601, lo que prefieras)
2. Publicar la nueva clave pública en DNS
3. Esperar a que propague (TTL)
4. Cambiar el servidor para firmar con la nueva clave privada
5. Esperar unos días (correos en tránsito con firma antigua)
6. Borrar el registro DNS del selector antiguo

DMARC — la política que une todo

Qué hace

DMARC (Domain-based Message Authentication, Reporting and Conformance) le dice a los servidores receptores qué hacer cuando un correo falla SPF o DKIM. Sin DMARC, aunque SPF o DKIM fallen, la mayoría de servidores reciben el correo de todas formas.

DMARC también introduce el concepto de alineación: no basta con que SPF o DKIM pasen — el dominio que pasa la validación tiene que ser el mismo que aparece en el From: del correo.

Sintaxis básica

v=DMARC1; p=none; rua=mailto:[email protected]

Los parámetros más importantes:

Crear el registro

El registro DMARC va en _dmarc.ejemplo.com:

Tipo: TXT
Nombre: _dmarc
Valor: v=DMARC1; p=none; rua=mailto:[email protected]
TTL: 3600

Los informes RUA

Con rua activo, recibirás un XML comprimido cada día de cada servidor que haya recibido correo de tu dominio. El XML es ilegible a mano, pero herramientas como dmarcian, Postmark DMARC o MXToolbox DMARC Analyzer lo parsean y te muestran un dashboard legible.

Lo que buscas en los informes:

• Correos que pasan SPF y DKIM → legítimos, correcto
• Correos que fallan ambos desde IPs desconocidas → spoofing o configuración incompleta
• Correos legítimos que fallan → tienes servicios de envío que no están en SPF o sin DKIM configurado

Subir de p=none a p=reject

No pases directamente a p=reject. Es el error más común y puede hacer que correos legítimos se rechacen.

El proceso correcto:

1. Publicar p=none con rua activo
2. Revisar informes durante 2-4 semanas
3. Identificar todos los servicios que envían correo de tu dominio y asegurarte de que están en SPF con DKIM configurado
4. Subir a p=quarantine; pct=10 — aplica la política al 10% del tráfico
5. Ampliar gradualmente el pct mientras revisas que no hay falsos positivos
6. Cuando pct=100 funciona bien, pasar a p=reject

Orden correcto de despliegue

Si partes de cero:

1. Configurar SPF con ~all
2. Configurar DKIM y publicar clave pública
3. Publicar DMARC con p=none + rua
4. Revisar informes (mínimo 2 semanas)
5. Corregir lo que falle (servicios no incluidos en SPF, DKIM sin configurar en algún servicio)
6. Cambiar SPF a -all
7. Subir DMARC a p=quarantine (pct bajo, ir subiendo)
8. Subir DMARC a p=reject

No te saltes el paso de los informes. Siempre hay un servicio que se te ha olvidado: el CRM que envía notificaciones, el formulario de contacto de la web, el sistema de facturación.

Herramientas de verificación

Línea de comandos:

# SPF
dig TXT ejemplo.com +short

# DKIM (sustituir "mail" por tu selector)
dig TXT mail._domainkey.ejemplo.com +short

# DMARC
dig TXT _dmarc.ejemplo.com +short

Online:

• MXToolbox SuperTool — SPF, DKIM, DMARC, DNSBL en un sitio
• mail-tester.com — envías un correo a una dirección temporal y te da puntuación con diagnóstico completo
• Google Admin Toolbox — Check MX — valida configuración de correo, útil si tienes Google Workspace
• Port25 Verifier — envía un correo a [email protected] y recibes un informe detallado directamente en tu bandeja

Checklist rápido

Antes de dar el dominio por configurado:

□ dig TXT dominio.com → muestra registro v=spf1 válido
□ El SPF tiene menos de 10 lookups DNS
□ Solo hay un registro SPF (no dos)
□ dig TXT selector._domainkey.dominio.com → muestra clave pública DKIM
□ El servidor de correo firma los correos salientes (verificar cabecera DKIM-Signature)
□ dig TXT _dmarc.dominio.com → muestra registro v=DMARC1 válido
□ La dirección rua recibe informes
□ Los informes no muestran servicios legítimos fallando
□ p=none → quarantine → reject completado gradualmente
□ Clave DKIM rotada o con fecha de rotación programada

Tres registros, un objetivo: que nadie pueda enviar correo suplantando tu dominio y que tus correos legítimos lleguen donde tienen que llegar. SPF y DKIM solos no son suficientes — DMARC es lo que les da efecto. Y los informes DMARC son la única forma de saber si algo está fallando antes de que te lo digan tus usuarios.