SPF, DKIM y DMARC: guía de configuración de email

Configurar SPF, DKIM y DMARC correctamente es la base de la autenticación de correo: son los tres registros publicados en DNS que demuestran al servidor receptor que un mensaje enviado en nombre de tu dominio es legítimo y no una falsificación. Esta guía es puramente de despliegue. No entra en el análisis del ataque (para eso está la guía de qué es spoofing: tipos y técnicas), sino en los registros exactos que hay que publicar, cómo activarlos en Google Workspace y Microsoft 365, y cómo pasar de una política permisiva a una que rechace activamente el correo suplantado sin romper el correo legítimo.

Lo esencial: SPF autoriza servidores por IP, DKIM firma el mensaje criptográficamente y DMARC exige que uno de los dos esté alineado con la cabecera From visible y decide qué hacer si no lo está. El objetivo final es p=reject, pero se llega por fases (none, quarantine, reject) leyendo los reportes agregados RUA para no descartar correo válido durante la transición.

Qué autentican SPF, DKIM y DMARC (y por qué importa la alineación)

Los tres mecanismos resuelven problemas distintos y solo funcionan en conjunto.

SPF (Sender Policy Framework) publica en DNS la lista de servidores autorizados a enviar correo por tu dominio. El receptor compara la IP de origen con esa lista y valida el dominio del sobre (MAIL FROM o Return-Path), no la cabecera From que ve el usuario.

DKIM (DomainKeys Identified Mail) añade una firma criptográfica en las cabeceras. El servidor emisor firma con una clave privada y el receptor verifica con la clave pública publicada en un selector DNS. Si el mensaje llega intacto, la firma es válida.

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la capa de decisión. Comprueba que SPF o DKIM pase y que el dominio validado esté alineado con el dominio de la cabecera From visible. La alineación es la pieza clave: un atacante puede superar SPF con un dominio propio, pero no puede alinear ese dominio con tu From. DMARC publica además la política a aplicar cuando la alineación falla y una dirección donde recibir informes.

Sin DMARC, SPF y DKIM protegen poco frente a la suplantación directa del dominio, porque validan campos que el usuario nunca ve. Este matiz se detalla en la guía de tipos de phishing, donde el fraude por correo (BEC) explota precisamente esa brecha.

Registros DNS que hay que publicar

Todo se configura en la zona DNS del dominio. Estos son los registros exactos.

SPF: el registro de servidores autorizados

Un único registro TXT en la raíz del dominio. Para Google Workspace:

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

Para Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Si envías desde varias plataformas (por ejemplo correo corporativo más una herramienta de marketing), se encadenan los include: v=spf1 include:_spf.google.com include:sendgrid.net ~all. El calificador final importa: ~all es softfail (recomendado durante el despliegue) y -all es hardfail (más estricto). Nunca uses +all, que autoriza a cualquiera. Debe haber un solo registro SPF por dominio y no superar los 10 lookups DNS.

DKIM: firma criptográfica del correo

DKIM se publica en un selector, un subdominio del tipo selector._domainkey.tudominio.com. La sintaxis del registro TXT es:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...

En Google Workspace generas la clave (2048 bits recomendado) desde la consola de administración y publicas el TXT que te indica. En Microsoft 365 el modelo es distinto: se publican dos registros CNAME que delegan a la infraestructura de Microsoft y permiten rotación de clave sin tocar tu DNS:

selector1._domainkey  CNAME  selector1-tudominio-com._domainkey.tuinquilino.onmicrosoft.com
selector2._domainkey  CNAME  selector2-tudominio-com._domainkey.tuinquilino.onmicrosoft.com

DMARC: la política que une todo

Un registro TXT en _dmarc.tudominio.com. Para arrancar en modo observación:

v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; ruf=mailto:dmarc@tudominio.com; fo=1; adkim=s; aspf=s; pct=100

Etiquetas relevantes: p es la política (none, quarantine, reject), rua recibe los reportes agregados diarios, ruf los forenses por mensaje, adkim y aspf fijan el modo de alineación (s estricto, r relajado) y pct el porcentaje de correo sobre el que se aplica la política. Empieza siempre en p=none.

Configuración en Google Workspace y Microsoft 365

Los pasos de plataforma son concretos y difieren entre proveedores.

Google Workspace

1. SPF ya cubre la infraestructura de Google mediante el include:_spf.google.com; solo publica el TXT en tu DNS.
2. En Aplicaciones > Google Workspace > Gmail > Autenticar correo, genera la clave DKIM por dominio (elige 2048 bits), publica el TXT indicado y vuelve para pulsar Iniciar autenticación.
3. Publica el registro _dmarc en p=none y espera a recibir el primer reporte RUA (24 a 48 horas).

El error más común es olvidar el paso de activación de DKIM tras publicar el TXT: la clave queda publicada pero Google no firma hasta pulsar el botón. Este tipo de configuración forma parte del enfoque de defensa continua que describimos en cómo evitar el phishing.

Microsoft 365

1. Añade el include:spf.protection.outlook.com a tu SPF.
2. En el Centro de seguridad de Microsoft Defender > Directivas > DKIM, selecciona el dominio y activa la firma; el portal te muestra los dos CNAME que hay que publicar antes de habilitarla.
3. Publica el registro _dmarc en p=none. Microsoft 365 no crea el registro DMARC por ti: hay que publicarlo manualmente en tu DNS.

Despliegue por fases: de p=none a p=reject

La fase de observación es innegociable. Saltar directamente a p=reject descarta correo legítimo de proveedores SaaS (facturación, firma electrónica, CRM, boletines) que envían en tu nombre y que aún no has alineado.

