SPF, DKIM y DMARC explicados: La guía completa de autenticación de correo electrónico [2026]

El correo electrónico tiene un problema de confianza. No hay una forma integrada de demostrar que un mensaje provino realmente del dominio que dice ser, por lo que alguien puede enviar un correo electrónico que parezca ser de su jefe, su banco o su empresa con poco más que unos minutos de configuración.

SPF, DKIM y DMARC son los tres registros DNS que solucionan esto. Juntos, indican a los servidores de correo receptores qué servidores tienen permiso para enviar en nombre de su dominio, si cada mensaje ha sido manipulado durante el tránsito y qué hacer cuando una de esas comprobaciones falla.

Esta guía explica qué hace cada uno, cómo funcionan juntos, el orden para configurarlos y cómo probarlos. A partir de 2026, los tres son obligatorios para cualquier empresa que envíe correos electrónicos. Gmail, Yahoo y Microsoft lo imponen directamente, y omitir cualquiera de ellos afecta la entrega en la bandeja de entrada.

Respuestas rápidas

• ¿Qué son SPF, DKIM y DMARC? Tres registros DNS que trabajan juntos para verificar que tus correos electrónicos son realmente tuyos. SPF autoriza qué servidores pueden enviar en nombre de tu dominio, DKIM añade una firma criptográfica que demuestra que el mensaje no ha sido alterado y DMARC indica a los receptores qué hacer cuando SPF o DKIM fallan.
• ¿Necesitas los tres? Sí. Cada uno soluciona lo que los otros no cubren, y desde febrero de 2024, Gmail y Yahoo los requieren para remitentes de más de 5000 correos electrónicos por día.
• ¿En qué orden se configuran? Primero SPF, luego DKIM y finalmente DMARC, con verificación entre cada paso.
• Compruébalos ahora: Usa el verificador gratuito de esta página para probar los tres registros en tu dominio.

SPF, DKIM y DMARC: Autenticación de correo electrónico explicada

Los tres registros son comprobaciones independientes que se combinan en una política. Una vez implementados, dejas de tener que adivinar por qué nunca llegó un restablecimiento de contraseña o por qué un correo electrónico transaccional fue a la carpeta de spam.

¿Qué son SPF, DKIM y DMARC?

SPF, DKIM y DMARC son tres registros DNS que autentican el correo electrónico que proviene de tu dominio.

• SPF (Sender Policy Framework) enumera todos los servidores que tienen permiso para enviar correo en nombre de tu dominio.
• DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje para que los receptores puedan confirmar que el contenido no se ha modificado durante el tránsito.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) indica a los receptores qué hacer cuando SPF o DKIM fallan, y vincula ambas comprobaciones a la dirección visible From:.

Cada uno soluciona una brecha diferente. SPF impide que servidores no autorizados suplanten tu dominio, DKIM impide que alguien modifique tus mensajes en tránsito y DMARC impide que los atacantes superen SPF o DKIM con un dominio diferente mientras suplantan el tuyo en la línea From: visible.

Comparación rápida

	SPF	DKIM	DMARC
Qué hace	Enumera los servidores autorizados para enviar correo en nombre de su dominio	Firma cada correo electrónico para que los receptores puedan confirmar que no se modificó	Indica a los receptores qué hacer cuando SPF o DKIM fallan
Cómo funciona	El receptor compara la IP de envío con una lista en su DNS	El receptor verifica una firma criptográfica contra su clave pública	El receptor aplica su política (entregar, spam o rechazar) al correo fallido
Lo que no hace	No comprueba la dirección From: visible, falla con el reenvío	No indica qué servidores pueden enviar, puede fallar si los retransmisores modifican el correo	No autentica nada por sí solo, depende de SPF y DKIM
Dónde reside en el DNS	Registro TXT en su dominio raíz	Registro TXT en [selector]._domainkey.sudominio.com	Registro TXT en _dmarc.sudominio.com
¿Obligatorio en 2026?	Sí	Sí	Sí

Cuando un correo electrónico llega a Gmail, Outlook o cualquier otra bandeja de entrada, se realizan tres comprobaciones una tras otra. El receptor busca tu registro SPF y compara la IP de envío con la lista. El receptor comprueba la firma DKIM con la clave pública de tu DNS. Luego, el receptor lee tu política DMARC y decide qué hacer con el resultado.

¿Qué es SPF?

SPF es un registro TXT en tu DNS que enumera cada servidor y servicio autorizado para enviar correos electrónicos en nombre de tu dominio. Es la primera línea de defensa contra la suplantación de identidad del dominio.

Un registro SPF básico se ve así:

v=spf1 include:sendlayer.net ~all

Las partes:

