Skip to main content
New AI-powered DMARC analysis + open REST API See how → →
Autenticación de correo

¿Qué es
SPF?

SPF (Sender Policy Framework) es un protocolo de autenticación de correo basado en DNS que permite a los propietarios de dominios publicar qué direcciones IP y servidores están autorizados para enviar correo en su nombre - e indica a los receptores que rechacen todo lo demás.

Cómo funciona

Autorización de remitente basada en IP en tres pasos

SPF le permite declarar qué servidores están autorizados para enviar correo para su dominio. Los receptores verifican cada mensaje entrante contra su lista publicada.

01

El remitente envía

Un servidor de correo inicia una conexión SMTP para entregar un mensaje que afirma ser de su dominio. La dirección IP del servidor que se conecta es registrada por el servidor receptor.

02

El receptor verifica SPF

El servidor receptor consulta DNS para el registro SPF TXT de su dominio. Obtiene la lista de direcciones IP autorizadas, includes y mecanismos que usted ha publicado.

03

Aprobado o fallido

La IP que se conecta se compara con el registro SPF. Si coincide con un mecanismo autorizado, el resultado es Pass. Si no, el resultado depende de su calificador all: fallo duro, fallo suave o neutral.

Anatomía del registro

Cómo se ve un registro
SPF en DNS

Un registro SPF es un único registro DNS TXT publicado en la raíz de su dominio. Comienza con v=spf1 y lista cada remitente autorizado usando mecanismos como include:, ip4:, y termina con un calificador all.

  • Un dominio puede tener exactamente un registro SPF (múltiples registros causan PermError)
  • El registro debe comenzar con v=spf1 como el primer mecanismo
  • Cada mecanismo include: cuesta 1+ consultas DNS hacia el límite de 10
  • Los mecanismos ip4: e ip6: no cuentan como consultas DNS
  • El mecanismo all debe ser el último y define la acción predeterminada
Registro DNS TXT
ejemplo.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"
v=spf1
Versión
Requerido. Debe ser el primer token. Identifica esto como un registro SPF.
include:
Delegar
Obtiene el registro SPF de otro dominio. Cuesta 1+ consulta DNS.
ip4:
Dirección IP
Autoriza una dirección IPv4 específica o rango CIDR. Cero consultas DNS.
-all
Fallo duro
Rechazar todos los remitentes no coincidentes con los mecanismos anteriores.
Contador de consultas SPF
include:_spf.google.com
+3 3/10
include:sendgrid.net
+2 5/10
include:spf.mailchimp.com
+2 7/10
include:spf.hubspot.com
+2 9/10
include:spf.freshdesk.com
+2 11/10
PermError: Se excedieron 10 consultas DNS - todo el correo de este dominio falla SPF
El límite de 10 consultas

Por qué SPF se rompe en
10 consultas DNS

La sección 4.6.4 del RFC 7208 limita la evaluación SPF a 10 consultas DNS de mecanismos. Esto evita que los registros SPF se usen como un vector de amplificación DNS. Cada mecanismo include, a, mx, redirect y exists desencadena una consulta DNS. Las organizaciones que usan 4-5 servicios de correo comúnmente exceden este límite.

La solución: Aplanamiento SPF

El aplanamiento SPF reemplaza los mecanismos include: con direcciones IP resueltas, eliminando las consultas DNS. AutoSPF - nuestro producto hermano - maneja el aplanamiento automáticamente y re-escanea cada 15 minutos para captar cambios de IP de proveedores.

Mecanismos SPF

Los bloques de construcción de un registro SPF

Cada mecanismo define una regla para coincidir direcciones IP de remitentes. Los mecanismos se evalúan de izquierda a derecha hasta que se encuentra una coincidencia.

ip4 / ip6

Autoriza direcciones IPv4 o IPv6 específicas o rangos CIDR. No cuenta hacia el límite de 10 consultas porque no se necesita consulta DNS.

ip4:203.0.113.0/24
include

Delega la autorización al registro SPF de otro dominio. El receptor obtiene y evalúa ese registro. Cada include cuesta 1+ consultas DNS.

include:_spf.google.com
a

