SPF, DKIM y DMARC: cómo configurar la autenticación del correo en el DNS de tu dominio

1. Da a cada servicio que envía correo un lugar en el mapa

Los registros MX indican a los servidores remitentes dónde entregar el correo dirigido a tu dominio. El correo saliente sigue otro camino: una empresa puede recibir el correo en su proveedor de buzones y, a la vez, enviar las confirmaciones de pedido desde la plataforma de la tienda, las respuestas de soporte desde una herramienta de atención al cliente y los boletines desde un servicio de marketing.

Crea un inventario de remitentes con una fila por servicio: la dirección From visible, el dominio del remitente del sobre (el MAIL FROM, que en el mensaje entregado suele aparecer en la cabecera Return-Path), el dominio con el que firma DKIM, la persona responsable y un mensaje de ejemplo. Es normal que esos dominios no coincidan; tenerlos juntos es lo que permite interpretar después los resultados de autenticación. Anota también el nombre exacto que usa el correo: www.example.com sirve la web, pero el correo suele salir de example.com o de un subdominio como news.example.com, y cada nombre tiene sus propios registros. Incluye además los dominios que tienes registrados y no usan el correo: un registro MX nulo (RFC 7505) anuncia que no aceptan mensajes. El inventario resulta especialmente útil cuando el equipo incorpora un servicio nuevo o cuando la responsabilidad pasa a otra persona.

2. Entiende qué aporta cada mecanismo

Cada mecanismo aporta una pieza distinta. SPF y DKIM autentican dominios; DMARC comprueba si alguno de ellos coincide con el dominio del campo From, que es el que ve el destinatario. El cifrado del transporte entre servidores es otro asunto: lo aporta TLS, y MTA-STS sirve para exigirlo. Tener claros estos papeles facilita mucho leer las cabeceras técnicas de un mensaje entregado.

3. Mantén SPF al día con las rutas de envío reales

SPF compara el servidor que se conecta con la política publicada para el dominio del sobre, no para el From visible; de relacionar ambos se encarga DMARC. La política es un registro TXT que empieza por v=spf1 y suele incluir, con include:, la configuración publicada por cada proveedor, que a su vez puede remitir a otros registros. La especificación de SPF (RFC 7208) fija límites que conviene revisar:

• Solo puede haber un registro SPF por nombre; dos registros v=spf1 producen un error permanente (permerror).
• Se admiten como máximo diez términos que generan consultas DNS (include, a, mx, ptr, exists y redirect), contando los que hay dentro de cada include; ip4, ip6 y all no cuentan. Superar ese límite también da permerror.
• Las consultas que no devuelven datos (void lookups) deberían ser como mucho dos: la especificación recomienda que los evaluadores no admitan más y devuelvan permerror por encima de ese límite.
• El mecanismo ptr está desaconsejado, y +all autoriza a cualquier servidor de internet.

Con ~all (softfail) el receptor no debería rechazar un mensaje solo por ese resultado; con -all (fail) la decisión depende de su propia política. Pasar a -all no siempre es mejor: la especificación actual de DMARC advierte que un fallo de SPF con -all puede hacer que el mensaje se rechace al principio de la transacción SMTP, antes de evaluar DMARC, aunque una firma DKIM alineada lo habría hecho pasar, y esos rechazos nunca aparecen en los informes agregados de DMARC. Cuando añadas o retires un servicio, actualiza a la vez el inventario y el DNS, y revisa cuántas consultas añade cada include.

Para consultar con dig o nslookup los registros SPF y DMARC que publica hoy tu dominio y leerlos término a término, sigue la guía para comprobar SPF y DMARC.

4. Conecta firmas, alineación e informes

DKIM firma partes del mensaje con una clave privada, y el receptor verifica la firma con la clave pública publicada en <selector>._domainkey.<dominio> (RFC 6376). El INCIBE, el Instituto Nacional de Ciberseguridad de España, lo resume como un protocolo que asocia un nombre de dominio a un mensaje mediante técnicas criptográficas. Sin conocer el selector no se pueden listar esas claves desde fuera, así que la comprobación fiable es otra: activa la firma en cada proveedor, publica en el DNS los registros DKIM que te indique, envía un mensaje real y revisa la cabecera Authentication-Results que añade el receptor.

DMARC tiene una especificación nueva. El RFC 9989, publicado en mayo de 2026 como estándar del IETF, sustituye al RFC 7489, que era solo informativo. El registro sigue en _dmarc.<dominio> y empieza por v=DMARC1, pero hay cambios: desaparecen las etiquetas pct, rf y ri; con la nueva etiqueta t=y, el dominio indica que está en pruebas y pide aplicar un nivel por debajo de la política publicada (reject se trata como quarantine); se añaden np, para los subdominios que no existen, y psd, y el dominio organizativo ya no se busca en la lista de sufijos públicos, sino recorriendo el árbol DNS.