• v=spf1 declara que este es un registro SPF.
• include:sendlayer.net autoriza un servicio de envío, aquí SendLayer. Cada herramienta de envío tiene su propia directiva include:.
• ~all es la regla general para todo lo que no coincide. La tilde significa "fallo suave", que permite el correo pero lo marca. Usa -all para "fallo duro" (rechazar) una vez que estés seguro de que tu registro cubre a todos los remitentes legítimos.

Cuando llega un correo electrónico, el servidor receptor toma la IP de origen y comprueba si esa IP está permitida por tu registro SPF. Si es así, SPF pasa. Si no, SPF falla.

Lo que SPF no puede hacer

SPF tiene dos limitaciones conocidas. Falla con el reenvío de correos electrónicos. Cuando alguien reenvía tu correo, el servidor de reenvío utiliza su propia IP, que no está en tu registro SPF, por lo que SPF falla aunque el original fuera legítimo. También solo comprueba la ruta de retorno, no la dirección visible From:. Un atacante puede pasar SPF con un dominio que controla mientras hace que la línea From: parezca la tuya. Por eso la alineación DMARC es importante (más sobre esto a continuación).

El límite de 10 búsquedas DNS

Los registros SPF están limitados a 10 búsquedas DNS en total (RFC 7208). Cada directiva include:, a, mx, ptr y exists: cuenta para el límite. Si añades demasiados servicios de envío, alcanzarás un PERMERROR, momento en el cual todas las autenticaciones fallan silenciosamente.

La mayoría de los dominios alcanzan este límite al agrupar varias herramientas de marketing, CRM, servicios transaccionales y sistemas de asistencia. Si estás cerca del límite, sigue nuestra guía sobre cómo fusionar varios registros SPF en un único registro simplificado.

Y ten en cuenta que solo puedes tener un registro SPF por dominio. Si intentas añadir un segundo, RFC 7208 dice que los receptores deben tratar toda la configuración como inválida, el mismo efecto que no tener ningún SPF.

¿Qué es DKIM?

DKIM añade una firma criptográfica a cada correo electrónico que envías. La firma se genera utilizando una clave privada que tiene tu servicio de envío, y tu DNS tiene la clave pública correspondiente. Los servidores receptores comparan ambas para confirmar que el correo electrónico provino realmente de tu dominio y que nada en él fue modificado durante el tránsito.

Un registro DKIM en DNS se ve así:

selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

El selector (“selector1” en este ejemplo) indica a los servidores receptores qué clave DKIM buscar. La mayoría de los proveedores rotan las claves periódicamente y utilizan selectores diferentes para distintas transmisiones de envío, por lo que el nombre del selector es parte de la ubicación del registro.

Cada correo electrónico que envías lleva una cabecera DKIM-Signature que se parece a esto:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

La etiqueta d= es el dominio que reclama la firma. La etiqueta s= es el selector. Ese es el registro DNS que los receptores buscarán.

Lo que DKIM no puede hacer

DKIM es potente pero tiene límites. No indica qué servidores tienen permiso para enviar para tu dominio. Ese es el trabajo de SPF. Un atacante puede suplantar tu dominio sin firmar con DKIM, y DKIM por sí solo no tiene opinión al respecto. También puede fallar si un servidor de retransmisión modifica el cuerpo del mensaje, por ejemplo, una lista de correo que añade un pie de página al correo saliente. Y DKIM no tiene ninguna aplicación incorporada. Un servidor receptor puede ignorar una firma fallida a menos que DMARC le indique lo contrario.

Longitud de la clave DKIM

Las claves DKIM modernas son de 2048 bits, lo que produce una cadena de clave pública más larga que 255 caracteres, la longitud máxima de un valor de registro TXT único. La mayoría de los proveedores de DNS manejan esto automáticamente dividiendo el valor en varias cadenas entrecomilladas, pero algunos no lo hacen. Si tu registro DKIM no se guarda o no se valida, consulta nuestra guía sobre cómo dividir un registro DKIM.

¿Qué es DMARC?

DMARC une SPF y DKIM y dice a los servidores receptores qué hacer cuando falla la autenticación. Es el único de los tres que genera informes para ti.

Un registro DMARC típico se ve así:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

Cada etiqueta tiene una función:

• v=DMARC1 declara que este es un registro DMARC.
• p= es la política, una de none, quarantine o reject.
• rua= es a dónde se envían los informes agregados.
• pct= es el porcentaje de correo al que se aplica la política (útil para implementaciones graduales).
• aspf= y adkim= controlan el modo de alineación, relajado (r) o estricto (s).

Progresión de políticas, de none a quarantine a reject

