Verificador y generador de registro SPF

Cómo comprobar un registro SPF

1. Escribe un dominio en el campo superior. También puedes pegar una dirección de correo completa: la herramienta extraerá el dominio automáticamente.
2. Haz clic en Comprobar registro SPF. La consulta se realiza en servidores DNS públicos autorizados, de la misma forma que lo hace un servidor de correo receptor.
3. Revisa primero el resumen: indica si el registro es válido, si presenta advertencias o si está roto.
4. A continuación, consulta la lista de problemas detectados. Cada punto explica con exactitud qué corregir.
5. Debajo encontrarás la explicación de cada término del registro y las consultas DNS que consume. Puedes desplegar cada include para ver qué autoriza.

El enlace en la barra de direcciones guarda esta misma comprobación SPF para que puedas compartirlo con un compañero o tu proveedor de DNS. Ten en cuenta una limitación: los servidores receptores evalúan el SPF según la IP del servidor que entrega el mensaje. Al no tener un mensaje real que analizar, esta herramienta valida el registro y su árbol DNS público. No puede evaluar macros SPF dinámicas que dependen de la IP del remitente.

¿Qué es un registro SPF?

Un registro SPF es un registro TXT en el DNS de un dominio que enumera los servidores autorizados para enviar correos en su nombre. SPF significa Sender Policy Framework y sus reglas están recogidas en la RFC 7208. Un dominio configurado con Google Workspace suele tener un registro como este:

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

v=spf1 identifica el inicio del registro SPF. include:_spf.google.com autoriza a todos los servidores de la lista oficial de Google. ~all indica a los servidores de destino que traten con sospecha los correos procedentes de cualquier otro servidor.

Al recibir un correo, el servidor de destino toma el dominio de la dirección de rebote (Return-Path o Envelope From), consulta su registro SPF y comprueba si la IP del servidor emisor está autorizada. SPF no comprueba la dirección From visible en la bandeja de entrada. Por este motivo se combina con DKIM y DMARC. Para entender cómo se integran, consulta SPF, DKIM y DMARC explicados.

Desde febrero de 2024, Gmail exige SPF o DKIM a todos los remitentes, y ambos a quienes realizan envíos masivos. Yahoo aplica los mismos requisitos.

Qué significa cada parte del registro SPF

Un registro SPF se compone de términos separados por espacios. Los servidores de destino leen de izquierda a derecha y se detienen en el primer término que coincide con el servidor de envío.

Cualquier mecanismo puede llevar un calificador inicial que define el resultado en caso de coincidencia. + significa Pass (aprobado) y es el valor por defecto si se omite. - significa Fail (rechazo estricto), ~ significa Softfail (falso suave) y ? significa Neutral (neutro). Por eso la palabra all suele cerrar los registros como -all, ~all o ?all.

Los nombres no distinguen entre mayúsculas y minúsculas: Include: funciona igual que include:. La RFC 7208 aconseja cerrar todo registro con all o con un modificador redirect. Sin una regla de cierre explícita, los servidores no listados obtienen un resultado neutral.

El límite estricto de 10 consultas DNS

Cada include, a, mx, ptr, exists y redirect obliga al servidor de destino a realizar una consulta de resolución DNS. La RFC 7208 establece un límite máximo de 10 consultas por validación. Las consultas realizadas dentro de los include anidados también cuentan, por lo que un solo include puede sumar varias consultas. ip4, ip6 y all no generan ninguna consulta. Si un registro supera las 10 consultas, los servidores receptores abortan el análisis con un error permanente (Permerror) y el SPF falla.

Llegar a este límite es muy fácil. Hemos medido el coste de includes comunes en DNS público: Google Workspace consume 1 consulta, Microsoft 365 consume 1 consulta, Salesforce consume 2, Mailgun consume 5 y Freshdesk 7. Una empresa en Google Workspace que sume Mailgun y Freshdesk ya alcanza 13 consultas. Un estudio de 2024 sobre registros SPF en dominios .com, .net, .org y .se reveló que el 6,5 % superaba las 10 consultas, y que los includes de solo dos proveedores de hosting causaban el 83,7 % de estos casos.

Los costes también cambian con el tiempo. El include de Google costaba 4 consultas hasta diciembre de 2025, cuando Google sustituyó sus includes anidados por una lista plana. Muchos manuales y generadores antiguos todavía mencionan el valor de 4. Nuestra herramienta analiza el árbol DNS en tiempo real para contar el número exacto.

Superar el límite no siempre hace fallar todos los mensajes de forma predecible. Como explica Microsoft, los servidores evalúan los mecanismos de izquierda a derecha y se detienen en la primera coincidencia. Los correos de un proveedor listado al inicio pueden pasar, mientras que los de un servicio al final fallan. Por eso es indispensable contar las consultas del registro al completo.

