¿Qué es SPF y cómo funciona un registro SPF?

SPF es el más antiguo de los tres registros de autenticación del correo y el que la mayoría de los dominios ya tiene. Responde a una pregunta muy concreta: ¿puede este servidor enviar correo usando este dominio en el sobre? Esta guía explica cómo hacen esa comprobación los receptores, dónde deja de ser útil y cómo publicar un registro que funcione. También es el punto de partida de nuestras guías sobre SPF.

¿Qué es un registro SPF?

SPF son las siglas de Sender Policy Framework. Está definido en el RFC 7208, un documento de la categoría Standards Track de abril de 2014 que sustituyó al RFC 4408 experimental. En palabras del RFC, permite a los propietarios de dominios "autorizar a hosts a usar sus nombres de dominio en las identidades 'MAIL FROM' o 'HELO'".

El registro es un único registro TXT de DNS en el propio dominio:

example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -all"

• v=spf1 identifica el registro TXT como SPF. Los receptores descartan los registros TXT que no empiezan exactamente así.
• include: e ip4: son mecanismos: cada uno describe servidores que pueden enviar.
• -all es el comodín final. Fija el resultado para cualquier servidor que no esté en la lista.

La sección 3.1 del RFC 7208 indica que los registros SPF "DEBEN publicarse como registro de recurso DNS TXT (tipo 16)" únicamente. El tipo de registro SPF independiente de la fase experimental está retirado. Un dominio solo puede publicar un registro SPF; dos o más dan PermError (sección 4.5).

¿Cómo comprueba SPF un receptor?

SPF suele ejecutarse durante la conversación SMTP, antes de que llegue el cuerpo del mensaje; el RFC 7208 dice que la comprobación "DEBERÍA realizarse" en ese momento. En ese punto el servidor receptor conoce tres datos: la dirección IP que se ha conectado, el nombre que el servidor indicó en HELO/EHLO y el remitente del sobre en MAIL FROM.

1. Comprobar el nombre HELO (opcional). La sección 2.3 del RFC 7208 considera "RECOMENDADO" comprobar también la identidad HELO. Un resultado HELO concluyente puede ahorrar la comprobación MAIL FROM, más compleja.
2. Comprobar el dominio MAIL FROM. Los verificadores "DEBEN comprobar la identidad 'MAIL FROM'" si no se hizo la comprobación HELO o no fue concluyente (sección 2.4). En los rebotes, que tienen un MAIL FROM vacío, SPF usa en su lugar postmaster@ más el nombre HELO.
3. Obtener el registro TXT de ese dominio y quedarse con el que empieza por v=spf1.
4. Evaluar los mecanismos de izquierda a derecha. El primero que coincide con la IP que se conecta decide el resultado, según su calificador. No se lee nada de lo que viene después.
5. Registrar el resultado, normalmente en un encabezado Authentication-Results o Received-SPF, y aplicar la política local.

La función devuelve uno de siete resultados (sección 2.6):

El RFC 7208 deja deliberadamente el tratamiento en manos del receptor: "el protocolo no establece requisitos normativos para tratar ningún resultado concreto". Microsoft lo dice claramente sobre -all y ~all: "Lo que ocurre realmente con el mensaje depende del sistema de correo de destino".

¿Qué son los mecanismos y calificadores de SPF?

Los mecanismos comparan la IP que envía. Los más habituales son ip4, ip6, include, a, mx y all. Cada uno puede llevar un calificador: + pass (el valor por defecto), - fail, ~ softfail y ? neutral. Dos modificadores, redirect= y exp=, completan la sintaxis.

Todos los mecanismos, con ejemplos listos para copiar y los errores que vemos con más frecuencia, están en Sintaxis y ejemplos de registros SPF.

¿Cuáles son los límites de consultas de SPF?

SPF puede generar muchas consultas DNS, por eso el RFC 7208 las limita. La sección 4.6.4 fija tres límites:

• 10 términos que consultan el DNS. Cuentan los mecanismos include, a, mx, ptr y exists y el modificador redirect, incluidos los que hay dentro de los registros que incluyes. Las implementaciones "DEBEN limitar el número total de esos términos a 10", y superarlo "DEBE devolver 'permerror'".
• 2 consultas vacías. Una consulta que no devuelve registros, o un dominio que no existe, es una "consulta vacía" (void lookup). Las implementaciones "DEBERÍAN limitar las 'consultas vacías' a dos", y superar el límite produce PermError. La causa habitual es un include que apunta al dominio de un proveedor que ya no se usa.
• 10 registros de dirección por término mx o ptr. Un mecanismo mx cuyos hosts se resuelven en más de 10 consultas A o AAAA devuelve PermError.

ip4, ip6 y all no cuentan. Microsoft señala que tener menos de 10 instrucciones include "no garantiza menos de 10 consultas DNS", porque los include pueden anidarse (Microsoft Learn).

Este límite también afecta a grandes organizaciones. En nuestro análisis de octubre de 2026 de los 1.000 primeros dominios de Tranco, 22 dominios publicaban un registro SPF que superaba el límite de 10 consultas y 4 publicaban más de un registro SPF. Nuestra guía sobre SPF PermError: demasiadas consultas DNS explica cómo contar y reducir las consultas.

¿Qué no hace SPF?

SPF es útil, pero limitado. Conoce sus puntos ciegos antes de confiar en él.

No comprueba la dirección From

SPF autentica el dominio MAIL FROM (y, opcionalmente, HELO). La línea From: que la gente lee en su cliente de correo es otro encabezado y puede indicar cualquier dominio. Un spammer puede pasar SPF para attacker.example mientras muestra tu dominio en From. Relacionar ambos es tarea de DMARC.

Falla cuando el correo se reenvía