La aplicación de DMARC es un viaje, no un interruptor. Las tres políticas son etapas, y usted progresa a través de ellas a medida que aumenta su confianza.

• p=none es el modo de monitorización. Los correos electrónicos fallidos se entregan normalmente, pero recibes informes sobre ellos. Empieza siempre aquí.
• p=quarantine envía los correos electrónicos fallidos a la carpeta de spam del destinatario. Pasa aquí después de 2 a 4 semanas en p=none sin que ningún correo legítimo falle.
• p=reject rechaza los correos electrónicos fallidos de plano (un error SMTP 550). Pase aquí después de otras 2 a 4 semanas en p=quarantine.

Saltar directamente a p=reject es la causa más común de interrupciones relacionadas con DMARC. Descubrirá fuentes de envío legítimas que olvidó (su CRM, su herramienta de marketing, su mesa de ayuda) solo después de que sean rechazadas. Empiece siempre en p=none, lea los informes y luego escale.

Informes agregados de DMARC

Cuando configuras rua= en tu registro DMARC, empezarás a recibir informes XML diarios de cada proveedor de correo que gestione el correo de tu dominio, incluidos Google, Microsoft, Yahoo y otros. Estos informes muestran cada IP que envió correo bajo tu dominio y si SPF y DKIM pasaron y se alinearon para cada uno.

El XML sin procesar es ruidoso y legible por máquinas, por lo que la mayoría de los equipos conectan su dirección rua= a un servicio de informes DMARC (Postmark, dmarcian, EasyDMARC y similares) que analiza los informes en un panel de control legible. Es la única forma práctica de descubrir fuentes de envío legítimas que podrías haber pasado por alto antes de endurecer tu política.

Alineación DMARC

DMARC introduce un concepto que los otros protocolos no tienen, llamado alineación. SPF y DKIM pasan cada uno cuando su respectiva verificación es válida, pero DMARC solo cuenta ese pase si el dominio autenticado coincide con la dirección From: visible.

Hay dos tipos de alineación.

• Alineación SPF significa que el dominio smtp.mailfrom (return-path) coincide con el dominio From:.
• Alineación DKIM significa que la etiqueta d= en la firma DKIM coincide con el dominio From:.

DMARC pasa si al menos una de estas se alinea Y la verificación subyacente pasó.

La alineación relajada (la predeterminada) permite coincidencias de subdominios, por lo que el correo de mail.example.com se alinea con un From: en example.com. La alineación estricta requiere una coincidencia exacta. La mayoría de los remitentes usan la relajada a menos que tengan una razón de seguridad específica para la estricta.

La alineación es la razón más común de fallo de DMARC incluso cuando SPF y DKIM pasan individualmente. Muchos servicios de envío se autentican usando *su propio* dominio (por ejemplo, sendgrid.net), no el suyo, lo que significa que SPF y DKIM pasan pero DMARC falla porque nada se alinea con example.com. Corregir la alineación generalmente significa cambiar a un return-path personalizado o a una firma DKIM de marca ofrecida por su proveedor.

Cómo añadir un registro DMARC

Si su proveedor de correo electrónico le proporciona un registro DMARC específico, añada ese. Si no, este es un registro genérico seguro para empezar en _dmarc.sudominio.com:

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

Esto te pone en modo de monitorización con informes que llegan a un buzón que controlas. Para una configuración completa, incluyendo la gestión de informes y la progresión de políticas, consulta nuestra guía dedicada sobre cómo crear un registro DMARC.

Por qué necesitas los tres

Cada protocolo soluciona lo que los otros no pueden. Aquí está el desglose.

	SPF	DKIM	DMARC
Lo que previene	Servidores no autorizados que envían en nombre de tu dominio	Contenido del correo modificado en tránsito	Suplantación de la dirección From: por parte de atacantes, incluso cuando otras verificaciones pasan
Lo que verifica	IP de envío frente a tu lista autorizada	Firma criptográfica frente a tu clave pública	Alineación entre los resultados de autenticación y el dominio From:
Fallo común	El correo legítimo falla al reenviar	Los retransmisores de listas de correo modifican el cuerpo y rompen la firma	Tanto SPF como DKIM fallan en la alineación con el dominio visible
Si te lo saltas	Cualquier servidor puede afirmar enviar en nombre de tu dominio	Cualquiera puede modificar tu correo en tránsito sin ser detectado	Las autenticaciones fallidas no tienen aplicación

Ejecuta solo con SPF y serás vulnerable a la suplantación basada en alineación, donde un atacante se autentica con su propio dominio mientras muestra el tuyo. Ejecuta solo con DKIM y cualquier servidor aún puede hacerse pasar por ti. Ejecuta solo con DMARC y no tendrás autenticación subyacente para que la aplique. Los tres juntos son la única configuración que realmente funciona.

