SPF, DKIM y DMARC: cómo frenar la suplantación de correo paso a paso

En resumen: SPF enumera los servidores autorizados a enviar correo en nombre de tu dominio, DKIM firma cada mensaje y DMARC comprueba que uno de los dos pase para el dominio de la dirección From visible, y después indica a los receptores qué hacer con el correo que falla. Desde febrero de 2024, Gmail y Yahoo exigen SPF o DKIM a todos los remitentes, y SPF, DKIM y DMARC a los remitentes masivos, y Gmail endurece su aplicación desde noviembre de 2025. Publica un solo registro SPF, activa DKIM en cada servicio que envíe por ti, empieza DMARC con p=none y reportes, y pasa a p=quarantine o p=reject cuando tu correo legítimo pase las comprobaciones.

El correo electrónico se diseñó sin ninguna prueba de quién envía un mensaje. Cualquiera puede escribir billing@yourcompany.com en la línea From y, sin registros de autenticación, el servidor receptor no tiene forma de saber que es falso. Así funcionan el fraude de facturas y el phishing en tu nombre, y por eso tu correo real también puede parecer sospechoso a Gmail.

SPF, DKIM y DMARC lo resuelven con tres registros DNS. Esta guía explica cómo encajan, qué exigen los grandes proveedores de correo, cómo lee tu dominio nuestro verificador gratuito de SPF y DMARC y cómo pasar de no tener registros a una política aplicada sin romper tu propio correo.

Cómo funcionan juntos SPF, DKIM y DMARC

El punto débil de SPF y DKIM por separado está en la fila "qué dominio comprueba". La RFC 7208 establece que SPF verifica las identidades MAIL FROM y HELO, que el destinatario nunca ve. Un suplantador puede pasar SPF con su propio dominio mientras muestra el tuyo en From. DMARC cierra esa brecha con la alineación: un mensaje pasa DMARC solo si SPF o DKIM pasan para un dominio que coincide con el dominio From (la alineación relajada admite subdominios de la misma organización).

SPF en un registro

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Cada include autoriza los servidores de un proveedor; -all al final indica que todo lo demás falla. La RFC 7208 define los calificadores: - es fail, ~ es softfail ("probablemente no autorizado"), ? es neutral y + es pass. +all autoriza a todo internet y anula el propósito del registro.

DKIM en un registro

Tu proveedor de correo firma los mensajes salientes con una clave privada y te entrega una clave pública para publicarla bajo un selector, por ejemplo google._domainkey.example.com. Cada servicio de envío usa su propio selector, así que puedes tener varias claves DKIM a la vez (RFC 6376).

DMARC en un registro

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p es la política del dominio, sp la de los subdominios, y rua recibe reportes agregados diarios de los receptores con los servidores que enviaron correo como tu dominio y si pasaron o no.

El estándar DMARC se actualizó en 2026

En mayo de 2026 el IETF publicó la RFC 9989, que deja obsoleta la especificación original de DMARC, la RFC 7489, y lleva DMARC al Standards Track. Los registros existentes siguen funcionando; la etiqueta de versión sigue siendo v=DMARC1. Los cambios que conviene conocer:

• Se elimina pct. La RFC dice que "was usually not accurately applied" (normalmente no se aplicaba con precisión). Una nueva etiqueta t ("testing") lo sustituye: t=y pide a los receptores que no apliquen la política, más o menos como el antiguo pct=0.
• Se añade np, una política para subdominios inexistentes.
• Se eliminan rf y ri, y un "tree walk" de DNS sustituye a la Public Suffix List para encontrar el dominio organizacional.

Los receptores adoptarán las nuevas reglas a distinto ritmo, y la propia guía de configuración de Google sigue recomendando pct durante el despliegue. Usar pct no rompe nada, pero no cuentes con él como un porcentaje exacto.

Qué exigen Gmail y Yahoo

Ambos proveedores empezaron a aplicar sus requisitos para remitentes en febrero de 2024.

Fuentes: directrices para remitentes de Google y buenas prácticas para remitentes de Yahoo. Google advierte que los mensajes sin autenticar "might be marked as spam or rejected with a 5.7.26 error" (podrían marcarse como spam o rechazarse con un error 5.7.26), y su FAQ dice: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic" (desde noviembre de 2025, Gmail intensifica la aplicación contra el tráfico que no cumple), con rechazos temporales y permanentes. La misma FAQ recomienda alinear DMARC tanto con SPF como con DKIM y señala que la alineación probablemente se volverá un requisito más adelante.

