Comprobador gratuito de registros SPF

Qué es SPF y por qué importa en 2026

Sender Policy Framework (SPF) es uno de los tres pilares de la autenticación moderna de correo, junto con DKIM y DMARC. Definido en la RFC 7208, permite al dueño del dominio publicar en DNS una lista de servidores autorizados para enviar, de modo que los proveedores receptores puedan verificar que los mensajes entrantes vienen realmente de donde dicen. Sin SPF, cualquiera puede enviar correo haciéndose pasar por tu dominio — y proveedores como Gmail y Yahoo dejarán caer en silencio el correo no autenticado directo a spam.

En 2026, SPF ya no es opcional. Los requisitos para remitentes masivos de Gmail y Yahoo (lanzados en 2024 y endurecidos desde entonces) obligan a tener SPF y DKIM en cualquier dominio que envíe más de 5.000 mensajes al día. Microsoft 365 y Apple Mail aplican estándares parecidos. Un SPF mal configurado o ausente se traduce hoy directamente en spam, ingresos perdidos y daño de marca. La buena noticia: SPF es una de las victorias de entregabilidad más baratas y rápidas — un único registro TXT bien configurado puede subir la entrega a bandeja entre un 20 y un 40 % de un día para otro.

Anatomía de un registro SPF

Cada registro SPF es un único registro DNS TXT con mecanismos separados por espacios. Este es un ejemplo típico para un dominio que usa Google Workspace y Mailgun:

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

• v=spf1 — la etiqueta de versión. Todo registro SPF debe empezar así. No existe v=spf2; el protocolo no ha cambiado en más de una década.
• ip4: / ip6: — ip4: y ip6: — direcciones IP o rangos CIDR explícitamente permitidos. ip4:203.0.113.0/24 autoriza una subred entera. Son los mecanismos más baratos porque cuestan cero lookups DNS.
• include: — incluye el registro SPF de otro dominio. include:_spf.google.com indica a los receptores que también acepten correo de cualquier servidor que Google autorice para sus tenants. Cada include cuenta como un lookup DNS, y los includes anidados también cuentan.
• a / mx — a y mx — autorizan las IPs del registro A del dominio (el servidor del sitio web) o de los registros MX (los servidores de correo entrante). Úsalos con cuidado: muchos dominios tienen servidores web que no deberían enviar correo.
• Los cualificadores controlan el resultado. ~all (soft fail) marca el correo no coincidente como sospechoso pero lo acepta — útil mientras pruebas. -all (hard fail) rechaza directamente el correo no coincidente — el ajuste recomendado en producción. ?all (neutral) no hace nada y es inútil. +all autoriza explícitamente cada IP de Internet — no lo uses nunca; es el equivalente a dejar la puerta de casa abierta con un cartel que dice "por favor, suplántame".

5 errores comunes de SPF y cómo arreglarlos

Demasiados lookups DNS (límite RFC 7208: 10)

SPF permite un máximo de 10 lookups DNS por evaluación. Cada include:, a:, mx:, exists: y redirect= cuenta. Los includes anidados también — si include:_spf.google.com contiene cuatro includes, son cinco lookups solo para ese mecanismo. Superar el límite dispara un PermError y la mayoría de receptores lo tratan como fallo duro. Solución: audita cada include con nuestro SPF checker, retira proveedores que ya no usas, sustituye include: por bloques ip4: cuando el proveedor publique rangos estáticos, o usa un servicio de flattening.

PermError: sintaxis de SPF inválida

Errores típicos: falta el prefijo v=spf1, usar punto y coma en vez de espacios, dejar caracteres sueltos del copia-pega o poner el cualificador (~all) en medio del registro en vez de al final. Los receptores lo ven como fallo de configuración y SPF cae sin más. Solución: pega el registro exacto en un validador, busca caracteres Unicode ocultos y asegúrate de que los mecanismos van separados por espacios con el cualificador all al final.

Varios registros SPF (hay que fusionarlos)

La RFC 7208 prohíbe explícitamente más de un registro TXT v=spf1 en el mismo dominio. Pasa cuando un equipo añade Google Workspace y otro añade SendGrid sin coordinarse. Los receptores que ven dos registros lanzan un PermError. Solución: combínalos en un único registro. v=spf1 include:_spf.google.com include:sendgrid.net ~all reemplaza los dos individuales.

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

El reenvío rompe SPF

Cuando un destinatario reenvía tu mensaje a otra dirección, la IP que conecta cambia pero el Return-Path sigue siendo el tuyo — y SPF falla en el salto de reenvío. Es por diseño, pero genera falsos negativos. Solución: apóyate en DKIM para alineación (DKIM sobrevive al reenvío), implementa SRS en los reenviadores que controles y asume que SPF solo no basta — que es exactamente por lo que DMARC pide SPF o DKIM, no los dos.

Confusión con la herencia entre subdominios

SPF no se hereda. mail.example.com y example.com son hosts distintos y necesitan registros SPF distintos. Bug típico: la empresa publica SPF en el ápice pero una herramienta de marketing envía desde updates.example.com — los receptores no ven SPF en el subdominio y tu correo falla la alineación. Solución: publica v=spf1 -all en cada subdominio que nunca deba enviar correo, y una política real en cada subdominio que sí envíe.

Configuración SPF paso a paso

1. Inventaria todos los servicios de envío

Lista cada sistema que envía correo desde tu dominio: plataformas de marketing (Mailchimp, HubSpot), proveedores transaccionales (SendGrid, Postmark, Resend), CRMs, mesas de soporte (Zendesk, Intercom), nóminas, pasarelas de pago y tus propios servidores de aplicación. Si te dejas uno, el correo legítimo se rechazará en cuanto publiques tu registro.