¿Son obligatorios SPF, DKIM y DMARC en 2026?

La autenticación de correo electrónico pasó de ser una buena práctica a ser innegociable entre 2024 y 2026. Aquí es donde están las cosas.

Remitentes masivos (más de 5000 correos al día a Gmail o Yahoo)

• Febrero de 2024. Gmail y Yahoo introdujeron requisitos para remitentes masivos. Se requieren SPF, DKIM y DMARC. Se requieren encabezados de cancelación de suscripción con un clic. La tasa de quejas de spam debe mantenerse por debajo del 0,3%.
• Mayo de 2025. Microsoft introdujo requisitos equivalentes para Outlook.com, Hotmail y Live.com.
• Noviembre de 2025. Gmail pasó de aplazamientos temporales (errores 421) a rechazo permanente (errores 550) para mensajes no conformes. Ya no hay período de gracia. El correo no conforme se rechaza de plano.

Remitentes de menor volumen (menos de 5000 al día)

Técnicamente no estás sujeto a las reglas de remitente masivo, pero las comprobaciones de autenticación subyacentes se aplican a cada conexión. La falta de SPF, DKIM o DMARC reduce la entrega en la bandeja de entrada hasta en un 76% incluso con un volumen bajo. Las reglas se dirigen nominalmente a los remitentes masivos, pero los filtros de spam utilizan las mismas señales para todos.

Contextos de cumplimiento

• PCI DSS v4.0 incluye requisitos de autenticación de correo electrónico para organizaciones que manejan datos de tarjetas de pago.
• La Directiva Operacional Vinculante 18-01 de CISA exige que todas las agencias federales de EE. UU. implementen SPF, DKIM y DMARC con p=reject.
• Existen requisitos similares en el Reino Unido (NCSC), Australia (ACSC) y Canadá (CCCS) para el gobierno y la infraestructura crítica.

Incluso si envías 50 correos electrónicos al mes desde tu formulario de contacto, todavía necesitas los tres registros.

El orden de configuración que importa

Añade SPF primero. Luego DKIM. Luego DMARC. Con esperas entre cada uno. Este orden no es negociable, y equivocarse en él es la razón más común por la que las nuevas implementaciones rompen la entrega.

Por qué importa este orden

DMARC comprueba los resultados de SPF y DKIM. Si añades DMARC antes de que esos dos estén implementados y validados, cada correo electrónico fallará la autenticación. Con una política de p=quarantine o p=reject, tu correo empezará a ir a spam o a ser rechazado en el momento en que DMARC se propague. Muchos proveedores ni siquiera te permitirán añadir un registro DMARC hasta que SPF pase la validación.

Tiempo hasta que cada uno esté activo

• SPF: 5 a 30 minutos
• DKIM: 1 a 4 horas
• DMARC: 1 a 24 horas

Después de que cada registro se propague, envía un correo electrónico de prueba a una dirección de Gmail que controles y comprueba las cabeceras a través de Mostrar original. Tanto SPF como DKIM deberían mostrar PASS antes de añadir DMARC.

Dónde añadir los registros SPF, DKIM y DMARC

Los tres registros se añaden como registros TXT en la configuración DNS de tu dominio, el mismo lugar donde gestionas los registros A, los registros MX y los servidores de nombres. Dónde se encuentra exactamente depende de quién esté gestionando tu DNS.

Alojamiento compartido (Bluehost, SiteGround, HostGator)

La mayoría de los hosts compartidos incluyen un Editor de Zona DNS en su panel de control bajo Dominio o Gestión de DNS. Busca una opción para añadir un registro TXT.

Registradores de dominios (GoDaddy, Namecheap, Google Domains)

Si tu hosting y dominio están separados, tu DNS suele residir con tu registrador. Busca Configuración de DNS o Gestionar DNS en el panel de tu dominio.

Cloudflare

Abre el panel de Cloudflare, selecciona tu dominio, haz clic en DNS en el menú de la izquierda y añade un nuevo registro TXT. Aquí tienes la vista del editor.

Vercel

Si Vercel gestiona el DNS de tu dominio, abre el proyecto, haz clic en Configuración » Dominios » Registros DNS y añade un nuevo registro TXT. El campo Host acepta @ para el apex (usado para SPF) y _dmarc para DMARC.

Netlify

El DNS de Netlify se encuentra en Dominios en el panel de tu equipo. Haz clic en el dominio, luego en Configurar Netlify DNS si aún no lo has hecho, y luego añade registros en Registros DNS.

Squarespace