Aunque envíes muchos menos de 5.000 mensajes al día, estos registros deciden si tus facturas, restablecimientos de contraseña y respuestas llegan a la bandeja de entrada, y si otra persona puede enviar correos convincentes en tu nombre.

Cómo funciona el verificador de SPF y DMARC de Searvia

El verificador gratuito de SPF y DMARC forma parte de nuestro verificador SEO de sitios web y muestra primero la comprobación de autenticación de correo. Introduce un dominio (se elimina un www. inicial) y la herramienta:

1. Consulta los registros TXT del dominio y toma los que empiezan por v=spf1. Si hay más de uno, lo marca, porque entonces SPF falla.
2. Cuenta las consultas DNS que necesita el registro SPF (include, a, mx, ptr, exists y redirect, siguiendo cada include un nivel de profundidad) y avisa si son más de 10.
3. Consulta los registros TXT de _dmarc. más el dominio y toma el que empieza por v=DMARC1.
4. Lee la política p= del registro DMARC y comprueba si hay una dirección de reportes rua.
5. Muestra ambos registros completos, con una marca de verificación o una cruz, y una fila de DKIM marcada como "Not checked".

En la auditoría general, esta comprobación tiene prioridad media. Fíjate en lo estricta que es con DMARC: p=none cumple el mínimo de Gmail, pero aun así muestra una advertencia, porque no detiene la suplantación.

Lo que la comprobación gratuita no cubre:

• DKIM. Las claves DKIM están bajo selectores elegidos por cada servicio de correo y no hay forma de listarlas desde DNS, así que el informe marca DKIM como no comprobado. Revisa DKIM en el panel de administración de tu proveedor de correo o en los encabezados de un mensaje que hayas enviado (busca dkim=pass).
• Todas las reglas de SPF. Detecta registros duplicados y más de 10 consultas, pero no si el registro termina en -all o ~all. Los includes se siguen un nivel de profundidad, así que un registro con anidación profunda puede necesitar más consultas de las que indica el recuento.
• Los detalles de DMARC. Lee p= y comprueba rua, pero no sp= ni los ajustes de alineación.

Cómo interpretar tu resultado

• Error: tu dominio está expuesto a la suplantación y tu correo incumple requisitos de Gmail y Yahoo. Empieza por el paso 1 de abajo.
• "DMARC is missing" o "SPF is missing": vas a medias. Añade el registro que falta.
• "DMARC is set to none": el resultado más habitual. Estás recopilando reportes (si hay rua), que es la primera etapa correcta. Planifica el paso a la aplicación de la política.
• Correcto: bien. Revisa lo que la herramienta gratuita no ve: DKIM de cada remitente, includes de SPF con anidación profunda y la política sp para subdominios.

Cómo solucionarlo, paso a paso

Paso 1: Haz una lista de todo lo que envía correo como tu dominio

Tu proveedor de correo (Google Workspace, Microsoft 365), la herramienta de newsletters, el CRM, el help desk, el software de facturación, la plataforma de comercio electrónico, el formulario de contacto de tu web y cualquier servidor que envíe notificaciones. Olvidar uno aquí es la principal razón por la que la aplicación de DMARC sale mal más adelante.

Paso 2: Publica un único registro SPF

1. Reúne el valor include: que documenta cada proveedor.
2. Combínalos en un solo registro. La RFC 7208 es explícita: si existe más de un registro SPF, el resultado es "permerror".
3. Termina con ~all mientras pruebas y luego con -all.
4. Cuenta las consultas. include, a, mx, ptr, exists y redirect cuestan cada uno una consulta DNS, y el límite es 10, incluidas las consultas dentro de includes anidados. Superar 10 es un permerror. Elimina los servicios que ya no uses y descarta ptr, que según la RFC "SHOULD NOT be published" (no debería publicarse).

Si un proveedor envía con su propio dominio de sobre (habitual en herramientas de newsletters), no necesita estar en tu SPF; necesita DKIM con tu dominio para que DMARC pase.

Paso 3: Activa DKIM en cada remitente

En cada servicio, busca la configuración de autenticación de dominio o DKIM, publica el registro que te dé (un TXT o CNAME bajo un selector) y activa la firma. Google recomienda esperar 48 horas tras configurar SPF y DKIM antes de añadir DMARC. Después envía un mensaje de prueba a una dirección de Gmail y revisa "Mostrar original": debes ver SPF: PASS, DKIM: PASS y DMARC: PASS.

Paso 4: Publica DMARC con p=none y reportes

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Google recomienda empezar con p=none e incluir siempre rua. Los reportes agregados son archivos XML; un servicio de reportes DMARC o un analizador los hace legibles. Si la dirección de reportes está en otro dominio, ese dominio debe autorizarla con un registro DNS.

