Registro SPF: qué es y para qué sirve

Dicho de otra forma: es la lista del personal autorizado a acceder a la zona de embarque de un aeropuerto. Si alguien se presenta diciendo que trabaja allí y no está en la lista, en el control lo saben. El SPF no comprueba lo que dice el mensaje ni quién lo firma —de eso se ocupa DKIM—: solo si el sistema que lo ha enviado tenía permiso para hacerlo.

Qué pasa exactamente cuando alguien recibe un correo tuyo

Todo correo lleva dos direcciones de remitente: la del sobre, que es la que se usa para devolver los rebotes, y la del «De», que es la única que ve tu cliente. Pueden ser distintas, y el SPF solo se ocupa de la primera.

A partir de ahí son dos comprobaciones, en este orden:

1. El servidor que recibe el mensaje mira la dirección del sobre y extrae el registro SPF del dominio de esa dirección.
2. Comprueba si la IP del servidor que le ha entregado el mensaje figura entre las autorizadas en ese registro.

Si figura, el mensaje pasa la verificación. Si no, lo que ocurra después depende de cómo termine tu registro.

Y esa diferencia entre las dos direcciones tiene una consecuencia que sorprende a mucha gente: un correo puede pasar el SPF perfectamente y aun así mostrar en pantalla un nombre que no le corresponde. Para eso existe DMARC, que comprueba que las dos direcciones coincidan.

Qué aspecto tiene un registro SPF

Es un registro de tipo TXT en tu DNS. Empieza siempre por v=spf1 —si no empieza exactamente así, se descarta— y conviene terminarlo con una instrucción sobre qué hacer con lo que no esté en la lista:

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

Entre el principio y el final van los mecanismos. La especificación define ocho, pero en la práctica se usan sobre todo estos tres:

Los otros cinco son a, mx, ptr, ip6 y exists. El ptr la propia especificación desaconseja publicarlo: es lento, poco fiable cuando hay errores de DNS y existen alternativas mejores.

Y si no pones nada al final, no es que no haya norma: el registro se comporta como si terminara en ?all, es decir, sin pronunciarse. Por eso conviene cerrarlo de forma explícita.

Cada sistema que envíe en tu nombre tiene su propia declaración de inclusión, y la publica su proveedor. Conviene cogerla siempre de su documentación en el momento de configurarla, nunca de una lista copiada de otro sitio: las cambian, y una inclusión desactualizada deja de autorizar lo que debería.

De hecho, cada vez más plataformas ya no te piden que añadas una inclusión: te dan otros registros y firman con su propio dominio de retorno. Eso cambia cómo se comprueba la autenticación, y es una de las razones por las que un dominio puede tener el SPF impecable y aun así fallar la alineación.

Y una cosa que casi ninguna guía menciona: cada subdominio que envíe correo necesita su propio registro. El del dominio principal se publica con el nombre @; el de un subdominio, con el nombre del subdominio.

Qué significa el final del registro SPF

Si has llegado aquí buscando qué es un softfail o un SPF fail, es porque lo has visto en un mensaje de rebote. Softfail significa que el correo salió de un sistema que no está en tu lista y el destinatario ha decidido dejarlo pasar con desconfianza. Fail significa que lo ha rechazado.

Y si el rebote dice does not designate as permitted sender, es exactamente eso: el sistema desde el que se envió no aparece en el registro SPF del dominio.

Un dominio solo puede tener un registro SPF

Uno. No dos, no tres. Si un dominio publica más de un registro que empiece por v=spf1, el servidor que lo evalúa no puede decidir cuál vale y devuelve permerror: el dominio queda exactamente igual que si no tuviera ninguno.

Es el fallo más habitual al cambiar de herramienta de envío, porque se añade el registro de la nueva sin quitar el de la anterior. Dos registros no suman: se anulan. Cuando hay que autorizar a varios proveedores, todos van dentro del mismo registro, uno detrás de otro.

