¿Por qué el correo falla en SPF? Cómo leer el registro que comprueban los receptores

Un encabezado dice spf=fail en un mensaje que ustedes sí enviaron. Su plataforma de correo dice que SPF está configurado. Ambas cosas pueden ser ciertas a la vez, porque SPF no revisa el remitente que ven en la bandeja de entrada, y porque un registro que se lee bien puede seguir siendo inválido en el momento en que un receptor lo evalúa.

SPF es la primera comprobación de identidad que ejecutan la mayoría de los receptores, y es la más propensa a estar mal de una forma que se ve bien hasta que un mensaje concreto falla.

Casi todo fallo corresponde a uno de tres patrones: dos registros SPF en un mismo dominio, lo cual es inválido y devuelve permerror; un proveedor agregado sin actualizar el DNS, que falla solo en el correo de ese proveedor; o el límite de diez consultas DNS, que hace fallar todo a la vez. Estos casos se desarrollan en qué errores de SPF aparecen con más frecuencia en su correo. Leer primero el registro es lo que les dice cuál de los tres tienen.

¿Qué comprueba SPF realmente?

SPF responde una pregunta: ¿este mensaje vino de un servidor que su dominio declara autorizado a enviar?

No demuestra que el mensaje no fue alterado. Eso es DKIM. No dice a los receptores qué hacer cuando las comprobaciones fallan. Eso es DMARC. SPF es una lista de permisos publicada en el DNS, y los servidores que reciben consultan esa lista cuando llega el correo.

La consulta usa dos datos:

1. El dominio del remitente del sobre (la dirección MAIL FROM, a menudo oculta en el encabezado Return-Path).
2. La dirección IP del servidor que se conectó para entregar el mensaje.

Si la IP está autorizada por el registro SPF de ese dominio, el receptor anota spf=pass. Si no, obtienen fail, softfail o permerror, según cómo esté escrito el registro y si el registro en sí es válido.

Lo que SPF no hace: no revisa la dirección From visible que ve el lector. Un mensaje puede mostrar you@yourbrand.com en la bandeja de entrada mientras el remitente del sobre es bounce@esp-vendor.net. SPF solo evalúa el dominio del sobre contra la IP que se conecta. Esa brecha es la razón de que exista la alineación de DMARC, y de que SPF por sí solo nunca detenga la suplantación del nombre para mostrar.

Si el correo está cayendo en spam y todavía no han leído encabezados, empiecen por el diagnóstico sereno y avancen con las comprobaciones de identidad en orden. SPF es el paso uno de ese camino.

¿Cómo es un registro SPF real?

Un registro SPF válido es una única respuesta TXT en el dominio raíz (o en el subdominio desde el que envían). Siempre empieza con v=spf1 y termina con un calificador sobre all:

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

Léanlo de izquierda a derecha:

Token	Significado
v=spf1	Marcador de versión. Obligatorio. Si falta, el registro se ignora.
include:_spf.google.com	Sigue el SPF publicado por Google y trata sus IPs autorizadas como autorizadas para ustedes. Cuesta una consulta DNS.
include:sendgrid.net	Igual para SendGrid. Otra consulta.
~all	Soft fail: todo lo no listado es sospechoso, pero no es un rechazo automático en todos los receptores.

El mecanismo include: es la forma en que la mayoría de los remitentes SaaS se autoriza sin listar a mano decenas de rangos de IP. Su registro apunta al del proveedor; el registro del proveedor lista las IPs.

Otros mecanismos que verán en la práctica:

• ip4:198.51.100.0/24 autoriza directamente un rango IPv4 específico (sin consulta extra).
• a o mx autoriza los hosts A o MX del dominio.
• redirect=otherdomain.com delega toda la política al SPF de otro dominio (poco común; úsenlo con cuidado).

Un registro con solo v=spf1 ~all es técnicamente válido e inútil: no autoriza a nadie de forma explícita, así que todo cae en soft fail. Un registro con +all es peor: autoriza todo internet y les señala una mala configuración a los filtros que prestan atención.

Si arman un registro desde cero, el generador de SPF construye un TXT único y válido a partir de los remitentes que realmente usan. Pasen el registro terminado por el chequeo de salud del correo antes de darlo por terminado.

¿Cuál es la diferencia entre softfail y hardfail?

El calificador sobre all es la política para todos los que no aparecen listados de forma explícita:

• ~all (softfail): “Probablemente no autorizado.” Muchos receptores lo tratan como una señal negativa pero igual aceptan el mensaje si DKIM pasa y la reputación está limpia.
• -all (hardfail): “No autorizado.” Señal más fuerte. Algunos receptores rechazan de plano; otros igual aceptan con suficiente cobertura de DKIM y DMARC.
• ?all (neutral): “Sin declaración.” Raro en la práctica; no lo usen en un dominio desde el que envían.
• +all (pass all): Nunca lo usen en un dominio de producción.