Squarespace gestiona el DNS a través de Dominios » [nombre del dominio] » Configuración de DNS » Registros personalizados. Añade registros TXT con Host = @ para el dominio apex, o _dmarc para DMARC.

WP Engine

WP Engine no gestiona tu DNS por defecto, por lo que añadirás los registros SPF, DKIM y DMARC en el registrador que utilices para el dominio (GoDaddy, Namecheap, Cloudflare, etc.). Lo que necesitarás de WP Engine es el valor correcto para tu include: de SPF para que sus servidores de correo puedan enviar en nombre de tu sitio. Encuentra esto en el Portal de Usuario de WP Engine, en la configuración de DNS o de correo de tu entorno. Su include SPF típico es mail1.wpengine.com. Añádelo a tu registro SPF existente junto con cualquier otro remitente, nunca como un segundo registro v=spf1.

Cómo probar SPF, DKIM y DMARC

Tres formas fiables de verificar que los tres registros hacen lo que esperas.

Gmail “Mostrar original”

Envía un correo electrónico de prueba desde tu dominio a una dirección de Gmail que controles. Una vez que llegue, abre el correo, haz clic en el menú de tres puntos en la parte superior derecha y selecciona Mostrar original. Busca estas tres líneas cerca de la parte superior.

• SPF: PASS (con tu dominio)
• DKIM: PASS (con header.d= mostrando tu dominio)
• DMARC: PASS

Si alguno de estos muestra FAIL o NEUTRAL, salta a la sección de solución de problemas más abajo.

Comprobador de dominio de WP Mail SMTP

La herramienta de prueba de correo electrónico de WP Mail SMTP valida los tres registros automáticamente cada vez que envías un correo de prueba, sin necesidad de una herramienta separada. Señala registros faltantes, registros SPF múltiples, problemas de firma DKIM, fallos de alineación DMARC y problemas de registro PTR, todo desde tu administrador de WordPress. El Comprobador de dominio es gratuito en WP Mail SMTP Lite.

Comprobadores en línea

MxToolbox, dmarcian y HostedScan ofrecen búsquedas gratuitas de SPF, DKIM y DMARC. Introduce tu dominio y obtendrás un estado rápido de aprobado/fallido para cada registro, además de diagnósticos para errores comunes como demasiadas búsquedas de DNS o problemas de sintaxis.

Solución de problemas comunes

Si tus registros están configurados pero la autenticación sigue fallando, uno de estos escenarios es casi siempre la causa. Cada uno sigue la misma plantilla: síntoma, causa probable, diagnóstico y solución.

1. Gmail rechazó tu correo electrónico con "550-5.7.26"

Síntoma. Gmail rebota con un rechazo SMTP 550-5.7.26. El texto completo suele decir algo como "Gmail requiere que todos los remitentes se autentiquen con SPF o DKIM."

Causa probable. Falta un SPF o DKIM válido en el dominio de envío, o ambos están mal configurados.

Diagnóstico. Ejecuta tu dominio a través del comprobador en la parte superior de esta página, o utiliza el Comprobador de dominio de WP Mail SMTP. El resultado mostrará cuál de los tres registros falta o falla.

Solución. Agrega un registro SPF válido y confirma que DKIM está firmando para tu dominio de envío. Vuelve a enviar después de que ambos registros se propaguen. Para un diagnóstico completo, consulta nuestra guía sobre cómo solucionar el bloqueo de correos electrónicos de Gmail.

2. "Acción requerida: el registro SPF requerido por tu servidor SMTP no se ha añadido"

Síntoma. El panel de control de tu proveedor SMTP muestra una advertencia de que tu registro SPF falta o no los incluye.

Causa probable. La directiva include: de tu proveedor no está en el registro SPF de tu dominio.

Diagnóstico. Ejecuta dig TXT tu_dominio.com, o utiliza el comprobador de arriba. Busca el registro SPF y confirma si el dominio del proveedor (por ejemplo, sendlayer.net, _spf.google.com) está en la lista.

Solución. Agrega el include: del proveedor a tu registro SPF existente. Por ejemplo, un registro SPF que utiliza SendLayer más Google Workspace se leería v=spf1 include:sendlayer.net include:_spf.google.com ~all. Nunca crees un segundo registro SPF en el mismo dominio.

3. DMARC falla a pesar de que SPF pasa

Síntoma. Mostrar original de Gmail muestra SPF: PASS pero DMARC: FAIL.

Causa probable. Fallo de alineación SPF. Tu dominio de ruta de retorno no coincide con el dominio visible de From:.

Diagnóstico. Mira el valor smtp.mailfrom en las cabeceras. ¿Coincide con el dominio en From:?