El límite de las diez consultas

Cada include: obliga al servidor que recibe el mensaje a hacer una consulta de DNS. La especificación del SPF fija el máximo en diez. Superado ese número, el servidor deja de evaluar y devuelve un permerror.

Tres cosas que conviene saber sobre ese límite, porque es donde se rompen la mayoría de los registros:

• Cuentan include:, a, mx, ptr, exists y el modificador redirect. No cuentan ip4:, ip6: ni all.
• Es acumulativo. No son diez consultas en tu registro y otras diez dentro de cada inclusión: son diez en total, contando todo lo que haya dentro de las inclusiones de tus proveedores. Por eso se puede pasar de diez con solo cuatro o cinco include: a la vista.
• permerror no es lo mismo que fail. Un fail significa que el registro se evaluó y el sistema emisor no estaba autorizado. Un permerror significa que no se pudo evaluar el registro en absoluto. Qué hace el destinatario con ese mensaje depende de su política, pero en la práctica se queda sin la señal de autenticación. Y no avisa: en el DNS todo sigue viéndose bien.

Fíjate en que las dos averías de esta ficha —dos registros y pasarse de diez consultas— acaban en el mismo sitio: permerror. Un dominio que parece bien configurado y que en la práctica no está autenticado.

Hay un segundo límite menos conocido: las consultas vacías —las que no devuelven ningún resultado— están limitadas a dos. Un include: que apunte a un dominio que ya no existe cuenta como una.

El límite se llena antes de lo que parece, porque se acumulan inclusiones de sistemas que ya no se usan. Es de lo que más me encuentro al revisar dominios: el webmail del hosting, la plataforma de envío anterior, la herramienta que se probó y se descartó. Nadie las quita, y cada una sigue gastando una consulta.

Preguntas frecuentes

¿Por qué mis correos llegan a Gmail pero no a Outlook?

Porque Microsoft es más estricto con la autenticación que Google. Desde mayo de 2025, Outlook exige SPF, DKIM y DMARC a todo dominio que envíe más de 5.000 correos al día: primero manda los mensajes no conformes a la carpeta de no deseados y, si el problema no se resuelve, los rechaza con el error 550 5.7.515 Access denied. Un mismo registro SPF mal puesto puede pasar desapercibido en Gmail y bloquearte entero en Outlook.

Mi SPF pasa, pero DMARC dice que no está alineado. ¿Por qué?

Son dos comprobaciones distintas. La primera mira si el registro SPF existe y autoriza al servidor que ha enviado: eso puede pasar sin problema. La segunda mira si el dominio del sobre coincide con el dominio del «De», y ahí es donde falla. Ocurre casi siempre con herramientas de email marketing: el sobre sale con un dominio de la plataforma y el «De» lleva el tuyo. Para alinearlo hay que configurar un dominio de retorno propio, y no todas las plataformas lo permiten en sus planes básicos.

¿Puedo tener dos registros SPF?

No. Un dominio solo puede tener uno. Si hay dos, la verificación devuelve un permerror y el dominio queda como si no tuviera ninguno. Cuando hay que autorizar a varias herramientas, se combinan todas dentro del mismo registro.

¿~all o -all?

-all protege más, pero rechaza sin contemplaciones: si te falta una herramienta por incluir, sus correos desaparecen. ~all es la terminación con la que conviene empezar, y se pasa a -all cuando se tiene la certeza de que todos los remitentes legítimos están dentro.

¿Un registro SPF correcto garantiza que mis correos lleguen a la bandeja de entrada?

No. Garantiza que se puede verificar desde dónde salen. Lo dice la propia documentación de Microsoft: autenticar no garantiza la entrega, pero evita que tus correos vayan a no deseados por el simple hecho de no estar autenticados. Llegar a la bandeja depende además de la reputación del dominio, del comportamiento de tus suscriptores y del historial de envíos.