SPF, DKIM y DMARC: configúralos en tu servidor paso a paso

Configurar SPF, DKIM y DMARC dejó de ser algo opcional hace tiempo. Si administras un servidor de correo, o simplemente una instalación de WordPress que manda emails transaccionales, necesitas estos tres registros DNS. Sin ellos, tus correos acaban en spam. O directamente los rechaza Gmail u Outlook. Aquí, en esta primera parte, vemos qué es cada mecanismo y cómo dejar funcionando SPF y DKIM en tu servidor.

Qué son SPF, DKIM y DMARC y por qué necesitas los tres

Cada protocolo hace una cosa distinta. Y las tres piezas se complementan:

• SPF (Sender Policy Framework): publica en el DNS la lista de servidores autorizados a enviar correo en nombre de tu dominio. El servidor receptor comprueba si la IP de origen figura en esa lista.
• DKIM (DomainKeys Identified Mail): firma digitalmente cada mensaje mediante criptografía de clave pública. El receptor verifica esa firma contra la clave publicada en el DNS, con lo que se garantiza que el correo no fue alterado en tránsito.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): actúa como capa superior que combina SPF y DKIM, define qué hacer cuando algo falla (cuarentena, rechazo o entrega) y manda informes sobre quién está usando tu dominio.

¿Por qué los tres? La explicación cabe en dos líneas. SPF sin DKIM se queda cojo en los reenvíos de correo; DKIM sin DMARC no le dice al receptor qué hacer cuando la firma falla; y DMARC solo, sin los otros dos, no funciona. Es más: Gmail y Yahoo Mail exigen desde 2024 que los remitentes masivos tengan los tres configurados. No es una recomendación. Es un requisito de facto.

Cómo configurar el registro SPF en tu DNS

El SPF es un registro TXT en la zona DNS de tu dominio. Ojo con un detalle: solo puede existir uno por dominio, así que revisa lo que ya tienes antes de añadir otro. Su sintaxis básica es esta:

Cada mecanismo significa algo concreto:

• ip4:203.0.113.45: autoriza esa dirección IPv4 a enviar correo.
• include:_spf.google.com: incluye los rangos de IP de un proveedor externo.
• -all: rechaza todo lo que no coincida (hard fail, lo recomendable).
• ~all: marca como sospechoso sin rechazar (soft fail, útil mientras pruebas).

Los pasos, en orden:

1. Inventario todos los servicios que envían correo desde tu dominio: tu servidor propio, la newsletter, el CRM, el plugin SMTP de WordPress.
2. Accede al panel de gestión DNS de tu dominio o hosting.
3. Crea (o edita) el registro TXT con el nombre del dominio raíz y el valor correspondiente.
4. Empieza con ~all, monitoriza unos días y luego endurece a -all.

Un aviso que se olvida demasiado a menudo: el registro SPF tiene un límite de 10 lookups DNS (los mecanismos include o mx que generan resoluciones adicionales). Si lo superas, el registro queda invalidado y los receptores lo ignoran sin avisarte. Verifica siempre tu SPF en herramientas como MXToolbox antes de darlo por bueno.

Cómo generar e instalar DKIM en tu servidor

Aquí toca generar un par de claves criptográficas. Si trabajas con Postfix y OpenDKIM en un servidor Linux, el proceso es este:

El comando crea dos archivos: mail.private (la clave privada, que nunca sale del servidor) y mail.txt (el registro DNS que debes publicar). Después configuras OpenDKIM editando /etc/opendkim.conf para indicar el dominio, el selector (en este caso «mail») y la ruta de la clave, y conectas el filtro con Postfix mediante la directiva smtpd_milters = inet:localhost:8891.

¿Usas cPanel, Plesk o un panel tipo DirectAdmin? Entonces la generación es automática. Busca la opción «DKIM» o «Email Deliverability», activa la casilla y el panel publica el registro DNS por ti. Menos trabajo, mismo resultado.

El registro DNS de DKIM es un TXT con el nombre mail._domainkey.tudominio.com y un valor parecido a:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… (clave pública completa)

Una vez publicado, comprueba que la firma funciona enviando un correo a una dirección de test como check-auth@verifier.port25.com y revisa que el resultado sea «PASS» en DKIM. Con SPF y DKIM ya operativos, en la segunda parte del artículo nos toca montar DMARC y, sobre todo, aprender a interpretar sus informes.