Solución. Cambie el return-path de su servicio de envío a su dominio (la mayoría de los proveedores ofrecen una configuración de "return-path personalizado" o "dominio de rebote"), o confíe en la alineación DKIM en su lugar, que a menudo es más fácil de configurar.

4. Firma DKIM faltante en correos electrónicos recibidos

Síntoma. Las cabeceras no muestran ninguna línea DKIM-Signature:.

Causa probable. DKIM no está realmente configurado en el lado del remitente, o se está utilizando el selector incorrecto.

Diagnóstico. Envíe una prueba desde otra herramienta (directamente desde Gmail u otro servicio SMTP) para comparar. Verifique el panel de control de su proveedor SMTP para ver el estado de DKIM, ya que la mayoría muestra si el selector está verificado.

Solución. Vuelva a verificar que los registros CNAME o TXT de DKIM existan exactamente como los especificó su proveedor. El nombre del selector en su registro DNS debe coincidir con el que el proveedor está firmando. Los errores tipográficos aquí son extremadamente comunes.

5. SPF "permerror: demasiadas búsquedas de DNS"

Síntoma. Los servidores de correo rechazan sus mensajes con un PERMERROR de SPF.

Causa probable. Su registro SPF contiene más de 10 búsquedas de DNS (el límite estricto de 10 de RFC 7208). Común al apilar directivas include: para varios servicios.

Diagnóstico. Utilice una herramienta de aplanamiento de SPF para contar sus búsquedas. Cada include:, a, mx, ptr y exists: cuenta.

Solución. Elimine los includes innecesarios o utilice un servicio de aplanamiento de SPF que resuelva los includes en entradas IP directas. Guía completa en nuestra guía de fusión de SPF.

6. Múltiples registros SPF en el mismo dominio

Síntoma. PERMERROR o NEUTRAL de SPF a pesar de tener un registro que parece válido.

Causa probable. Tiene dos o más registros TXT de SPF. RFC 7208 dice que esto no es válido y los receptores lo tratarán como si no existiera ningún registro SPF.

Diagnóstico. Ejecute dig TXT sudireccion.com o utilice la búsqueda SPF de MxToolbox. Si ve dos registros que comienzan con v=spf1, ese es el problema.

Solución. Combine las directivas include: de ambos registros en un solo registro. Consulte la guía de fusión anterior.

7. Registro DKIM demasiado largo para DNS

Síntoma. Su proveedor le dio una clave DKIM, pero DNS no la acepta.

Causa probable. Los registros TXT individuales tienen un límite de 255 caracteres por cadena. Las claves DKIM de 2048 bits superan esto y deben dividirse en varias cadenas entrecomilladas dentro del mismo registro.

Diagnóstico. Cuente los caracteres de su clave. Más de 255 significa que este es el problema.

Solución. Divida el valor en fragmentos de 255 caracteres, cada uno entre comillas, como "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI...". La mayoría de los proveedores de DNS modernos hacen esto automáticamente. Algunos no. Consulte la sección de longitud de clave DKIM anterior para obtener la guía completa.

8. Fallo de alineación DMARC (el asesino silencioso)

Síntoma. SPF: PASS y DKIM: PASS pero DMARC: FAIL.

Causa probable. Ningún protocolo está alineado con el dominio From: aunque ambos pasen individualmente.

Diagnóstico. Compare tres valores en las cabeceras: el dominio From:, el dominio smtp.mailfrom y la etiqueta DKIM d=. Al menos uno de los dos últimos debe coincidir con el primero.

Solución. Configure su servicio de envío para que utilice su dominio en el return-path (para la alineación SPF) o en la firma DKIM (para la alineación DKIM). La mayoría de los proveedores utilizan su propio dominio por defecto. Debe optar por la alineación.

9. DMARC p=reject bloqueando sus propios correos legítimos

Síntoma. Los clientes dejan de recibir sus correos transaccionales (restablecimientos de contraseña, recibos), pero sus envíos de prueba funcionan correctamente.

Causa probable. Pasó a p=reject demasiado rápido, antes de capturar todas las fuentes de envío legítimas en su SPF.

Diagnóstico. Consulte sus informes agregados de DMARC. Muestran todos los remitentes que han fallado bajo su dominio. Los legítimos serán obvios (su CRM, herramienta de marketing, helpdesk).

Solución. Vuelva a p=quarantine o p=none. Utilice los informes DMARC para añadir los remitentes legítimos que faltan a SPF. Espere de 2 a 4 semanas hasta que los informes muestren un 0% de fallos de correo legítimo, y luego vuelva a aplicar la política.

10. Registros añadidos pero no se propagan

Síntoma. Añadió los registros, pero las herramientas todavía dicen que faltan.

