SPF — Marco de Política del Remitente

Internet Standard Email Authentication Obsoletes RFC 4408 Published March 2026

ELI5: Imagina que tu empresa tiene papel de carta oficial. SPF es como publicar una lista de impresoras autorizadas para imprimir en tu papel de carta. Cuando alguien recibe una carta que dice ser de ti, pueden verificar si proviene de una de tus impresoras aprobadas. Si no es así, saben que probablemente es una falsificación.

Por qué existe este RFC

SMTP fue diseñado a principios de los años 80 sin verificación integrada del remitente. Cualquier servidor puede afirmar que envía correo desde cualquier dominio — no hay nada en el protocolo base que lo impida. Esto hizo que la suplantación de correo electrónico fuera trivial: los spammers y phishers podían falsificar la dirección del remitente para hacerse pasar por bancos, colegas o cualquier marca de confianza.

SPF (Marco de Política del Remitente), estandarizado en RFC 7208, lo resuelve permitiendo que los propietarios de dominios publiquen un registro TXT de DNS que enumera explícitamente qué direcciones IP y servidores están autorizados para enviar correo electrónico desde su dominio. Los servidores de correo receptores consultan este registro durante la transacción SMTP y pueden rechazar o marcar mensajes de fuentes no autorizadas.

RFC 7208 obsoletó el anterior RFC 4408 experimental, promocionando SPF a un Estándar de Internet completo con reglas de procesamiento clarificadas y requisitos más estrictos para límites de búsqueda DNS.

Cómo funciona

SPF opera a nivel de sobre, no a nivel de encabezado de mensaje. El dominio verificado es el del comando MAIL FROM (también llamado Return-Path o remitente de sobre), no el encabezado From: que ven los usuarios.

Flujo de verificación SPF

Un servidor emisor se conecta al receptor y emite MAIL FROM:<user@example.com>.
El receptor extrae el dominio example.com del remitente de sobre.
El receptor consulta DNS para un registro TXT en example.com que comience con v=spf1.
El receptor evalúa los mecanismos del registro SPF contra la dirección IP de conexión.
El resultado es uno de: pass, fail, softfail, neutral, none, temperror o permerror.

Ejemplo de transacción SMTP

# Servidor emisor 198.51.100.25 se conecta
S: 220 mx.receiver.com ESMTP ready
C: EHLO mail.example.com
S: 250-mx.receiver.com Hello
S: 250 OK
C: MAIL FROM:<alice@example.com>
# El receptor ahora verifica: ¿autoriza el registro SPF de example.com a 198.51.100.25?
# Búsqueda DNS: example.com TXT "v=spf1 ip4:198.51.100.0/24 -all"
# 198.51.100.25 coincide con ip4:198.51.100.0/24 => resultado: pass
S: 250 OK
C: RCPT TO:<bob@receiver.com>
S: 250 OK

Detalles técnicos clave

Sintaxis de registro SPF

Un registro SPF es un registro TXT de DNS que comienza con la etiqueta de versión v=spf1 seguida de una serie de mecanismos y un calificador opcional para cada uno. El registro se evalúa de izquierda a derecha; el primer mecanismo que coincide determina el resultado.

example.com. IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/32 include:_spf.mailertogo.com include:_spf.google.com -all"

Mecanismos

Mecanismo	Descripción
`ip4:<range>`	Coincide si la IP del remitente está dentro del rango CIDR IPv4 dado.
`ip6:<range>`	Coincide si la IP del remitente está dentro del rango CIDR IPv6 dado.
`a`	Coincide si la IP del remitente es igual a un registro A/AAAA del dominio.
`mx`	Coincide si la IP del remitente es igual a un registro A/AAAA de uno de los hosts MX del dominio.
`include:<domain>`	Evalúa recursivamente el registro SPF de otro dominio. Un `pass` del dominio incluido cuenta como una coincidencia.
`exists:<domain>`	Coincide si existe un registro A de DNS para el dominio dado (usado para macros avanzadas).
`redirect=<domain>`	Modificador: reemplaza completamente la verificación SPF actual con el registro de otro dominio.
`all`	Coincide con todo. Típicamente se usa al final del registro como `-all` o `~all`.