Paso 5: Lee los reportes y corrige los fallos

Durante dos a cuatro semanas, busca servicios legítimos que fallen la alineación de SPF o DKIM. Cada uno necesita firma DKIM con tu dominio o un include de SPF. El correo reenviado y las listas de distribución pueden fallar por motivos legítimos; la RFC 9989 sugiere que los dominios cuyos usuarios escriben en listas de distribución pasen al menos un mes en p=none y un periodo similar en p=quarantine antes de p=reject.

Paso 6: Pasa a quarantine y después a reject

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Cambia un nivel cada vez y sigue revisando los reportes. Al llegar a p=quarantine, nuestro verificador da el resultado correcto. p=reject es la meta: los receptores rechazan el correo que falla.

Paso 7: Blinda los dominios que no envían correo

Los dominios aparcados y los que solo redirigen son atractivos para los suplantadores porque nadie los vigila. La guía del gobierno del Reino Unido recomienda:

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Comprueba tú mismo los registros

El verificador lee SPF y DMARC; puedes ver los tres registros con herramientas DNS estándar. En macOS o Linux:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

En Windows, nslookup -type=TXT _dmarc.example.com hace lo mismo. Para DKIM necesitas el selector, que tu proveedor muestra en su configuración de DKIM y que aparece como s= en el encabezado DKIM-Signature de cualquier mensaje que hayas enviado; google es el valor predeterminado en Google Workspace. Algunos proveedores publican la clave como un CNAME que apunta a su propio DNS, y eso es válido.

La prueba de extremo a extremo más fiable es un mensaje real. Envía uno desde cada servicio a una dirección de Gmail y abre "Mostrar original": muestra el resultado de SPF, DKIM y DMARC y el dominio para el que pasó cada uno. Un DKIM aprobado para el dominio del proveedor en lugar del tuyo significa que la alineación DMARC sigue fallando, así que busca tu propio dominio en el resultado.

Errores comunes

Ejemplo práctico (hipotético)

Lo siguiente es un ejemplo hipotético, no datos reales. Pinecrest Dental, una clínica inventada, se entera por sus pacientes de que recibieron una solicitud de pago falsa "de parte" de la clínica. El verificador de SPF y DMARC muestra:

• SPF: v=spf1 include:_spf.google.com ~all
• DMARC: ausente. Resultado: advertencia, "DMARC is missing."

El paso 1 encuentra tres remitentes: Google Workspace, el sistema de reservas que envía recordatorios y una herramienta de newsletters. El sistema de reservas necesita un include de SPF; la herramienta de newsletters usa su propio dominio de sobre, así que recibe DKIM con el dominio de la clínica. La clínica publica DMARC con p=none y una dirección de reportes. Dos semanas de reportes muestran que el sistema de reservas pasa SPF y la newsletter pasa DKIM, además de unos cientos de mensajes de servidores desconocidos en otros países que fallan ambos: la suplantación. La clínica pasa a p=quarantine, donde el verificador da el resultado correcto, y un mes después a p=reject. Los mensajes falsos en su nombre ahora son rechazados por los receptores que aplican DMARC.

Una lista de verificación que puedes terminar esta semana

1. Pasa el verificador de SPF y DMARC por cada dominio que tengas, incluidos los aparcados.
2. Haz una lista de todos los servicios que envían correo como tu dominio.
3. Combina SPF en un solo registro, con menos de 10 consultas y que termine en ~all o -all.
4. Activa DKIM en cada servicio y pruébalo con "Mostrar original" en Gmail.
5. Publica DMARC con p=none y rua, y lee los reportes.
6. Pasa a p=quarantine y después a p=reject.
7. Publica v=spf1 -all y p=reject en los dominios que no envían nada.

Cómo vigila Searvia tu autenticación de correo

El verificador gratuito de SPF y DMARC lee tus registros en segundos, sin registro previo, como parte de una auditoría de 38 comprobaciones que también cubre la apariencia de tu sitio en las búsquedas, su velocidad y su seguridad.

Una cuenta gratuita de Searvia añade un análisis de seguridad semanal que va más allá en el correo: detecta un registro SPF ausente o demasiado abierto (+all, ?all o sin all), una política DMARC ausente o todavía en p=none, y la falta de un registro CAA, con la consulta DNS detrás de cada hallazgo y un registro que puedes copiar. El análisis se repite cada jueves, así que un cambio de DNS que rompa tus registros aparece en una semana. Para la parte de seguridad del sitio web, consulta nuestra guía de encabezados de seguridad.