1. p=none: publica la política y deja que corra dos o tres semanas. Los reportes RUA que llegan a la dirección rua listan cada fuente que envía como tu dominio, con su volumen y su resultado SPF/DKIM. Un visor de reportes (Dmarcian, Postmark, URIports o similar) los convierte en tabla legible.
2. Corrige los flujos desalineados: por cada fuente legítima que aparezca sin pasar, añádela a SPF o habilita su DKIM. Si un proveedor no admite DKIM sobre tu dominio, delega un subdominio dedicado (mkt.tudominio.com) para aislar ese flujo.
3. p=quarantine; pct=25 y ve subiendo el porcentaje. La cuarentena envía a spam el correo no alineado, un fallo reversible que aún no destruye mensajes.
4. p=reject: cuando los reportes muestran que el 100% del correo legítimo está alineado, sube a rechazo. Este es el dmarc policy of reject, el único estado que impide activamente que se entregue correo suplantando tu dominio.

Troubleshooting: "dmarc policy not enabled" y flujos desalineados

Los verificadores externos devuelven avisos con causas concretas.

"dmarc policy not enabled": significa que el analizador no encuentra una política DMARC aplicable. Las causas habituales son que no existe registro TXT en _dmarc.tudominio.com, que la etiqueta p falta o está en p=none (que muchos scoring interpretan como no aplicada), o que el registro tiene un error de sintaxis y no parsea. Verifica con dig TXT _dmarc.tudominio.com +short que devuelve exactamente un registro que empieza por v=DMARC1 y que p tiene un valor. Para superar el aviso de forma real hay que llegar a quarantine o reject.

SPF pasa pero DMARC falla: es desalineación. El sobre (MAIL FROM) usa un dominio del proveedor que pasa SPF, pero no coincide con tu From. La solución es firmar con DKIM alineado, que sobrevive a los reenvíos, o pasar aspf a relajado si el subdominio de sobre está bajo tu control.

El reenvío rompe SPF: listas de correo y reglas de forwarding cambian la IP de origen. DKIM no se ve afectado si el cuerpo no se altera, por lo que un DKIM sólido sostiene DMARC cuando SPF cae. No conviertas a -all de forma prematura por este motivo.

"Too many DNS lookups": SPF supera los 10 lookups permitidos. Consolida include, elimina proveedores que ya no uses o aplana el registro con una herramienta de flattening.

Avanzado: BIMI y VMC cuando ya estás en p=reject

Con DMARC en quarantine o reject al 100% puedes activar BIMI (Brand Indicators for Message Identification), que muestra el logotipo de tu marca junto al remitente en clientes compatibles como Gmail y Apple Mail. El registro:

default._bimi.tudominio.com  TXT  "v=BIMI1; l=https://tudominio.com/logo.svg; a=https://tudominio.com/vmc.pem"

El logotipo debe estar en formato SVG Tiny Portable/Secure. La etiqueta a apunta a un VMC (Verified Mark Certificate), un certificado emitido por autoridades como DigiCert o Entrust que vincula el logotipo a una marca registrada. Gmail exige el VMC para pintar el logo. BIMI no aporta seguridad criptográfica adicional, pero refuerza el reconocimiento visual y es un incentivo tangible para completar el despliegue hasta p=reject.

Preguntas frecuentes

¿Cómo configuro DMARC desde cero?

Publica primero SPF y DKIM y verifica que ambos pasan. Después crea un registro TXT en _dmarc.tudominio.com con v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com. Deja p=none durante dos o tres semanas leyendo los reportes RUA, corrige los flujos desalineados y solo entonces sube a quarantine y a reject.

¿Qué significa "dmarc policy not enabled"?

Que el verificador no encuentra una política DMARC efectiva. O falta el registro en _dmarc, o tiene un error de sintaxis, o la etiqueta p está ausente o en none. Comprueba con dig TXT _dmarc.tudominio.com +short y asegúrate de que hay un único registro que empieza por v=DMARC1 con un valor válido en p. El aviso desaparece al aplicar quarantine o reject.

¿Cuál es el registro SPF de Google Workspace?

v=spf1 include:_spf.google.com ~all como registro TXT único en la raíz del dominio. Si envías desde otras plataformas, añade sus include en el mismo registro antes del ~all, sin superar 10 lookups DNS ni crear un segundo registro SPF.

¿Es peligroso poner DMARC en p=reject?

Solo si se hace sin fase previa. Aplicado tras semanas de observación en p=none y corrección de todos los flujos legítimos, p=reject es seguro y es el estado recomendado. El riesgo aparece cuando se salta la observación y se descarta correo de proveedores que envían en tu nombre sin estar alineados.

¿Necesito BIMI para estar protegido?

No. BIMI es una capa visual que requiere DMARC ya en enforcement y un certificado VMC de pago. La protección real la dan SPF, DKIM y DMARC en reject. BIMI aporta reconocimiento de marca, no seguridad técnica adicional.

Recursos relacionados

• Qué es spoofing: tipos y técnicas
• Cómo evitar el phishing
• Tipos de phishing
• Qué es ingeniería social

Configura tu autenticación de correo con Secra

Secra audita la configuración SPF, DKIM y DMARC de tu organización, identifica los flujos SaaS que envían en tu nombre sin estar alineados y acompaña la transición de p=none a p=reject sin interrumpir el correo legítimo, con seguimiento continuo de los reportes agregados. Este trabajo forma parte de nuestro servicio de ciberseguridad gestionada y aporta evidencia documental directa si tu organización está dentro del ámbito de NIS2 o necesita justificar medidas del artículo 32 del RGPD. Escríbenos a través de contacto para una evaluación inicial del estado de tu correo.