Cuando un mensaje se reenvía, llega desde la IP del reenviador, que no está en tu registro. La sección 7.4 del RFC 9989 dice que ese correo "muy probablemente fallará las comprobaciones SPF" salvo que el reenviador reescriba la dirección MAIL FROM, mientras que "las firmas DKIM normalmente seguirán siendo válidas". El apéndice D del RFC 7208 describe las soluciones basadas en reescritura. Nuestra guía sobre por qué el reenvío rompe SPF y DMARC trata SRS y ARC.

No cubre los subdominios

SPF se comprueba para el dominio exacto del MAIL FROM. news.example.com necesita su propio registro; no hereda el de example.com. Microsoft indica que cada subdominio que envía correo "necesita su propio registro TXT de SPF".

No dice nada del contenido

Un mensaje enviado desde un servidor autorizado puede seguir siendo spam o phishing. SPF solo demuestra de dónde viene el mensaje, no si es deseado.

¿Cómo funciona SPF con DMARC?

El RFC 9989, el estándar DMARC vigente, usa SPF como una de sus dos entradas. Es explícito sobre la identidad: "DMARC se basa únicamente en la validación SPF de la identidad MAIL FROM". Los resultados HELO no cuentan.

Un pass de SPF solo ayuda a DMARC cuando el dominio MAIL FROM está alineado con el dominio From. En el modo relajado por defecto, bounce.example.com está alineado con example.com; mailer-vendor.net no. El RFC 9989 explica por qué hace falta la alineación: "cualquier propietario de dominio, incluso uno malintencionado, puede publicar un registro SPF para su dominio y enviar un correo que obtenga un resultado SPF 'pass'".

Esta es la sorpresa más habitual con los remitentes externos. Muchas herramientas de boletines, CRM y helpdesk usan por defecto su propio dominio de rebote. SPF da pass, pero para su dominio, así que no cuenta para tu resultado DMARC. La solución es un return-path personalizado (a menudo llamado MAIL FROM personalizado o dominio de rebote) en un subdominio tuyo, o DKIM alineado. Nuestra guía sobre por qué falla DMARC repasa los casos.

Para DMARC, fail, softfail, neutral, none y permerror son lo mismo: no hay un pass de SPF alineado. En ese caso, todo depende de DKIM. Consulta qué es DMARC y cómo funciona, y SPF, DKIM y DMARC: diferencias para saber qué demuestra cada registro.

¿Un registro SPF debe terminar en ~all o en -all?

Ambas opciones son defendibles para un dominio que envía correo, y las fuentes no coinciden:

El motivo de la cautela está en la sección 7.1 del RFC 9989: algunos receptores comprueban SPF pronto, así que un fallo con -all "podría hacer que un mensaje se rechace al principio de la transacción SMTP, antes de que se realice cualquier procesamiento DMARC", aunque un DKIM alineado lo habría aprobado.

Una opción razonable por defecto: usa ~all mientras sigues identificando a todos tus remitentes y plantéate -all cuando DKIM esté activo en todos los servicios y los informes DMARC estén limpios. Para un dominio que nunca envía correo, publica v=spf1 -all; tanto Microsoft como M3AAWG lo recomiendan para dominios aparcados. No uses nunca +all y no dejes ?all en producción. La comparación completa está en SPF softfail frente a hardfail.

¿Cómo creo un registro SPF?

1. Enumera todos los servicios que envían en nombre de tu dominio: tu plataforma de correo, tu web y sus formularios, el CRM, el helpdesk y las herramientas de facturación y de boletines. Las directrices para remitentes de Google exigen SPF o DKIM a todo el que envía a Gmail.
2. Obtén el valor documentado de cada proveedor. Nuestras páginas de registros SPF por proveedor de correo muestran el include exacto de servicios habituales, como Microsoft 365 y Google Workspace, con el número de consultas que consumen, medido por nosotros.
3. Pasa los envíos masivos a un subdominio siempre que puedas. Microsoft lo recomienda para los servicios que no controlas directamente, y el subdominio tiene su propio margen de 10 consultas.
4. Crea un único registro. El SPF Record Generator (generador de registros SPF) lo construye a partir de tus servicios y cuenta las consultas.
5. Publícalo o edítalo en tu proveedor de DNS. Sustituye el registro existente; no añadas nunca un segundo registro v=spf1.
6. Compruébalo con el SPF Checker (verificador de SPF): sintaxis, número de consultas y terminación all.
7. Prueba con correo real. Envía desde cada servicio a un buzón externo y busca spf=pass en los encabezados con el Email Header Analyzer (analizador de encabezados de correo).
8. Añade DKIM y DMARC. SPF por sí solo no protege la dirección From.

Nuestras guías sobre SPF

Próximos pasos

1. Analiza tu dominio con el SPF Checker para ver tu registro, su número de consultas y su terminación all.
2. Si falta algo o algo está roto, vuelve a crear el registro con el SPF Record Generator y sustituye el antiguo.
3. Publica v=spf1 -all en todos tus dominios que no envían correo.
4. Configura DKIM en cada servicio de envío y después publica DMARC; empieza por qué es DMARC.
5. Obtén una visión completa de una vez con el Email Health Check (revisión de salud del correo). Si quieres saber cuándo alguien cambia tu registro SPF, la monitorización del dominio de iBlockSpam envía alertas de cambios.

Los registros SPF suelen romperse cuando alguien añade un servicio meses después. Free Domain Watch (vigilancia gratuita del dominio) comprueba cada semana tus registros públicos SPF, MX, DMARC y MTA-STS y te avisa por correo cuando alguno cambia; no necesita cuenta.

Consulta nuestras otras guías sobre SPF, DKIM y DMARC.