Causa probable. Caché DNS en su registrador, su resolvedor local o el servidor receptor. Común con cambios de TTL bajos después de que registros de TTL altos se hayan cacheados previamente.

Diagnóstico. Ejecute dig +trace TXT yourdomain.com desde una red diferente, o consulte directamente a Google DNS con dig @8.8.8.8 TXT yourdomain.com. Si estos muestran el registro pero su probador no, es caché.

Solución. Espere. La mayoría de la propagación se completa en una hora para SPF y hasta 24 horas para DMARC. Si después de 48 horas todavía no ve nada, vuelva a comprobar que el registro se guardó correctamente en su registrador. Un error común son las interfaces que necesitan un paso de confirmación que omitió.

Notas específicas de WordPress

WordPress tiene un problema de correo electrónico específico. Por defecto, utiliza la función mail() de PHP, que envía mensajes sin ninguna autenticación. Sus registros SPF, DKIM y DMARC pueden estar perfectamente configurados, pero si WordPress envía correos electrónicos a través de mail() de PHP desde la IP compartida de su proveedor de alojamiento web, y esa IP no está en su registro SPF, todas las comprobaciones de autenticación fallan.

La solución es enrutar todo el correo de WordPress a través de un servicio SMTP autenticado. WP Mail SMTP hace esto con integraciones de un solo clic para SendLayer, SMTP.com, Brevo, Gmail/Google Workspace, Microsoft 365, Amazon SES, Mailgun, SendGrid, Postmark, SparkPost y otros. Cada integración está preconfigurada para autenticarse correctamente y alinearse con su dominio. Las funciones mejoradas de entrega de correo de WP Mail SMTP incluyen el Comprobador de Dominio gratuito que marca los registros SPF, DKIM y DMARC faltantes o mal configurados directamente dentro de WordPress.

Si los correos electrónicos de su WordPress terminan en spam, la causa suele ser la falta de autenticación o una autenticación desalineada. El diagnóstico completo se encuentra en nuestra guía sobre por qué los correos electrónicos de WordPress van a spam. Para la configuración, nuestra guía de validación de correo electrónico de WordPress le guía a través de la verificación de los registros.

Soluciona tus correos de WordPress ahora

Preguntas frecuentes sobre SPF, DKIM y DMARC

Estas son las preguntas más buscadas sobre autenticación de correo electrónico, organizadas de la más frecuente a la más técnica. Cada respuesta es autónoma.

¿Cuál es la diferencia entre SPF, DKIM y DMARC?

SPF indica quién puede enviar, DKIM demuestra que los correos son genuinos y no han sido alterados, y DMARC aplica qué sucede cuando falla alguna de las comprobaciones.

SPF autoriza los servidores de envío, DKIM añade una firma criptográfica a prueba de manipulaciones y DMARC establece la política que siguen los receptores cuando SPF o DKIM fallan en la alineación. Necesita los tres porque cada uno cubre una brecha que los otros dejan abierta. SPF sin DKIM falla en correos reenviados. DKIM sin SPF permite que servidores no autorizados reclamen su dominio. Ambos sin DMARC significa que los servidores receptores no tienen instrucciones de aplicación cuando algo falla.

¿Necesita los tres, SPF, DKIM y DMARC?

Sí. Desde febrero de 2024, Gmail y Yahoo requieren los tres para los remitentes de más de 5000 correos electrónicos por día, y Gmail comenzó a rechazar el correo no conforme directamente en noviembre de 2025. Incluso por debajo de ese umbral, la falta de alguno de los tres reduce la colocación en la bandeja de entrada.

SPF y DKIM fallan en diferentes situaciones (SPF falla al reenviar, DKIM falla si un relé modifica el mensaje), por lo que una configuración de un solo protocolo falla de forma impredecible.

¿Puede usar DMARC sin SPF o DKIM?

Técnicamente, DMARC pasa si SPF o DKIM pasan y se alinean, por lo que puede ejecutar DMARC con solo uno. En la práctica, debería configurar ambos, porque cada uno falla en escenarios en los que el otro sobrevive.

Ejecutar DMARC solo con SPF significa que los correos reenviados fallan. Ejecutarlo solo con DKIM significa que los mensajes modificados en tránsito fallan. Ambos juntos proporcionan una autenticación fiable.

¿Qué significan p=none, p=quarantine y p=reject?

Estos son los niveles de aplicación de DMARC, en orden de estrictez.

p=none es el modo de monitorización. Informa de fallos pero no bloquea nada, y es por donde todo dominio debería empezar. p=quarantine envía los correos electrónicos fallidos a la carpeta de spam. p=reject bloquea completamente los correos electrónicos fallidos.