Existe además un segundo límite: las consultas vacías (void lookups), que ocurren al consultar dominios inexistentes o sin registros. La RFC 7208 obliga a los servidores a detener la evaluación tras 2 consultas vacías consecutivas.

Cómo mantenerse por debajo de las 10 consultas DNS

1. Elimina includes de herramientas y servicios que ya no utilices.
2. Elimina includes que los proveedores ya no solicitan. Plataformas como Mailchimp, Postmark, Brevo y Klaviyo ya no precisan un include en tu dominio principal. SendGrid y Amazon SES gestionan sus envíos en subdominios dedicados. Consulta la lista inferior.
3. Define tus propios servidores de correo con ip4 e ip6 en lugar de mecanismos a o mx. La RFC 7208 recomienda este orden y las direcciones IP directas no consumen consultas DNS.
4. Envía correos masivos o transaccionales a través de un subdominio dedicado, como noticias.ejemplo.es. Cada subdominio tiene su propio registro y dispone de su propio cupo de 10 consultas.

Algunos servicios ofrecen aplanamiento de SPF (SPF flattening), reemplazando los includes por sus direcciones IP resultantes. Aunque reduce consultas DNS, los proveedores actualizan sus rangos de IP periódicamente y un registro aplanado queda desactualizado. Microsoft desaconseja aplanar registros salvo en servicios con rangos fijos y exige revisiones trimestrales.

Includes SPF para Google Workspace, Microsoft 365 y otros proveedores

Estos son los valores include recomendados en la documentación oficial de cada servicio, con las consultas DNS medidas en DNS público a 12 de octubre de 2026. Comprueba siempre la documentación de tu proveedor por si tu cuenta requiere una variante regional.

HubSpot asigna a cada cuenta un include exclusivo que termina en hubspotemail.net. Debes copiarlo desde los ajustes de correo de HubSpot. Consume 1 consulta.

Servicios que generalmente no necesitan un include SPF

El control SPF se valida contra la dirección de rebote técnica (Return-Path), no contra el campo From visible. La mayoría de proveedores de email marketing actuales gestionan sus propios rebotes en sus servidores o mediante subdominios CNAME. Añadir su include a tu dominio principal solo consume consultas DNS sin aportar protección.

• Mailchimp. Mailchimp gestiona la autenticación mediante registros CNAME de DKIM.
• Postmark. Postmark envía desde su propio dominio de Return-Path.
• Brevo. Brevo no requiere SPF en el dominio raíz salvo con IP dedicada.
• Klaviyo. Klaviyo no requiere un include SPF en el dominio raíz.
• SendGrid. SendGrid ubica el SPF en un subdominio generado durante la autenticación.
• Amazon SES. SES solo lo requiere en subdominios MAIL FROM personalizados.

Nuestro verificador resalta estos includes redundantes si los detecta en tu registro.

Cómo crear un registro SPF

Pasa a la pestaña Crear para utilizar el generador interactivo de SPF. Marca los servicios que envían correos en tu nombre y la herramienta generará la sintaxis adecuada mientras supervisa el consumo de consultas DNS. Si tu dominio ya tiene un registro, cárgalo primero para complementarlo en lugar de sobreescribirlo. Estos son los pasos recomendados :

1. Haz un inventario de todos los servicios que envían correos desde tu dominio: correo corporativo, boletines, CRM, help desk, facturación y formularios web. Los informes DMARC ayudan a identificar remitentes olvidados.
2. Localiza el include de cada servicio o selecciónalo en nuestra herramienta. Para servidores propios, añade sus direcciones IP.
3. Elige la regla de cierre: ~all o -all. La siguiente sección detalla las implicaciones de cada una.
4. Publica la regla como un único registro TXT en el nodo raíz de tu dominio (habitualmente indicado con @ en tu panel DNS). Si ya existe un registro que empiece por v=spf1, edítalo en lugar de añadir uno nuevo.
5. Espera unos minutos a la propagación DNS y vuelve a verificar el dominio con este analizador para confirmar que todo funciona.

Cada subdominio emisor necesita su propio registro, ya que no heredan la configuración del dominio principal. Un dominio o subdominio que nunca envíe correos debe protegerse expresamente con: v=spf1 -all. La RFC 7208 define esto como una práctica recomendada esencial para evitar la suplantación. El NCSC del Reino Unido recomienda añadir también una regla DMARC con p=reject y un registro MX nulo a los dominios inactivos.

Los registros que superen los 255 caracteres deben dividirse en varias cadenas entrecomilladas dentro del mismo registro TXT. Los servidores receptores unen estas cadenas sin insertar espacios, por lo que el espacio debe figurar dentro de las comillas. Revisa la documentación de tu proveedor DNS sobre cadenas largas.

~all o -all: qué cierre utilizar