Un mensaje supera DMARC cuando SPF o DKIM pasan con un dominio alineado con el From; por defecto la alineación es relajada y basta con compartir el dominio organizativo. Una política p=none permite observar sin pedir ninguna acción, y los informes agregados que llegan a las direcciones indicadas en rua muestran qué fuentes envían en nombre del dominio y con qué resultado. Para avanzar, el RFC 9989 propone al menos un mes en p=none y un periodo igual en quarantine antes de valorar reject. También desaconseja p=reject en dominios cuyos usuarios escriben en listas de correo, y exige a quien lo publique que firme con DKIM y no dependa solo de SPF. La guía técnica TR-03182 de la Oficina Federal de Seguridad de la Información de Alemania (BSI), en cambio, recomienda reject para los dominios que envían correo. No hay un valor correcto para todos: decide con los informes delante.

Los grandes proveedores de buzones ya piden estos registros. Según las directrices de Google, desde febrero de 2024 quien envía unos 5000 mensajes al día o más a cuentas personales de Gmail necesita SPF, DKIM, un registro DMARC (basta con p=none) y que el dominio From esté alineado con SPF o con DKIM. Microsoft exige desde mayo de 2025 algo parecido a los dominios que envían más de 5000 mensajes al día a cuentas de Outlook.com, y Yahoo pide requisitos similares a los remitentes masivos, aunque no publica un umbral de volumen.

5. Coordina certificados y transporte del correo

Los registros CAA (RFC 8659) indican qué autoridades certificadoras pueden emitir certificados TLS para un dominio. Las autoridades públicas los consultan antes de emitir y, como explica Let's Encrypt, usan el registro más cercano al nombre solicitado: un CAA en example.com cubre sus subdominios salvo que alguno publique el suyo. No publicar ningún registro CAA también es válido. Si lo publicas, incluye a todos los emisores que usan tu web, tu CDN y tus otros servicios, o una renovación automática puede fallar. Ten presente su límite: CAA no impide que una autoridad autorizada emita por error.

MTA-STS (RFC 8461) permite que un dominio pida a los servidores remitentes que le entreguen correo solo por TLS con un certificado de confianza. Necesita dos piezas que se revisan juntas: un registro TXT en _mta-sts.<dominio> y un archivo de política servido en https://mta-sts.<dominio>/.well-known/mta-sts.txt, con el modo (enforce, testing o none) y los servidores MX permitidos. Si además quieres recibir informes sobre los fallos de TLS (TLS-RPT, RFC 8460), la dirección de destino se publica aparte, en un registro TXT en _smtp._tls.<dominio>. Documentar en el mismo lugar los emisores de certificados y el transporte del correo reduce el riesgo de que una renovación o un cambio de proveedor rompa algo que nadie recordaba.

6. Revisa la configuración final con mensajes reales

Antes de cambiar el DNS, guarda los registros actuales, identifica el proveedor DNS autoritativo y anota el TTL. Después de publicar, consulta la respuesta autoritativa y la de un resolutor externo; hasta que caduque el TTL anterior, algunos resolutores pueden seguir devolviendo el valor antiguo.

1. Envía un mensaje representativo desde cada servicio del inventario.
2. Comprueba que llega y revisa su cabecera Authentication-Results.
3. Anota el resultado de SPF y de DKIM, el dominio de cada uno y si DMARC los consideró alineados.
4. Compara lo observado con los informes agregados y actualiza los responsables en el inventario.

Incluye los mensajes que tu negocio envía de verdad: facturas, respuestas de soporte, avisos de cuenta y boletines. Enviar a buzones de varios proveedores, por ejemplo una cuenta de Gmail y otra de Outlook.com, permite comparar resultados, porque cada receptor aplica sus propios criterios. Guarda un ejemplo fechado por cada ruta de envío para que la próxima persona vea la configuración prevista en funcionamiento.

Para consultar ahora los registros SPF, DMARC, MTA-STS y CAA de un dominio, usa el verificador de SPF y DMARC gratuito.

7. Reúne la identidad del dominio en un solo registro

Junta en un mismo documento el inventario de remitentes, los registros DNS, los emisores de certificados y los mensajes de ejemplo. Para una primera lectura desde fuera, el snapshot gratuito de Sitelemetry ejecuta ocho comprobaciones pasivas sobre un origen público, sin crear una cuenta; una de ellas lee los registros SPF, DMARC, CAA y MTA-STS. No es un pentest. Conviene conocer su alcance: consulta el nombre exacto que escribes (con www.example.com mira www, no el dominio principal), solo marca la falta de SPF, DMARC o MTA-STS si ese nombre tiene registros MX, revisa MTA-STS únicamente por su registro TXT, sin descargar el archivo de política, y no comprueba DKIM. Los mensajes reales del paso anterior siguen siendo necesarios.

Continúa con la guía de certificados TLS y cabeceras de seguridad para las conexiones del sitio web, o con la guía de integraciones para los servicios conectados al negocio.