Pase de none a quarantine a reject gradualmente, solo después de que sus informes confirmen que ningún correo legítimo está fallando.

¿En qué orden debería configurar SPF, DKIM y DMARC?

Configura primero SPF, luego DKIM y después DMARC. DMARC lee los resultados de SPF y DKIM, por lo que añadirlo primero provoca que todos los correos fallen la autenticación inmediatamente.

Añade SPF, espera a que se propague, añade DKIM, verifica que ambos pasan en una comprobación de Mostrar original de Gmail, y luego añade DMARC empezando con p=none.

¿Cómo compruebo si SPF, DKIM y DMARC están configurados correctamente?

Utiliza una herramienta de comprobación (como la gratuita en la parte superior de esta página) que busque los tres registros de tu dominio y reporte su estado.

También puedes verificarlo manualmente. Envía un correo a una dirección de Gmail, ábrelo, haz clic en el menú de tres puntos, selecciona Mostrar original y confirma que SPF, DKIM y DMARC muestran PASS.

¿Qué es la alineación DMARC?

La alineación es la comprobación que hace que DMARC sea significativo. Confirma que el dominio que ha pasado SPF o DKIM coincide con el dominio de la dirección visible From: del correo.

La alineación SPF requiere que el dominio de la ruta de retorno coincida con el dominio From:. La alineación DKIM requiere que la etiqueta d= de la firma coincida con él. La causa más común de fallo de DMARC es la desalineación, no un fallo directo de SPF o DKIM.

¿Qué significa el error “550-5.7.26” de Gmail?

El error 550-5.7.26 significa que Gmail rechazó tu correo porque el dominio remitente no está autenticado. Gmail ahora requiere que todos los remitentes se autentiquen con SPF o DKIM.

Para solucionarlo, añade un registro SPF válido y una firma DKIM para tu dominio remitente, y luego confirma que ambos pasan antes de reenviar. El primer elemento de solución de problemas anterior detalla el diagnóstico completo.

¿Qué significa cuando “Mostrar original” de Gmail muestra SPF, DKIM y DMARC PASS?

Significa que tu correo fue autenticado correctamente. SPF PASS confirma que el correo provino de un servidor autorizado. DKIM PASS confirma que el mensaje no fue alterado durante el tránsito. DMARC PASS confirma que el dominio autenticado se alinea con tu dirección visible From:.

Que los tres pasen es el resultado que deseas. Maximiza la ubicación en la bandeja de entrada.

¿Detienen SPF, DKIM y DMARC los correos que van a spam?

Son necesarios pero no suficientes. La autenticación indica a los proveedores de buzones que tus correos son genuinamente tuyos, lo cual es un requisito previo para la ubicación en la bandeja de entrada, pero otros factores siguen siendo importantes. Estos incluyen la reputación del remitente, la calidad del contenido, las tasas de interacción, la higiene de la lista y un registro PTR válido.

Configura los tres primero, luego aborda los otros factores de entregabilidad de correo electrónico.

¿Cuál es la mejor herramienta para comprobar DMARC, SPF y DKIM?

La forma más rápida es un comprobador que pruebe los tres a la vez, como el gratuito de esta página. Para la monitorización continua, Google Postmaster Tools muestra cómo Gmail evalúa tu autenticación, y el Comprobador de Dominio integrado de WP Mail SMTP verifica los tres registros directamente dentro de WordPress.

¿Cuál es el significado completo de SPF, DKIM y DMARC?

SPF significa Sender Policy Framework. DKIM significa DomainKeys Identified Mail. DMARC significa Domain-based Message Authentication, Reporting, and Conformance.

Juntos forman el conjunto estándar para autenticar correos y proteger un dominio contra la suplantación de identidad.

A continuación, comprueba tu registro PTR

SPF, DKIM y DMARC son tres de los cuatro registros DNS que importan para la entregabilidad del correo electrónico. El cuarto es tu registro PTR, la entrada DNS inversa que mapea tu IP de envío de vuelta a tu dominio. Los proveedores de buzones lo comprueban en cada conexión, y un PTR ausente o genérico perjudicará tu entregabilidad incluso cuando SPF, DKIM y DMARC pasen.

Para el desglose completo, consulte nuestra guía sobre registros PTR y DNS inverso.

Soluciona tus correos de WordPress ahora

¿Listo para arreglar tus correos electrónicos? Empieza hoy mismo con el mejor plugin SMTP de WordPress. Si no tienes tiempo para arreglar tus correos electrónicos, puedes obtener asistencia completa de configuración White Glove como compra adicional, y hay una garantía de devolución de dinero de 14 días para todos los planes de pago.