La mayoría de los remitentes pequeños publican ~all mientras todavía descubren cada herramienta que envía en su nombre. Pásense a -all solo cuando la lista de includes esté completa y lleven varias semanas de reportes de DMARC sin fuentes inesperadas.

La diferencia práctica aparece en los encabezados. Un softfail a menudo se lee como spf=softfail aunque el mensaje sea aceptado. Un hardfail en un dominio con DKIM débil es un camino común hacia la carpeta de correo masivo. Ninguno reemplaza la política de DMARC; son entradas para la puntuación del receptor, no órdenes.

¿Qué errores de SPF aparecen con más frecuencia en su correo?

Tres patrones cubren la mayoría de los fallos de SPF en el mundo real.

Dos registros SPF en un mismo dominio. El DNS devuelve dos respuestas TXT separadas que empiezan ambas con v=spf1. La RFC 7208 dice que eso es inválido: los receptores no deben fusionarlas, y muchas devuelven permerror, lo que hace fallar la comprobación por completo. La solución es un solo registro que combine todos los remitentes autorizados. Borren el duplicado; no los apilen.

Un proveedor agregado, DNS nunca actualizado. Las herramientas de automatización de marketing, tickets, CRM y facturación todas envían correo. Cada una necesita un include: o un rango de IP. El síntoma es un fallo selectivo: el correo de Google Workspace pasa, el correo de la herramienta nueva cae en soft fail porque sus IPs nunca se autorizaron.

El límite de diez consultas. Cada include: y la mayoría de los demás mecanismos cuestan una consulta DNS mientras el receptor evalúa el registro. Pasadas diez consultas, el resultado es permerror. Los includes anidados dentro de los registros de los proveedores cuentan contra su límite incluso cuando nunca tocaron el DNS. Si están cerca del límite, el SPF flattener les muestra el árbol completo y el conteo acumulado.

Menos comunes pero vale la pena conocerlos: SPF en el hostname equivocado (publicar en mail.example.com mientras el sobre usa example.com) y entradas ip4: desactualizadas después de que un proveedor cambia rangos de direcciones sin avisar.

¿Cómo comprobar y corregir su registro en cinco minutos?

Trabajen desde el dominio del sobre, no desde la dirección From visible.

1. Envíen un mensaje de prueba desde cada plataforma que usen (correo del workspace, ESP, proveedor transaccional).
2. Abran el código fuente en bruto y busquen Return-Path o smtp.mailfrom= en Authentication-Results. Ese dominio es el que SPF evalúa.
3. Consúltenlo con dig +short TXT example.com y confirmen que obtienen exactamente una respuesta que empieza con v=spf1.
4. Lean Received-SPF o la línea SPF dentro de Authentication-Results en el mensaje de prueba. pass significa que esa vía está autorizada. fail, softfail o permerror significan corregir el registro o la configuración de envío antes de tocar el texto o las plantillas.
5. Si al registro le falta un remitente, agreguen el include: documentado por el proveedor y eliminen cualquier TXT de SPF duplicado que encuentren en el mismo nombre.

Para una foto instantánea de un solo dominio sin leer encabezados, el chequeo de salud del correo devuelve veredictos de SPF, DKIM y DMARC en una sola pasada.

Qué hacer a continuación

SPF es una pata de un taburete de tres patas. Publiquen firmas DKIM desde cada plataforma de envío, y después DMARC para que los receptores sepan qué hacer cuando SPF y DKIM no se alinean con su dominio From visible. Creadores y negocios de cursos suelen manejar tres o cuatro herramientas en un solo dominio; las agencias manejan ese problema a escala en las zonas de sus clientes.

Cuando el registro de hoy esté limpio, conviértanlo en una rutina. Los registros de autenticación se desvían cuando el DNS cambia y nadie actualiza el TXT. Una pasada semanal lo detecta antes de que lo haga la entregabilidad; el flujo completo está en la revisión semanal de entregabilidad.

Lista de verificación

1. Confirmen un solo TXT de SPF en el dominio que usa su remitente del sobre.
2. Hagan una lista de cada sistema que envía correo por ustedes y emparejen cada uno con un include: o un ip4: en ese registro.
3. Configuren ~all hasta que los reportes de DMARC dejen de mostrar fuentes sorpresa, y entonces consideren -all.
4. Prueben cada vía de envío y lean Authentication-Results en un mensaje real.
5. Corrijan permerror antes de perseguir causas de reputación o de contenido.