Calificadores

Calificador	Resultado	Significado
`+` (predeterminado)	pass	Remitente autorizado
`-`	fail	No autorizado — rechazar el mensaje
`~`	softfail	Probablemente no autorizado — aceptar pero marcar
`?`	neutral	Sin aseveración realizada

Límite de 10 búsquedas

Para prevenir abuso de DNS, RFC 7208 ordena que la evaluación de SPF no requiera más de 10 búsquedas DNS que resulten en resolución de mecanismo. Los mecanismos que activan búsquedas son: include, a, mx, exists, redirect y ptr (deprecado). Los mecanismos raw ip4 e ip6 no cuentan. Exceder 10 búsquedas produce un resultado permerror, lo que típicamente significa sin protección SPF.

Límite de búsqueda MX

Además, el mecanismo mx no debe resultar en más de 10 nombres MX para consultar, y cada uno de esos no debe resolverse en más de 10 direcciones A/AAAA. El mecanismo ptr está explícitamente desaconsejado.

Expansión de macros

SPF soporta macros que se expanden a valores específicos del contexto durante la evaluación. Los macros comunes incluyen %{s} (remitente), %{l} (parte local), %{d} (dominio) e %{i} (dirección IP). Se usan principalmente en mecanismos exists: para políticas complejas por usuario o por IP.

Ejemplos de registros DNS

Básico: Rango IP único

example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Típico: ESP de terceros + Google Workspace

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com include:_spf.google.com -all"

Dominio que no envía correo electrónico

parked-domain.com. IN TXT "v=spf1 -all"

Usando redirect

subdomain.example.com. IN TXT "v=spf1 redirect=example.com"

Errores comunes

Múltiples registros SPF: Un dominio debe tener exactamente un registro TXT SPF. Publicar dos causa un permerror. Si necesitas combinar fuentes, fusiónalas en un solo registro.
Exceder el límite de 10 búsquedas: Cada include: cuenta como una búsqueda, y los propios mecanismos del registro incluido cuentan hacia el total. Cadenas de includes de múltiples ESPs rápidamente agotan el límite. Aplana tu registro o usa subdominios.
Usar ~all en lugar de -all: Softfail (~all) le dice a los receptores que el mensaje es sospechoso pero que no lo rechacen. Para protección fuerte (y para habilitar cumplimiento de DMARC), usa -all.
Olvidar el dominio Return-Path: SPF verifica el remitente de sobre, no el encabezado From:. Si tu ESP usa su propio dominio Return-Path, el registro SPF de tu dominio es irrelevante para las verificaciones SPF. Necesitas alineación personalizada de Return-Path o DKIM + DMARC.
Usar el mecanismo deprecado ptr: RFC 7208 explícitamente desaconseja ptr porque es lento, no confiable y coloca carga en la infraestructura de DNS inverso.
Usar registros de tipo SPF (99): El tipo de registro DNS SPF dedicado fue definido en RFC 4408 pero deprecado en RFC 7208. Siempre usa registros TXT.

Impacto en la entregabilidad

SPF es uno de los tres pilares de la autenticación de correo electrónico (junto con DKIM y DMARC). Su impacto en la entregabilidad es significativo:

Requerido por proveedores principales: Gmail, Yahoo, Microsoft y Apple evalúan SPF. Desde febrero de 2024, Gmail y Yahoo requieren SPF o DKIM para pasar para todos los remitentes, y ambos para pasar para remitentes en masa.
Alineación DMARC: SPF se vuelve mucho más poderoso cuando se combina con DMARC, que verifica que el dominio autenticado por SPF se alinee con el dominio del encabezado From:. Sin DMARC, SPF solo no puede prevenir la suplantación del encabezado From.
El reenvío rompe SPF: Cuando un mensaje se reenvía a través de una lista de correo o regla .forward, la IP de envío cambia pero el remitente de sobre a menudo se mantiene igual. Esto causa que SPF falle para correo legítimo. Esta es una razón por la que existen DKIM y ARC.
Señal de reputación: Un registro SPF correctamente configurado (con -all) señala a los receptores que tomas en serio la seguridad del correo electrónico y dificulta que los malos actores abusen de tu dominio.