Autoriza las direcciones IP devueltas por el registro A o AAAA del dominio especificado. Cuesta 1 consulta DNS.

a:mail.ejemplo.com
mx

Autoriza las direcciones IP de los servidores MX (intercambio de correo) del dominio. Cuesta 1 consulta DNS más consultas adicionales para la resolución MX.

mx
redirect

Reemplaza el registro SPF actual completamente con el registro de otro dominio. Se usa cuando la política de envío de un dominio es idéntica a otra.

redirect=_spf.ejemplo.com
all

Coincide con cada IP no capturada por los mecanismos anteriores. Siempre aparece último. El calificador (+, -, ~, ?) determina qué sucede con los remitentes no coincidentes.

-all
Calificadores SPF

Qué significan +, -, ~ y ? para la entrega

Los calificadores prefijan cualquier mecanismo para controlar el resultado cuando ese mecanismo coincide. El calificador en su mecanismo all es el más importante - define qué sucede con cada remitente no listado.

+
Pass

La IP está autorizada. Este es el calificador predeterminado si no se especifica ninguno. Raramente se escribe explícitamente.

+all (igual que all)
-
Fallo duro

La IP NO está autorizada. Los receptores deben rechazar el mensaje. Señal de aplicación más fuerte.

-all
~
Fallo suave

La IP probablemente no está autorizada. Los receptores deben aceptar pero marcar como sospechoso. Seguro para el despliegue inicial.

~all
?
Neutral

Sin afirmación sobre la IP. El resultado SPF no proporciona información. Raramente usado en la práctica.

?all
Solución de problemas

Problemas comunes de SPF y cómo solucionarlos

La mayoría de los fallos SPF provienen de límites de consultas, remitentes faltantes o errores de configuración que son fáciles de detectar con las herramientas adecuadas.

Demasiadas consultas DNS

Su registro SPF excede el límite de 10 consultas del RFC 7208. Cada include, a, mx, redirect y exists cuenta. Use aplanamiento SPF o AutoSPF para resolver IPs estáticamente.

Fuentes de envío faltantes

Un servicio de correo legítimo no está listado en su registro SPF. Común después de agregar nuevos servicios como herramientas de marketing, CRMs o mesas de soporte. Revise los informes DMARC agregados para encontrar remitentes que fallan SPF.

Límite de consultas vacías

El RFC 7208 también limita las consultas vacías (NXDOMAIN o respuestas vacías) a 2. Los dominios include obsoletos que ya no resuelven causan consultas vacías y pueden desencadenar PermError incluso por debajo de 10 consultas totales.

Múltiples registros SPF

Un dominio debe tener exactamente un registro SPF TXT. Múltiples registros causan un PermError. Consolide todos los remitentes autorizados en un único registro que comience con v=spf1.

Uso del mecanismo ptr

El mecanismo ptr está obsoleto en el RFC 7208 porque es lento, poco confiable y coloca una carga excesiva en DNS. Algunos receptores lo ignoran completamente. Reemplácelo con mecanismos ip4/ip6 o include.

+all demasiado permisivo

Usar +all autoriza cada dirección IP en internet para enviar como su dominio, anulando todo el propósito de SPF. Siempre use -all (fallo duro) o ~all (fallo suave) como el mecanismo final.

FAQ

Preguntas frecuentes sobre SPF

¿Qué es SPF?

SPF (Sender Policy Framework) es un protocolo de autenticación de correo basado en DNS definido en RFC 7208 que permite a un propietario de dominio publicar qué direcciones IP y servidores están autorizados para enviar correo en nombre de ese dominio. Los servidores de correo receptores verifican la IP del remitente contra el registro SPF publicado y rechazan o marcan mensajes de fuentes no autorizadas. SPF es uno de los tres protocolos fundamentales de autenticación de correo junto con DKIM y DMARC.

¿Cómo se ve un registro SPF?

Un registro SPF es un registro DNS TXT publicado en el dominio raíz. Un registro típico se ve así: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all. La etiqueta v=spf1 es requerida y debe ir primero. Los mecanismos include delegan la autorización a otro dominio. Los mecanismos ip4 e ip6 autorizan direcciones IP específicas. El mecanismo all al final define la política predeterminada para remitentes no listados: -all significa fallo duro, ~all significa fallo suave.