Los principales proveedores y organizaciones de la industria no coinciden plenamente:

• Google recomienda usar ~all (Softfail).
• El M3AAWG, consorcio internacional de operadores de correo, recomienda que los registros terminen en ~all y solicita a los receptores no rechazar mensajes por SPF antes de evaluar la alineación DMARC.
• Microsoft recomienda -all (Fail estricto), siempre que DKIM y DMARC estén plenamente operativos.

El inconveniente de -all es que algunos servidores receptores descartan los mensajes durante la negociación SMTP inicial, antes de verificar la política DMARC. La norma RFC 9989, estándar DMARC de 2026, destaca que esos mensajes descartados nunca se reflejan en los informes DMARC agregados, lo que dificulta diagnosticar entregas legítimas perdidas.

En la práctica, ~all es la alternativa más prudente para dominios activos, especialmente mientras terminas de mapear todos tus canales de envío. Si dispones de una política DMARC en quarantine o reject, DMARC determinará el destino final del correo. Reserva -all para dominios inactivos o puramente defensivos. Nunca uses +all (autoriza a todo Internet) y evita ?all (equivalente a no tener protección).

Qué significan los resultados de la comprobación SPF

Los servidores receptores emplean términos estandarizados para clasificar el resultado del análisis SPF en los encabezados Authentication-Results y en los informes DMARC:

Errores frecuentes en registros SPF y cómo corregirlos

Un estudio de 2023 sobre 12 millones de dominios populares halló SPF en el 56,5 % de ellos y errores graves en el 2,9 % de los registros configurados. El fallo más común fue incluir dominios que carecen de registro SPF propio, seguido inmediatamente por exceder el límite de consultas DNS.

Dos registros SPF en el mismo dominio

Suele ocurrir al dar de alta una herramienta nueva cuando su guía indica “añade este registro TXT” y se crea una entrada adicional en vez de editar la existente. Tener dos registros SPF genera un Permerror automático. Combina todos los mecanismos en una sola entrada que comience por v=spf1 y termine con un único all.

Include que apunta a un dominio sin SPF o inexistente

Si un include referencia un dominio sin registro SPF válido, toda la comprobación SPF falla con un Permerror. Suele deberse a erratas tipográficas o a proveedores dados de baja. Elimina o corrige el include afectado.

+all, ?all o falta de regla all final

+all autoriza a todos los servidores del mundo y desactiva la protección. ?all o la omisión del cierre devuelven un estado neutral inútil. Concluye siempre tu registro con ~all o -all.

Uso del mecanismo ptr

La RFC 7208 desaconseja el uso de ptr por su excesiva lentitud y consumo de consultas DNS. Sustitúyelo por entradas ip4 e ip6 directas para los servidores correspondientes.

Errores tipográficos en la sintaxis

Un espacio tras los dos puntos, una dirección IPv4 incompleta o palabras no reconocidas causan un Permerror. Un fallo sutil es escribir include=example.com con signo igual en lugar de dos puntos: el DNS lo ignora como modificador desconocido y el servicio nunca queda autorizado. Nuestra herramienta detecta estos fallos al instante.

Tres mitos habituales sobre el registro SPF

• «Un registro SPF no puede tener letras mayúsculas.» La RFC 7208 define los términos como totalmente insensibles a mayúsculas y minúsculas.
• «Un registro SPF tiene un tope máximo de 255 caracteres.» El límite de 255 caracteres aplica a cada subcadena dentro del registro DNS TXT. Los registros largos se dividen en varias cadenas que el servidor receptor une automáticamente.
• «Se pueden incluir hasta 10 términos include.» La limitación aplica al total de consultas DNS recursivas que genera el árbol SPF, no al número de directivas include escritas.

El SPF dentro de la autenticación del correo electrónico

Un resultado pass en SPF tiene limitaciones. En el estudio de 2023, el 34,7 % de los dominios analizados autorizaban indirectamente más de 100.000 direcciones IP. Además, el SPF falla habitualmente ante el reenvío automático de correos, ya que la IP del servidor que reenvía no figura en el registro original.

DKIM complementa esta carencia firmando criptográficamente el mensaje, resistiendo a los reenvíos. DMARC coordina ambos protocolos comprobando que el dominio del campo From coincida con el validado por SPF o DKIM, e indica a los servidores de destino cómo actuar si ninguno supera la prueba. Configura los registros complementarios con nuestro generador DKIM y nuestro generador DMARC. Emplea nuestra consulta MX para revisar la recepción de tu dominio.

La autenticación tampoco solventa los envíos a buzones inexistentes. Los correos que rebotan perjudican la reputación de tu dominio. Limpia direcciones individuales con el verificador de email o valida listas completas con nuestro verificador masivo de emails. Si necesitas una referencia técnica rápida para tu equipo, consulta la entrada sobre registro SPF en el glosario.