Herramienta gratuita
Generador de registros SPF gratuito
Crea tu registro SPF en minutos
Crea un registro TXT SPF válido para autorizar a tus remitentes y proteger tu entregabilidad. Elige tus proveedores, agrega tus propias IP y copia un registro correcto a la primera.
Sin registro. Validación en tiempo real.
Selecciona tus proveedores de email
Empieza por los proveedores que claramente requieren includes SPF en el dominio raíz. Muchos otros dependen de la configuración: los modos por defecto suelen apoyarse en DKIM, mientras que los modos con Return-Path o MAIL FROM personalizados pueden necesitar SPF en un subdominio de envío.
Includes SPF habituales en el dominio raíz
Estos proveedores suelen requerir includes SPF en el registro de tu dominio principal.
Avanzado: agregar includes personalizados
Úsalo solo cuando la documentación del proveedor exija explícitamente un include SPF para tu configuración (por ejemplo, un Return-Path o MAIL FROM personalizado).
Separados por comas. Los includes cuentan para el límite de 10 consultas DNS y pueden corresponder a un subdominio de envío.
Proveedores que dependen de la configuración
Las configuraciones por defecto suelen usar dominios Return-Path del proveedor y DKIM. Si activas un Return-Path o MAIL FROM personalizado, puede que necesites SPF (a menudo en un subdominio).
Email transaccional
El MAIL FROM por defecto usa amazonses.com; un MAIL FROM personalizado necesita SPF en ese subdominio
El modo CNAME automático suele gestionar SPF; el modo manual o con return-path personalizado puede necesitar SPF
SPF suele necesitarse en tu dominio o subdominio de envío
Return-Path del proveedor por defecto; el Return-Path personalizado admite alineación SPF
Configuración con DKIM primero; algunos modos de dominio aún requieren un include SPF
Marketing, ventas y soporte
Normalmente se apoya en DKIM; consulta la documentación cuando actives un dominio de rebote personalizado
Normalmente se apoya en DKIM; las necesidades de SPF dependen del plan y el modo de envío
La configuración del dominio de envío puede incluir requisitos de SPF
Agrega include:_spf.salesforce.com cuando Salesforce envíe correo por tu dominio
Puede requerir un include SPF al enviar en nombre de tu dominio
Puede que necesites SPF según la configuración de buzón o autenticación
Normalmente SPF del proveedor; la opción de return-path personalizado puede afectar a la alineación SPF
Agregar direcciones IP personalizadas (Opcional)
Separadas por comas. Admite notación CIDR (p. ej., 192.0.2.0/24).
Separadas por comas. Admite notación CIDR (p. ej., 2001:db8::/32).
Elige tu política SPF
Advertencia RFC 7208: Estos mecanismos están desaconsejados porque consumen consultas DNS y pueden causar problemas de fiabilidad. Usa ip4/ip6 en su lugar cuando sea posible.
Registro SPF generado
TXTv=spf1 ~all
Advertencia: Los registros SPF están limitados a 10 consultas DNS. Reduce los includes o usa direcciones IP directamente.
Cómo publicar
- 1 Inicia sesión en tu proveedor DNS (GoDaddy, Cloudflare, Namecheap, etc.).
- 2 Crea un registro TXT.
-
3
Host:
@o déjalo vacío - 4 Valor: pega el registro de arriba.
Verificación
Verifica tu configuración SPFTu registro SPF es solo el primer paso
Publicar SPF no te dice si de verdad funciona. Los informes DMARC te muestran cada fuente que envía en nombre de tu dominio, cuáles superan la autenticación y cuáles no, para que corrijas los problemas antes de que lleguen a la bandeja de entrada.
¿Qué es un registro SPF?
Sender Policy Framework (SPF) es un estándar de autenticación de correo que nombra los servidores autorizados a enviar por tu dominio. Publicas esa lista como un único registro TXT de DNS que empieza por v=spf1, y los servidores receptores la leen para decidir si un servidor que se conecta puede usar tu dominio.
Cuando un servidor recibe tu correo, lee el registro SPF del dominio del remitente del sobre y comprueba si la IP que se conecta está en la lista. Una coincidencia pasa SPF. Esta es una de las señales que usan los receptores para combatir la suplantación de correo y decidir si tu mensaje llega a la bandeja de entrada.
Por qué nuestro generador SPF vigila el presupuesto de consultas →
Formato y sintaxis de un registro SPF
Un registro SPF es una sola línea de texto con una forma fija. Empieza por el término de versión v=spf1 y, a continuación, una lista de términos separados por espacios. El servidor receptor lee los términos de izquierda a derecha y se detiene en el primero que coincide con la IP que se conecta, así que el orden importa. Cada término es un calificador opcional seguido de un mecanismo. Por ejemplo, ~all es el calificador ~ aplicado al mecanismo all.
Dos términos tienen una función especial. El término de versión v=spf1 va primero. El mecanismo all va al final, porque coincide con todo lo que los términos anteriores no cubrieron. Todo lo que hay en medio, los includes, los rangos de IP y los demás mecanismos, es donde indicas quién está autorizado a enviar.
Un registro por dominio. Un dominio debe publicar exactamente un registro TXT que empiece por v=spf1. Si publicas dos, el servidor receptor no sabe cuál usar, así que SPF devuelve un PermError y la verificación no se supera (RFC 7208 §4.5). Si una cadena supera los 255 caracteres, divide el valor en varias cadenas entre comillas dentro del mismo registro TXT; el receptor las une sin agregar espacios (RFC 7208 §3.3).
La gramática completa está en RFC 7208, el estándar que define SPF.
Referencia de mecanismos SPF
SPF define ocho mecanismos (RFC 7208 §5). La columna de la derecha es la que la mayoría de los registros defectuosos pasan por alto: cada mecanismo que provoca una consulta gasta parte de tu presupuesto de 10 consultas, y superarlo hace que SPF falle. El generador de arriba cuenta esta columna en vivo a medida que construyes.
| Mecanismo | Formas de sintaxis | Qué autoriza | Consultas DNS |
|---|---|---|---|
all |
all | Coincide siempre. Se coloca al final para fijar el resultado por defecto de los remitentes no listados antes. | 0 |
include |
include:dominio | Autoriza a todos los remitentes del registro SPF de otro dominio. La forma habitual de agregar un proveedor como Google o SendGrid. | 1 |
a |
a a/prefijo a:dominio a:dominio/prefijo | La dirección A o AAAA del dominio (el dominio actual si no se indica ninguno), opcionalmente un rango CIDR completo. | 1 |
mx |
mx mx/prefijo mx:dominio mx:dominio/prefijo | Las direcciones de los servidores de correo del dominio (sus hosts MX), opcionalmente un rango CIDR completo. | 1+ |
ptr |
ptr ptr:dominio | La IP que se conecta si su nombre DNS inverso termina en tu dominio. La RFC 7208 §5.5 indica que este mecanismo NO DEBERÍA publicarse. | 1 |
ip4 |
ip4:direccion ip4:rango/prefijo | Una dirección IPv4 o un rango CIDR. Sin consulta DNS, así que no cuesta nada en el presupuesto. | 0 |
ip6 |
ip6:direccion ip6:rango/prefijo | Una dirección IPv6 o un rango CIDR. Como ip4, no cuesta nada en el presupuesto. | 0 |
exists |
exists:dominio | Coincide si una consulta DNS del dominio (normalmente construido con macros) devuelve un registro A. Se usa en configuraciones avanzadas con macros. | 1 |
El mecanismo mx muestra «1+» porque el receptor consulta el registro MX y luego resuelve cada host de correo nombrado, y cada una de esas resoluciones cuenta. Prefiere ip4 e ip6 para direcciones fijas. Coinciden de forma exacta y no cuestan nada en el presupuesto.
Calificadores SPF: + - ~ ?
Un calificador es el único carácter que va delante de un mecanismo. Decide el resultado cuando ese mecanismo coincide con la IP que se conecta. Si lo omites, SPF asume + (pass), así que include:_spf.google.com significa lo mismo que +include:_spf.google.com (RFC 7208 §4.6.2).
| Calificador | Resultado | Qué le indica al servidor |
|---|---|---|
+ |
Pass | El remitente está autorizado. Es el valor por defecto, así que casi nunca lo escribes. Por lo general solo pones un calificador en el mecanismo all del final. |
- |
Fallo | El remitente no está autorizado; rechazar el correo. Escrito como -all, es un fallo estricto (hardfail). |
~ |
Softfail | Probablemente el remitente no esté autorizado; acepta el correo pero trátalo como sospechoso. Se escribe ~all. |
? |
Neutro | No afirma nada en ningún sentido, igual que no tener política. Se escribe ?all. |
~all frente a -all: empieza con ~all (softfail) mientras revisas tus informes DMARC y confirmas que todos los remitentes legítimos están en la lista. Pasa a -all (fallo) cuando la lista esté completa. Un -all prematuro rechaza a cualquier remitente que hayas olvidado, y también puede romper el correo reenviado, porque el reenvío cambia el servidor que envía.
Modificadores: redirect y exp
La mayoría de los generadores omiten estos dos, pero forman parte del estándar y te los encontrarás en registros reales (RFC 7208 §6). Un modificador se escribe como nombre=valor y, a diferencia de un mecanismo, aparece como máximo una vez.
redirect=dominio
Entrega la evaluación al registro SPF de otro dominio y usa su resultado, incluido su mecanismo all. Útil cuando muchos dominios comparten una misma política. Cuenta como una consulta DNS de tu presupuesto y se ignora si el registro ya tiene un mecanismo all (RFC 7208 §6.1).
exp=dominio
Apunta a un registro TXT con una explicación legible que el receptor puede mostrar cuando SPF falla. No cambia el resultado y su consulta no cuenta para el límite de 10 consultas (RFC 7208 §6.2, §4.6.4).
El límite de 10 consultas DNS
SPF limita cuánto trabajo de DNS hará un receptor por tu registro. Como máximo pueden ejecutarse 10 términos que provocan consulta durante la evaluación (RFC 7208 §4.6.4). Los mecanismos include, a, mx, ptr y exists, más el modificador redirect, cuentan cada uno. Los términos ip4, ip6, all y exp no.
La trampa es que un include trae otro registro, y los includes de ese registro también cuentan. Así, tres o cuatro includes de proveedores en tu propia línea pueden sumar más de diez sin que te des cuenta. Si cruzas el límite, SPF devuelve un PermError. Los receptores lo tratan como un fallo, lo que significa que SPF no puede superar la verificación y tu alineación de DMARC con SPF falla con él.
Consultas vacías. Hay un segundo límite, más discreto. Un receptor DEBERÍA detenerse tras dos consultas «vacías», es decir, las que no devuelven ningún registro (RFC 7208 §4.6.4). Un error de tipeo en un include o un proveedor que eliminó su registro SPF puede activarlo aunque tu total esté por debajo de diez.
Cómo contamos esto en producción
El generador de esta página cuenta la columna de consultas en vivo a medida que marcas proveedores y agregas IP, para que te mantengas dentro del presupuesto antes de publicar. Aplicamos la misma lógica en dominios reales. Nuestro analizador implementa la RFC 7208 §4.6.4, cuenta el total anidado completo al que se expande un include, controla las consultas vacías frente al límite de dos y excluye exp del recuento como exige el estándar. Cuando un registro ya supera el límite, las correcciones habituales, por orden de esfuerzo, son: eliminar los includes de proveedores que ya no uses, cambiar los includes estables por rangos ip4 e ip6 explícitos y solo entonces recurrir al aplanado de SPF, que nuestro plan Pro ejecuta automáticamente cada 30 minutos para mantener el registro aplanado al día.
Cómo encajan SPF, DKIM y DMARC
SPF rara vez actúa solo. Es uno de tres registros que trabajan juntos, y el receptor lee los tres. Esta es la división de tareas:
SPF autoriza el servidor que envía
Responde a «¿esta IP está autorizada a enviar por el dominio del sobre?» SPF verifica el remitente del sobre (el Return-Path o MAIL FROM) y el nombre HELO, no la dirección From que ve tu lector (RFC 7208 §2.4).
DKIM firma el mensaje
Tu servidor agrega una firma criptográfica en una cabecera, y el receptor la verifica con una clave pública publicada en tu DNS. Una firma válida prueba que el mensaje no se modificó en tránsito y que realmente proviene de tu dominio.
DMARC los vincula con el From visible
DMARC se supera cuando SPF o DKIM se verifica Y se alinea con el dominio de la cabecera From que ve tu lector. También indica a los receptores qué hacer ante un fallo (none, quarantine o reject) y a dónde enviar los informes.
SPF es la primera pieza. Construye la segunda con nuestro generador de registros DMARC y luego sigue la lista de configuración de DMARC para llevar tu dominio de cero protección a una política de rechazo sin afectar la entregabilidad.
Cómo es un registro SPF real
Este es un registro para un dominio que envía con Google Workspace, SendGrid y un servidor propio:
v=spf1
Marca esto como un registro SPF. Todo registro empieza por aquí, y un dominio solo puede publicar uno.
include:_spf.google.com
Incorpora la lista de IP de envío que publica Google. Cada include es una consulta DNS contra el presupuesto de 10.
include:sendgrid.net
Autoriza a SendGrid de la misma forma. Dos includes hasta aquí significan dos consultas usadas.
ip4:198.51.100.10
Autoriza por su dirección un servidor que gestionas directamente. Un mecanismo ip4 o ip6 cuesta cero consultas, así que prefiérelo para IP fijas.
~all
Captura todo remitente no listado arriba y le aplica softfail. Los mecanismos se leen de izquierda a derecha, así que el término all siempre va al final.
Cómo funciona la autenticación SPF
Los receptores ejecutan SPF durante la conversación SMTP, antes de aceptar el mensaje:
Un servidor se conecta
Tu servidor de correo abre una conexión con el servidor del destinatario y presenta una dirección de remitente del sobre y una IP de origen.
El receptor busca el SPF
Toma el dominio del Return-Path (el remitente del sobre) y consulta en el DNS el registro SPF de ese dominio.
Se comprueba la IP
Recorre los mecanismos del registro en orden y pregunta si alguno de ellos autoriza la IP que se conecta.
Se asigna un resultado
La coincidencia y tu cualificador final producen un veredicto: pass, fail, softfail o neutral.
El veredicto alimenta el filtrado
SPF se suma a DKIM y DMARC como entradas de la decisión de spam y autenticación del receptor.
Por qué tu dominio necesita SPF
Un dominio sin SPF es más fácil de suplantar y más difícil para entregar correo. Lo que obtienes al publicar uno:
Más difícil de suplantar
SPF nombra los servidores autorizados a enviar por ti. Sin él, cualquiera puede falsificar tu dirección desde cualquier servidor y los destinatarios no tienen forma de notarlo.
Mejor entregabilidad
Gmail, Microsoft y Yahoo leen SPF. El correo de un dominio sin SPF tiene más probabilidad de caer en spam o ser rechazado.
Cumple las reglas de remitentes masivos
Desde febrero de 2024, Google y Yahoo exigen a los remitentes masivos (en torno a 5.000+ mensajes al día) publicar SPF, DKIM y un registro DMARC. SPF es una de las patas de ese requisito.
Alimenta la alineación DMARC
DMARC pasa cuando SPF o DKIM se alinean con tu dominio From. SPF es una de las dos vías, así que influye directamente en si DMARC te protege.
Protege tu reputación
Cuando alguien suplanta tu dominio, los destinatarios que reciben el phishing culpan a tu marca. SPF es parte de cortar eso de raíz.
Errores comunes de SPF que debes evitar
La mayoría de los registros SPF rotos fallan por una de estas razones:
Cruzar las 10 consultas DNS
Cada include, a, mx, ptr, exists y redirect cuenta para el límite de 10. Si lo superas, SPF devuelve PermError. Cambia includes por ip4/ip6 cuando las IP sean estables.
Publicar dos registros SPF
Un dominio debe tener exactamente un registro que empiece por v=spf1. Dos de ellos son un PermError automático. Fusiónalo todo en un solo registro.
Agregar includes que no necesitas
Muchos proveedores envían desde su propio Return-Path, así que un include en el dominio raíz solo quema una consulta. Agrégalo únicamente cuando la documentación del proveedor lo indique, normalmente para Return-Path o MAIL FROM personalizado.
Pasar a -all demasiado pronto
El hardfail rechaza a cualquier remitente que olvidaste listar, incluidos los tuyos. Quédate en ~all con monitoreo DMARC hasta que tus informes muestren todas las fuentes legítimas.
Olvidar tus propios servidores
Los formularios de contacto, las notificaciones de aplicaciones y los scripts de monitoreo también envían correo. Si un servidor tuyo envía, su IP debe estar en el registro.
Los subdominios necesitan su propio registro
SPF no se hereda. Un registro en ejemplo.com no dice nada sobre el correo enviado desde mail.ejemplo.com o news.ejemplo.com. Cada subdominio que envía correo necesita su propio registro SPF en su propio nombre.
Para un subdominio que nunca envía correo, publica un registro que no autorice nada: v=spf1 -all. Eso aplica hardfail a quien falsifique correo desde él y cierra una vía que les gusta usar a los atacantes.
Pruébalo después de publicar
Los cambios de DNS tardan en propagarse, desde unos minutos hasta unas horas. Cuando el registro esté activo, léelo desde la línea de comandos antes de fiarte:
macOS o Linux
Windows
Un resultado correcto devuelve la cadena exacta que publicaste, por ejemplo:
¿Prefieres el navegador? Haz la misma comprobación en nuestro verificador de dominios gratuito y obtén un veredicto claro sobre SPF, DKIM y DMARC.
Cómo crear un registro SPF para tu dominio
Marca los proveedores que requieren un include en el dominio raíz, agrega las IP de los servidores que gestionas, agrega los includes del proveedor según su documentación cuando haga falta y elige una política. La herramienta genera el SPF válido sobre la marcha y tú copias el resultado en el DNS.
Para muchos proveedores transaccionales y de marketing, un include en el dominio raíz es opcional. Envían desde su propio Return-Path y se apoyan en DKIM para la alineación DMARC. Agrega un include solo cuando actives un Return-Path o MAIL FROM personalizado, y entonces normalmente corresponde al subdominio de envío.
SPF es solo un paso. Sigue la lista de configuración de DMARC para llevar tu dominio de cero protección a una política de rechazo sin afectar la entregabilidad.
Preguntas frecuentes
¿Qué es un registro SPF y por qué lo necesito para el correo?
Un registro SPF (Sender Policy Framework) es un registro TXT de DNS que enumera los servidores de correo autorizados a enviar correo por tu dominio. Sin él, receptores como Gmail y Outlook tienen más probabilidad de marcar tu correo como spam o rechazarlo. Desde febrero de 2024, Google y Yahoo exigen SPF a los remitentes masivos.
¿Cómo genero un registro SPF para mi dominio?
Introduce tu dominio en la herramienta de arriba, selecciona los proveedores que envían correo por ti (Google Workspace, Microsoft 365, etc.), agrega las direcciones IP propias, elige una política y copia. El generador genera la sintaxis SPF correcta por ti.
¿Dónde agrego mi registro SPF en el DNS?
Agrégalo como registro TXT en la raíz de tu dominio (host @ o vacío). Entra en tu proveedor DNS (GoDaddy, Cloudflare, Namecheap, Route 53 y similares), crea un registro TXT y pega el valor generado. Publica un solo registro que empiece por v=spf1.
¿Cuál es el límite de 10 consultas DNS de SPF?
Un registro SPF puede provocar como máximo 10 consultas DNS cuando un receptor lo evalúa. Los mecanismos include, a, mx, ptr, exists y redirect cuentan; ip4, ip6 y all no. Si pasas de 10, SPF devuelve un PermError, que los receptores tratan como un fallo. El contador de esta página va sumando consultas en vivo.
¿Cuál es la diferencia entre ~all y -all en SPF?
~all (softfail): los receptores aceptan el correo que falla SPF pero lo tratan como sospechoso. Es el ajuste adecuado mientras revisas los informes DMARC, porque DMARC toma la decisión final.
-all (fail): los receptores rechazan el correo que falla SPF. La opción más estricta, y vale la pena pasar a ella cuando todos los remitentes legítimos están listados. Puede romper algún reenvío.
?all (neutral): el resultado no tiene peso, lo mismo que no tener política. Evítalo en producción.
¿Por qué SPF comprueba el Return-Path en lugar de la dirección From?
SPF autentica el remitente del sobre, el Return-Path o MAIL FROM, más el nombre HELO. No mira la cabecera "From" visible que leen tus destinatarios. Muchos proveedores ponen su propio dominio en el Return-Path (por ejemplo mcsv.net en Mailchimp), así que la comprobación SPF se hace contra sus servidores, no los tuyos.
DMARC necesita alineación para pasar. Las configuraciones por defecto del proveedor suelen lograrlo mediante la firma DKIM con tu dominio, lo que significa que no hace falta un include SPF extra en tu raíz.
Esto depende de la configuración. Si activas un Return-Path o MAIL FROM personalizado en tu propio dominio o subdominio, SPF pasa a ser necesario para ese dominio de envío.
Más información sobre Return-Path y los requisitos SPF de los proveedores →
¿Cómo compruebo qué Return-Path usa mi proveedor?
Envíate un mensaje de prueba a través del proveedor y lee las cabeceras:
- Gmail: abre el mensaje, pulsa el menú de tres puntos y elige "Mostrar original".
- Outlook: abre el mensaje y ve a Archivo → Propiedades → "Encabezados de Internet".
Busca la línea Return-Path. Si muestra tu dominio o un subdominio que controlas (como [email protected]), ese dominio de envío necesita SPF. Si muestra el dominio del proveedor (como [email protected]), el proveedor gestiona SPF y DKIM es tu vía de alineación.
¿Dónde puedo encontrar la documentación SPF oficial de cada proveedor?
Cada proveedor documenta su propia configuración SPF. Enlaces directos:
Plataformas de email
Email transaccional
Email de marketing
¿Qué es un PermError de SPF?
Un PermError (error permanente) significa que un receptor no pudo evaluar tu registro SPF. La causa habitual es cruzar el límite de 10 consultas; una segunda causa es publicar dos registros que empiezan por v=spf1. Los receptores tratan un PermError como un fallo, así que la alineación de DMARC con SPF también falla.
Soluciónalo por orden de esfuerzo:
- Elimina los includes de proveedores que ya no uses.
- Reemplaza los includes estables por mecanismos explícitos
ip4/ip6. - Usa el aplanado de SPF para proveedores con rangos de IP dinámicos. Nuestro plan Pro lo automatiza.
¿Cómo soluciono el error de demasiadas consultas DNS en SPF?
SPF devuelve PermError en cuanto el registro necesita más de 10 consultas DNS. Para volver por debajo del límite:
- Cuenta cada
include,a,mx,ptr,existsyredirectde tu registro. Cada uno es una consulta. - Elimina los remitentes que ya no uses.
- Reemplaza los includes pesados por
ip4/ip6donde las IP se mantengan estables. - Para proveedores con IP cambiantes, usa el aplanado de SPF para que el registro se reconstruya automáticamente.
¿Cuál es la diferencia entre softfail (~all), neutral (?all) y hardfail (-all)?
~all (softfail): los receptores aceptan el correo no autorizado pero lo marcan como sospechoso. Úsalo mientras supervisas con DMARC.
-all (hardfail): los receptores rechazan de plano el correo no autorizado. Pasa aquí cuando todos los remitentes legítimos estén en tu registro.
?all (neutral): los receptores actúan como si no existiera un registro SPF. Echa por tierra el sentido de publicar uno.
¿Cómo se lee un registro SPF?
Léelo de izquierda a derecha. El registro empieza por v=spf1 y, a continuación, cada término separado por un espacio es un calificador opcional seguido de un mecanismo. El receptor compara la IP que se conecta con cada término en orden y se detiene en la primera coincidencia. Así, v=spf1 include:_spf.google.com ip4:198.51.100.10 ~all significa: autorizar a los servidores de Google, autorizar esa IP y aplicar softfail al resto.
¿Cuál es la diferencia entre un mecanismo, un calificador y un modificador de SPF?
Un mecanismo indica quién puede enviar (include, ip4, a, mx y los demás). Un calificador es el + - ~ ? que va delante de un mecanismo y fija su resultado. Un modificador (redirect, exp) se escribe como nombre=valor y cambia cómo se evalúa todo el registro en lugar de coincidir con una IP.
Completa tu autenticación de email
SPF es solo una parte de la autenticación de email. Combínalo con DKIM y DMARC para una protección completa contra la suplantación y el phishing.