¿Por qué SPF tiene un límite de 10 consultas?

La sección 4.6.4 del RFC 7208 limita la evaluación SPF a 10 consultas DNS de mecanismos para evitar que los registros SPF se conviertan en un vector de amplificación DNS. Cada mecanismo include, a, mx, redirect y exists desencadena una consulta DNS que cuenta hacia el límite. Cuando las organizaciones usan múltiples servicios de correo (Google Workspace, SendGrid, Mailchimp, CRM, mesa de soporte), las consultas combinadas de includes anidados fácilmente exceden 10. Exceder el límite produce un PermError que falla la autenticación para cada mensaje del dominio.

¿Qué sucede cuando se excede el límite de 10 consultas SPF?

Cuando un registro SPF excede 10 consultas DNS de mecanismos, el servidor receptor devuelve un resultado PermError. PermError significa que el registro SPF no pudo ser evaluado, y la mayoría de los receptores lo tratan como un fallo. Esto afecta a todos los correos enviados desde el dominio, no solo a los mensajes del remitente que causó el desbordamiento. La solución es el aplanamiento SPF (reemplazar mecanismos include con direcciones IP resueltas) o macros SPF. AutoSPF, el producto hermano de DMARC Report en autospf.com, maneja ambos enfoques y re-escanea cada 15 minutos.

¿Cuál es la diferencia entre -all y ~all en SPF?

El calificador -all (fallo duro) instruye a los servidores receptores a rechazar el correo de cualquier dirección IP no listada explícitamente en el registro SPF. El calificador ~all (fallo suave) instruye a los receptores a aceptar el mensaje pero marcarlo como sospechoso. En la práctica, muchos receptores tratan ambos de manera similar debido a la aplicación de DMARC, pero -all proporciona la señal más fuerte. Use ~all durante el despliegue inicial de SPF por seguridad, luego cambie a -all una vez que todos los remitentes legítimos estén contabilizados.

¿SPF funciona con el reenvío de correo?

No. SPF se rompe cuando el correo se reenvía porque la dirección IP del servidor de reenvío no está en el registro SPF del dominio original. El reenviador retransmite el mensaje desde su propia IP, que el servidor receptor verifica contra el registro SPF del dominio original y falla. Esta es una de las principales razones por las que DKIM existe: las firmas DKIM están adjuntas al mensaje mismo y sobreviven al reenvío. DMARC requiere que solo SPF o DKIM pasen y se alineen, por lo que DKIM cubre la brecha del reenvío.

¿Cómo verifico mi registro SPF?

Use la herramienta SPF Checker de DMARC Report en dmarcreport.com/tools/spf-checker/ para consultar su registro SPF, contar consultas DNS, verificar errores de sintaxis y verificar que todas sus fuentes de envío estén incluidas. La herramienta resuelve todos los mecanismos include recursivamente y muestra la lista completa de direcciones IP que su registro SPF autoriza. También puede usar nslookup o dig desde la línea de comandos: dig TXT ejemplo.com devolverá su registro SPF.

Verifique su registro SPF ahora

Use nuestro SPF Checker gratuito para contar consultas DNS, detectar remitentes faltantes y verificar la sintaxis de su registro. Resultados en segundos.

Verificar registro SPF

Lo que dicen los equipos de seguridad sobre la supervisión SPF

G2 Leader - DMARC

Rated 4.8/5 on G2 · 469 verified reviews

G2 Momentum Leader - DMARC
VU

Verified User in Information Technology and Services

5/5

"Best security tool for your own domains"

The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.

8/31/2022 Verified on G2
RC

Ryan C.

Director

4.5/5

"Control Centre for Email Security"

I like that we can see and check all reports on just 1 platform. We manage multiple domains, and monitoring them all in one place is essential.

8/29/2022 Verified on G2
eg

eddy g.

Director

4.5/5

"A great solution to a common email problem."

I have been using them for the last month after my Google business email started giving DMARC errors. I didn't even know what it meant at that time. After a little googling I found that people can spoof it as well. So far so good — the best thing is it protects every email.

8/29/2022 Verified on G2