Cómo crear una política DMARC efectiva

DMARC une SPF y DKIM bajo una política verificable y, sobre todo, te da visibilidad gracias a los informes. Mi consejo: avanza por fases. Nada de imponer el rechazo desde el primer día. Empieza publicando un registro de solo monitorización:

_dmarc.tudominio.com. IN TXT «v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; fo=1»

Con p=none no se rechaza nada. Pero recibirás informes agregados (rua) que te muestran qué fuentes envían correo con tu dominio y si pasan SPF o DKIM. Es la forma más segura de detectar servicios legítimos olvidados: una plataforma de newsletters, un ERP que manda notificaciones… esa clase de cosas que nadie recuerda.

Tras unas semanas analizando, escala la política poco a poco:

1. p=quarantine; pct=25: envía a spam solo el 25% del correo que falle la autenticación. Así mides el impacto sin romper la entregabilidad.
2. p=quarantine; pct=100: cuarentena para todo el correo no autenticado.
3. p=reject: la política final recomendada. Evita la suplantación de tu dominio de forma efectiva.

Incluye siempre la etiqueta rua para recibir informes agregados y, si te interesa, ruf para los forenses. Añade adkim=s y aspf=s si quieres alineamiento estricto; el modo relajado (r) es el valor por defecto y suele bastar en la mayoría de los casos (aquí prefiero no complicarse sin motivo). Herramientas gratuitas como dmarcian o Postmark DMARC Digests procesan los informes XML y los convierten en resúmenes legibles. Casi imprescindible si recibes volumen.

Errores comunes al configurar SPF, DKIM y DMARC y cómo verificarlos

Estos fallos aparecen una y otra vez en soporte. Los he visto todos más de una vez. Y casi siempre tienen el mismo diagnóstico:

• Más de un registro SPF: un dominio solo puede tener un registro TXT que empiece por v=spf1. Dos registros invalidan la autenticación. Solución: fusiona todos los includes en uno.
• Superar el límite de 10 lookups DNS: cada mecanismo include, a, mx, ptr o exists cuenta como consulta. Si te pasas, el SPF devuelve permerror. Herramientas como MXToolbox SPF Check te permiten verificar el contador.
• Falta de alineación en DMARC: que SPF y DKIM pasen no basta. El dominio del envelope-from o del d= de la firma debe coincidir con el dominio del From. Es la causa más habitual de rechazos inesperados al pasar a p=reject.
• Selector DKIM incorrecto: si firmas con s=mail pero publicas el registro en selector._domainkey con otro nombre, los receptores no encontrarán la clave pública. Error tonto, pero frecuente.
• Olvidar el correo de reenvío: los reenviadores rompen SPF. Si te afecta, apuesta por DKIM y alineamiento estricto, que sobrevive al reenvío en la mayoría de los casos.

¿Y cómo verificar todo el conjunto? Envía mensajes de prueba a check-auth@verifier.port25.com, usa el módulo de autenticación de MXToolbox o Google Admin Toolbox, y revisa en Gmail si el mensaje llega con el icono de remitente verificado. También puedes consultar las cabeceras completas: busca Authentication-Results y confirma spf=pass, dkim=pass y dmarc=pass. Cinco minutos que ahorran horas de dudas.

Conclusión: autenticación de correo lista y verificada

Configurar SPF DKIM DMARC correctamente no es un lujo técnico. Es el requisito mínimo para que tus correos lleguen a Gmail, Outlook o Yahoo en 2025, y para proteger tu dominio frente a suplantaciones. El camino es siempre el mismo: publica SPF con un único registro, firma con DKIM y verifica con pruebas externas, y despliega DMARC de forma progresiva apoyándote en los informes rua antes de saltar a p=reject. Con las herramientas de verificación indicadas podrás confirmar cada paso en minutos, sin depender de suposiciones. Y si al revisar tus informes aparecen fuentes desconocidas, firmas que no validan o rechazos que no logras diagnosticar, en RedServicio (redservicio.net) encontrarás ayuda profesional para auditar y ajustar la autenticación de tu servidor de correo.