Tu correo fue rechazado. Los encabezados dicen spf=fail. Tienes un 550 5.7.1 o un 550 5.7.26 delante, y un cliente espera una respuesta que nunca llegó.
Un fallo de SPF no es un problema de contenido. Es un fallo de autenticación DNS. El servidor de correo receptor comprobó tu registro SPF, descubrió que la IP de envío no estaba en la lista autorizada y rechazó el mensaje antes de que pudiera llegar a una carpeta de spam.
Desde febrero de 2024, Google y Yahoo rechazan el correo no autenticado a nivel de protocolo, en lugar de limitarse a marcarlo como sospechoso. Esta guía descifra el código de error concreto, muestra dónde encontrar la IP que falla en los encabezados y explica las tres correcciones de DNS que resuelven la gran mayoría de los fallos de SPF. Sin conjeturas. Empieza por la solución adecuada.
Si estás configurando el correo en tu dominio por primera vez, establece correctamente la configuración DNS básica antes de investigar fallos; los problemas de SPF casi siempre nacen de una configuración inicial incompleta.
¿Qué es un fallo de SPF?
Un fallo de SPF ocurre cuando un servidor receptor evalúa el registro Sender Policy Framework de tu dominio y descubre que la dirección IP de envío no figura como autorizada. SPF se publica como un registro TXT de DNS en tu dominio y enumera todas las direcciones IP y servicios de correo autorizados a enviar en tu nombre. Si la comprobación falla, el servidor rechaza el mensaje (fallo estricto) o lo acepta como sospechoso (fallo flexible). En ambos casos, tu política DMARC lo contabiliza como fallo.
SPF comprueba el remitente del sobre, la dirección MAIL FROM negociada durante el intercambio SMTP, no el encabezado "From" que ve el destinatario. Esta diferencia es importante al rastrear el origen del fallo.
| Resultado SPF | Calificador del registro | Qué ocurre con el correo |
|---|---|---|
Fallo estricto (fail) |
-all |
IP no autorizada. El servidor receptor rechaza el mensaje según la política. |
Fallo flexible (softfail) |
~all |
IP no autorizada. El correo se acepta, pero se marca. A menudo llega al spam. |
| PermError | Sintaxis incorrecta o 10+ consultas | El registro no es válido. SPF falla para todos los remitentes, incluido el tráfico legítimo. |
| Superado | -all (IP incluida) |
IP autorizada. Entrega normal. |
Lee el código de error antes de tocar nada
Cada servidor de correo devuelve códigos SMTP distintos ante un fallo de SPF. El código de error indica exactamente qué decidió el receptor y por qué; tratar un 550 5.7.26 igual que un 550 5.7.1 genérico hace perder tiempo de diagnóstico. Relaciona el código con la causa antes de modificar un solo registro DNS.
| Proveedor | Código de error | Significado |
|---|---|---|
| Google / Gmail | 550 5.7.26 |
Correo no autenticado bloqueado. No se encontró una validación SPF o DKIM. Rechazo habitual conforme a las reglas de Google para remitentes masivos vigentes desde febrero de 2024. |
| Microsoft / Outlook | 550 5.7.515 |
Identidad del remitente no autenticada. Fallo de SPF o DKIM. El mensaje "Acceso denegado" aparece antes de que se analice el contenido del correo. |
| Receptor genérico | 550 5.7.1 |
Acceso de retransmisión denegado. Código general para rechazos por política. El receptor no confía en la IP de envío. |
| Fallo flexible (aceptado) | Los encabezados muestran ~all |
Resultado SPF fallido, pero con una política permisiva. El correo llega al spam en vez de rechazarse. |
Paso 1: encuentra la IP que falla en los encabezados
No adivines qué IP causó el fallo de SPF. Abre los encabezados sin procesar del mensaje rechazado (o la propia notificación de rechazo) y busca Authentication-Results. Este encabezado indica la IP exacta que evaluó el receptor y la decisión que tomó.
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of team@example.com does not designate
192.0.2.55 as permitted sender)Ahí tienes dos datos forenses: la IP de envío (192.0.2.55) y el dominio comprobado (example.com). Ahora identifica a quién pertenece esa IP:
- ¿Una herramienta SaaS que has incorporado recientemente? (HubSpot, Zendesk, Shopify)
- ¿Tu servidor web? (WordPress, cPanel)
- ¿Un servicio de reenvío? (Consulta más abajo la sección sobre la trampa del reenvío)
Después confirma tu registro SPF actual con una consulta rápida:
dig +short txt yourdomain.com | grep spfSi ves más de una línea que comienza por v=spf1, ya has encontrado uno de los problemas.
Paso 2: las tres soluciones más comunes para un fallo de SPF
La mayoría de los fallos de SPF se debe a una de tres causas: falta el include de un proveedor, hay un registro duplicado o se supera el límite de 10 consultas DNS. Elige la solución que corresponda a lo que encontraste en el Paso 1.
Solución 1: falta el include del proveedor
Añadiste una herramienta de correo nueva, como HelpScout, HubSpot, Zendesk o el correo transaccional de Shopify, pero no actualizaste el DNS. El servicio envía en tu nombre mediante una IP que no has autorizado. Esta es la causa más común de un fallo de SPF tras incorporar un proveedor nuevo.
Registro que falla:
v=spf1 include:spf.trekmail.net -allRegistro que se valida (después de añadir HelpScout):
v=spf1 include:spf.trekmail.net include:helpscoutemail.com -allBusca en la documentación del proveedor la cadena include de SPF que exige. Añádela al registro TXT de SPF existente; no crees otro registro. Todos los servicios que utilices para enviar deben figurar en él.
Solución 2: el registro doble, un error de sintaxis fatal
Solo puede haber un registro SPF por dominio. Si añades un segundo registro TXT para una herramienta nueva en lugar de integrarlo en el existente, los receptores ven dos políticas contradictorias e invalidan ambas. El resultado es un PermError, un fallo estricto de SPF para todos los correos del dominio, incluidos los que antes se entregaban sin problemas.
Incorrecto: dos registros separados:
v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -allCorrecto: combinados en uno:
v=spf1 include:spf.trekmail.net include:_spf.google.com -allAccede a tu proveedor de DNS, elimina todos los registros TXT de SPF menos uno e integra todo en una sola línea. Un PermError causado por un registro doble provoca un fallo silencioso de SPF para todos los remitentes hasta que se corrige.
Solución 3: el límite de 10 consultas, un fallo de arquitectura
La norma RFC 7208 limita la evaluación de SPF a 10 consultas DNS. Esto evita que los servidores se utilicen para amplificar tráfico DNS. Mecanismos como include, a y mx cuentan para el límite, al igual que los include anidados, cuando el proveedor incluye a su vez el registro de otro proveedor.
Si superas las 10 consultas, obtienes un PermError. SPF falla para todos. Comprueba la cantidad actual de consultas siguiendo tu registro:
dig +short txt yourdomain.comCuenta manualmente cada mecanismo include, a y mx, y después sigue los include anidados de cada proveedor. Si superas el límite, hay dos opciones claras:
- Separa los remitentes en subdominios. Traslada las herramientas de marketing de gran volumen a
marketing.yourdomain.com. Ese subdominio obtiene su propio cupo nuevo de 10 consultas, completamente independiente del registro de tu dominio principal. - Aplana el registro. Sustituye las cadenas
includepor las IP reales a las que resuelven mediante mecanismosip4:oip6:. Estos no cuentan como consultas. La contrapartida es que tendrás que actualizar el registro manualmente cuando los proveedores cambien sus IP.
Otra trampa es el límite de consultas vacías. Si más de dos consultas de la cadena devuelven NXDOMAIN, por ejemplo, por un error como include:spf.gogle.com, el registro queda invalidado según RFC 7208 §11.1. Un solo error tipográfico en cualquier include anidado de un proveedor puede arruinar toda la evaluación de SPF.
La trampa del reenvío: por qué SPF falla en correo legítimo
Este fallo de SPF no tiene nada que ver con tu configuración DNS. Envías un correo a una dirección de antiguos alumnos (alice@university.edu) que lo reenvía automáticamente a Gmail (alice@gmail.com). Gmail ve el correo llegar desde la IP del servidor de la universidad. Tu registro SPF no autoriza esa IP. SPF falla, aunque lo hayas hecho todo bien.
La ruta: Tu servidor → Servidor de la universidad → Gmail. La comprobación: Gmail evalúa el último salto. No puedes corregir los fallos de reenvío con SPF porque SPF solo autoriza la IP de envío original. En cuanto interviene un reenviador, la comprobación de IP deja de funcionar.
La solución correcta es DKIM. DKIM firma criptográficamente el cuerpo y los encabezados del mensaje. El reenviador normalmente no modifica el cuerpo, por lo que la firma DKIM sobrevive al salto. Incluso si SPF falla, una firma DKIM válida permite que el mensaje supere DMARC.
Si gestionas reenvíos a nivel de infraestructura y quieres reescrituras compatibles con SPF, conviene entender el Sender Rewriting Scheme (SRS), que permite a los reenviadores reescribir el remitente del sobre para que SPF se valide en el destino final. Para otros fallos de entrega por reenvío, la guía para configurar y corregir el reenvío de correo cubre todo el proceso de diagnóstico.
Verifica la corrección antes de continuar
Después de actualizar el registro DNS, espera a que se propague; suele tardar entre 5 y 30 minutos con la mayoría de los proveedores, aunque en algunos casos puede llevar varias horas. Comprueba después que el cambio se haya aplicado antes de darlo por terminado.
Envía un correo de prueba a una dirección de Gmail y abre los encabezados sin procesar. Busca Authentication-Results. Este es el resultado que buscas:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of team@example.com designates
192.0.2.55 as permitted sender)Si todavía ves spf=fail o spf=softfail, puede que el cambio aún no se haya propagado o que el registro siga teniendo un problema. Compara la IP de los encabezados con la del registro actualizado. Deben coincidir.
También puedes verificar el registro directamente:
dig +short txt yourdomain.comConfirma que haya exactamente un registro que empiece por v=spf1, que incluya todos tus servicios de envío y que termine en -all (fallo estricto) o ~all (fallo flexible).
Gestión de SPF en varios dominios
Para un dominio, gestionar SPF es una tarea puntual. Añade los include, combina los duplicados y corrige la cantidad de consultas. Pero si administras el correo de 10, 50 o 500 dominios, cada uno con su registro SPF y sus proveedores SaaS, diagnosticar manualmente cada fallo de SPF se convierte en una carga operativa real.
| Enfoque | Registro SPF necesario | Quién gestiona la reputación de la IP |
|---|---|---|
| Hazlo tú mismo / BYO SMTP | Registro completo con todos los proveedores | Tú, manualmente |
| SMTP gestionado de TrekMail | v=spf1 include:spf.trekmail.net -all |
TrekMail: rotación de IP, reputación y alineación DKIM |
El SMTP gestionado de TrekMail, disponible desde Starter por $3.50/mo, reduce la configuración a un solo include por dominio. TrekMail se ocupa de la rotación de IP, la supervisión de rechazos, la alineación DKIM y la infraestructura de entrega subyacente. Con el plan Agency ($23.25/mo), las agencias pueden aplicar una plantilla DNS estandarizada a todos los dominios de clientes, en vez de buscar fallos de SPF en cientos de registros individuales.
Inicia una prueba gratuita de 14 días si quieres ver cómo funciona la entrega gestionada en la práctica.
Fallo de SPF: resumen
Un fallo de SPF significa que el servidor receptor consultó tu DNS, comprobó que la IP de envío no figuraba y aplicó tu política. Un fallo estricto (-all) implica rechazo. Un fallo flexible (~all) suele llevar a la carpeta de spam. PermError significa que el registro está roto y SPF falla para todos los remitentes hasta que corrijas el propio registro.
Aplica las soluciones en este orden:
- Encuentra la IP que falla en el encabezado
Authentication-Results - Añade el include que falta si el fallo de SPF apareció al incorporar un servicio nuevo
- Combina los registros SPF duplicados en uno
- Reduce las consultas DNS a menos de 10 o separa los remitentes de gran volumen en subdominios
- Si SPF falla en correo reenviado, implementa DKIM; SPF no puede sobrevivir a un salto de retransmisión
Empieza por la solución correcta, verifícala en los encabezados y habrás terminado.
