Qué es SPF y por qué muchos están mal, aunque no lo parezca

Qué es

Cuando un servidor entrega un correo, se presenta con una dirección técnica de devolución, el sobre (en inglés, Return-Path o MAIL FROM). No es el remitente que ve tu lector. Es la dirección a la que vuelven los rebotes, y no siempre es de tu dominio.

SPF es un registro de texto que publicas en el DNS de tu dominio con la lista de servidores que pueden usar tu dominio en ese sobre. El buzón que recibe el correo mira de qué dominio es el sobre, busca su SPF y comprueba si el servidor que se lo entrega está en la lista.

Un SPF típico se parece a este:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.25 ~all

Se lee de izquierda a derecha:

• v=spf1 dice que es un registro SPF.
• include: autoriza los servidores que otro publica en su propio SPF. Es como se da permiso a Google, a Microsoft o a una herramienta de envío.
• ip4: e ip6: autorizan direcciones concretas, por ejemplo un servidor propio.
• a y mx autorizan las direcciones de tu web y las de los servidores que reciben tu correo.
• ~all o -all, al final, dicen qué hacer con todo lo demás: sospechar o rechazar.

Hay dos reglas que no se ven en el registro y que rompen muchos: solo puede haber un SPF por nombre, y la comprobación no puede pasar de diez consultas DNS. Con dos registros, o con once consultas, el SPF entero deja de valer. Lo del límite lo contamos con calma en SPF con más de diez consultas DNS.

Lo que SPF no hace

SPF no comprueba el remitente que ve tu lector, solo el sobre. Por eso, por sí solo, no frena la suplantación: alguien puede poner tu dirección como remitente y usar su propio dominio en el sobre, y su SPF pasará sin problema.

Eso lo cierra DMARC, que exige que el dominio del sobre coincida con el de tu remitente. A eso se le llama alineación. Un correo pasa DMARC si pasa SPF con un sobre de tu dominio, o si lleva una firma DKIM válida de tu dominio. Con una de las dos basta. Lo explicamos en qué es DMARC y por qué p=none no te protege de nada.

Y aquí está el origen de muchos malentendidos: buena parte de las herramientas de envío no usan tu dominio en el sobre, sino el suyo. Para esos correos, tu SPF no entra en juego, por muchos permisos que tenga. Lo que los sostiene es la firma. Cómo lo hace cada herramienta de newsletter está en esta comparativa.

Por qué muchos están mal, aunque no lo parezca

Un SPF puede estar bien escrito, pasar cualquier comprobador y estar mal igualmente. Los fallos que más vemos no dan ningún error:

• Permisos que no autorizan a nadie que envíe. a autoriza la dirección de tu web, y mx, la de los servidores que reciben tu correo. Si tu web no envía correo por su cuenta, o tu correo entrante está en Google o en Microsoft, esos permisos autorizan servidores que nunca te han enviado nada, y gastan dos consultas de las diez.
• Herramientas que ya no usas. Cada herramienta que pasó por tu dominio dejó su include, y nadie lo quitó al dejarla. Su permiso sigue vivo: si mañana alguien envía desde esa plataforma con tu dominio en el sobre, tu SPF le da el visto bueno.
• Permisos que el asistente pide y no autentican. Algunas herramientas de newsletter piden su include para darte por verificado, aunque envían con su propio sobre. Ese permiso no autentica ni uno solo de tus correos. No hace daño, pero ocupa sitio y gasta consultas.
• Dos registros. Pasa al dar de alta una herramienta nueva: en vez de añadir su include al registro que ya había, se crea otro. Con dos, el SPF entero da error.
• El final equivocado. +all o ?all al final autorizan a cualquiera o no dicen nada. Los vemos poco, pero existen.

Ninguno de estos fallos hace que tus correos dejen de llegar mañana. Por eso duran años.

Cómo se pone en orden

1. Haz la lista de lo que envía con tu dominio. El correo de la empresa, la newsletter, la tienda, la facturación, los formularios de la web. Los informes de DMARC la confirman: ahí sale todo lo que envía con tu dominio, también lo que habías olvidado.
2. Para cada herramienta, mira con qué sobre envía. Si envía con tu dominio (Google Workspace, Microsoft 365, tu hosting, algunas herramientas transaccionales), su permiso va en tu SPF. Si envía con el suyo, lo que importa es que firme con tu dominio, y su include es opcional.
3. Quita lo que no se usa. Los a y mx que no envían, los includes de herramientas que dejaste. Antes de quitar un permiso, confirma en los informes que no ha autorizado ni un correo en las últimas semanas.
4. Un solo registro, con diez consultas como mucho. Si te pasas, lo primero es quitar lo que sobra. Si aun así no cabe, la salida es aplanar el registro, con alguien que lo mantenga al día, o dar a alguna herramienta su propio subdominio.
5. Termina en ~all o en -all. Para DMARC las dos cuentan como fallo. -all es más estricto con los buzones que solo miran el SPF, y es lo que recomienda Microsoft.

Lo que vemos en los dominios que vigilamos

Cifras de octubre de 2026. Las del registro están leídas en el DNS de los dominios que han pasado por nuestro diagnóstico. Las de uso, en los dominios que vigilamos, con los informes de DMARC de los últimos 30 días. Son proporciones, agregadas y anónimas.

• Casi todos tienen SPF, y muy pocos lo tienen roto. El 95 % de los dominios que diagnosticamos tiene SPF. Con dos registros, o por encima de las diez consultas, hay menos del 4 %. El problema no suele ser que falte, sino lo que lleva dentro.
• Los permisos a y mx sobran casi siempre. Algo más de uno de cada cuatro SPF de los dominios que diagnosticamos lleva un a o un mx. En los dominios que vigilamos, que llegaron en su mayoría con el correo en el hosting, tres de cada cuatro los traían, y de esos permisos, tres de cada cuatro no han autorizado ni un solo correo en 30 días.
• Lo que se trae, casi nunca se usa. De los permisos que los dominios traían en su SPF al empezar con nosotros, menos de uno de cada cuatro ha autorizado algún correo en los últimos 30 días. El resto son herramientas que se dejaron, direcciones sueltas de servidores que ya no envían y permisos puestos por si acaso.
• Permisos de herramientas que envían con su propio sobre. En algo más de la mitad de los dominios que vigilamos hay al menos un include de una herramienta de envío, casi siempre de newsletter, que nunca entra en juego, porque esa herramienta envía con su sobre y autentica con su firma. La mayoría están ahí porque el asistente de la herramienta los pidió.
• ~all gana por mucho. El 81 % de los SPF termina en ~all y el 13 %, en -all. Con DMARC en marcha, cualquiera de los dos sirve.