2. Elige una política de fallo (~all vs -all)

Empieza con ~all (soft fail) durante las primeras 1–2 semanas mientras vigilas los informes DMARC en busca de fuentes inesperadas. Cuando confirmes que cada remitente legítimo está en el registro y los informes DMARC muestran 100 % de pase, cambia a -all para máxima protección.

3. Construye el registro

Usa los include: que publican los proveedores siempre que puedas (p. ej., include:_spf.google.com). Para servicios sin include, usa ip4: con sus rangos publicados. Mantén el registro por debajo del límite de 10 lookups contando cada include y sus lookups anidados. Termina con un único cualificador — ~all o -all — nunca los dos.

4. Añade el registro TXT al DNS

En el panel de tu proveedor DNS, crea un nuevo registro TXT con host = @ (o el ápice de tu dominio) y value = la cadena SPF completa entrecomillada. Un TTL de 3600 (1 hora) es buen valor por defecto. Si tu proveedor DNS añade comillas automáticas, no las pongas tú también.

5. Valida y monitoriza

Usa el checker de arriba para verificar que el registro parsea limpio, que el conteo de lookups está por debajo de 10 y que la política está bien. Después manda correos de prueba a mail-tester.com y a tus propias cuentas de Gmail/Outlook. Configura DMARC con rua= para captar fuentes que se te hayan escapado. Monitoriza en continuo — las IPs de proveedores cambian, se añaden includes, y un SPF que estaba limpio hace seis meses puede romperse en silencio.

Cómo mantenerse bajo el límite de 10 lookups DNS

El límite de 10 lookups es la causa más común de fallos SPF a escala. Cada include: dispara una consulta DNS, y cualquier include que a su vez contenga includes dispara más — el SPF de Salesforce, por ejemplo, puede resolverse a 8+ lookups solo. Tres estrategias para mantenerte por debajo del límite. Primera: audita sin piedad. Cualquier proveedor que ya no uses sale del registro. Pasa nuestro checker cada mes y elimina includes muertos.

Segunda: sustituye include: por ip4: cuando los proveedores publiquen rangos IP estables. SendGrid, Mailgun y Amazon SES publican bloques estáticos; usar ip4:198.61.254.0/24 en vez de include:sendgrid.net cuesta cero lookups en lugar de dos. El precio es el mantenimiento — cuando el proveedor añada IPs nuevas tendrás que actualizar a mano.

Tercera: usa servicios de flattening de SPF (p. ej., easydmarc.com, dmarcian) para los includes anidados inevitables. Esos servicios resuelven todos tus includes en una lista plana de bloques ip4: y los republican como un único SPF alojado al que apuntas con un solo include. La pega es la dependencia operativa de un tercero — selecciónalos con cuidado y monitoriza posibles caídas.

SPF, DKIM y DMARC: cómo encajan

Solo con SPF no basta. Los tres protocolos forman una defensa por capas: SPF autentica la IP del servidor de envío, DKIM firma criptográficamente el contenido del mensaje, y DMARC ata ambos a la dirección From visible y le dice a los receptores qué hacer cuando la autenticación falla. SPF se rompe con el reenvío; DKIM sobrevive al reenvío pero es más complicado de desplegar porque exige generar un par de claves y publicar la pública en DNS. Juntos, la alineación DMARC pasa si pasa SPF o DKIM — desplegar los dos te da redundancia y cobertura completa en escenarios reales con reenvíos, listas de correo y cadenas de confianza ARC. Sin DMARC, SPF y DKIM son meras herramientas de diagnóstico; los receptores los pueden usar a la ligera o ignorar. Con DMARC en p=reject, te comprometes públicamente con tu política de autenticación y obligas a cada receptor del planeta a tirar el correo suplantado de raíz. Es el estándar moderno de seguridad en correo, y empieza con un SPF limpio. El orden recomendado de despliegue es: SPF primero (un registro TXT, impacto inmediato), después DKIM (generación de claves más DNS), luego DMARC en p=none con informes rua= durante dos semanas de monitorización, y por último endurecer progresivamente a p=quarantine y al final p=reject. Saltarte la monitorización es la causa más común de que se caiga correo legítimo durante el rollout DMARC.

Requisitos de Gmail y Yahoo en 2026

Desde febrero de 2024, Gmail y Yahoo exigen a todos los remitentes masivos (5.000+ mensajes al día a sus usuarios) publicar SPF, DKIM y DMARC, mantener una cabecera de unsubscribe en un clic (List-Unsubscribe con Post URL) y mantener las quejas de spam por debajo del 0,3 % medido en Postmaster Tools. Microsoft 365 aplica reglas similares vía SmartScreen, y Apple Mail sigue DMARC con rigor en iCloud y los Apple ID gestionados. En 2026 esos estándares se han endurecido: DMARC debe estar en p=quarantine o más estricto para tráfico masivo no autenticado, la confianza ARC se ha añadido a la cadena de evaluación para correo reenviado y las tasas de queja por encima del 0,1 % ya disparan entrega reducida antes incluso del tope duro del 0,3 %. El fallo no es un aviso suave — tu correo va a spam o se rechaza directamente en la capa SMTP. Incluso los remitentes no masivos se ven cada vez más afectados porque los filtros generalizan: un emisor B2B con 200 correos al día se beneficia igual de un SPF, DKIM y DMARC limpios porque los clasificadores de machine learning de Gmail reutilizan las mismas señales de autenticación para puntuar cada mensaje. La conclusión: SPF ya no es una buena práctica — es un prerrequisito de entregabilidad. Pasa el checker de arriba hoy para confirmar que tu SPF pasa, y luego pasa a DKIM y DMARC para completar el stack.

Guías relacionadas

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack