Elige los servicios que envían correo por tu dominio y obtén un registro SPF válido con el número real de consultas DNS. Carga el registro que publicas hoy, combínalo con el nuevo y compruébalo con DNS en vivo. Gratis, sin registro.
Un registro SPF es un registro TXT en el DNS de un dominio que indica qué servidores de correo pueden enviar mensajes en nombre de ese dominio. Los servidores receptores comparan el servidor remitente con esa lista y tratan el correo de cualquier otro como sospechoso o lo rechazan. SPF está definido en el RFC 7208 y siempre empieza por v=spf1.
El generador de esta página crea el registro a partir de los servicios que realmente usas, cuenta las consultas DNS que provoca y te avisa antes de que supere el límite de diez. Es el motivo más habitual por el que un registro SPF que parece correcto no funciona en absoluto.
1. Dile al generador quién envía tu correo. Marca tu proveedor de correo, tu herramienta de newsletter y cualquier otro servicio que envíe con tu dominio en la dirección del remitente: la tienda, el servicio de atención, el CRM, el programa de facturación. Si tu propio servidor envía correo, marca mx o escribe su dirección en el campo IPv4.
2. Publica un único registro TXT. Copia el valor en el DNS de tu dominio como registro TXT en el propio dominio. Si ya existe un registro que empieza por v=spf1, sustitúyelo. No añadas un segundo: dos registros SPF son un error, y los receptores ignoran SPF por completo.
3. Compruébalo. «Comprobar con DNS en vivo» resuelve cada include del nuevo registro y cuenta las consultas igual que un receptor. Tras publicarlo, el Email Security Check lee SPF junto con DKIM y DMARC y muestra si los tres encajan.
¿Ya tienes un registro? Escribe tu dominio arriba y pulsa «Cargar registro publicado». El generador lee lo que publicas hoy, marca los servicios que reconoce y conserva todo lo demás. Así amplías el registro en lugar de empezar de cero y perder un remitente del que ya nadie se acordaba.
Todos los paneles DNS piden lo mismo: un tipo, un nombre y un valor. Solo cambia el campo del nombre, porque cada panel escribe «el propio dominio» de una forma distinta.
| Lo que muestra tu panel | Lo que debes poner como nombre | Por ejemplo en |
|---|---|---|
| Un campo «Nombre» o «Host» | @ |
Cloudflare, IONOS, GoDaddy, Namecheap |
| Un campo de nombre con el dominio ya añadido detrás | déjalo vacío | Plesk, AWS Route 53, muchos paneles de hosting |
| Un campo que exige el nombre completo | example.com. con el punto final |
editores tipo BIND, algunos registradores |
| Un archivo de zona | example.com. 3600 IN TXT "v=spf1 ..." |
tu propio servidor de nombres |
El tipo es siempre TXT. El antiguo tipo SPF (tipo 99) se abandonó en 2014 y los receptores lo ignoran; si tu panel todavía lo ofrece, no lo uses. El TTL puede quedarse en su valor por defecto. Escribe el valor sin comillas, salvo que el panel las pida. Si divide un valor largo en varias cadenas entre comillas, no pasa nada: los receptores las vuelven a unir sin espacios.
Al evaluar un registro SPF, un receptor puede hacer como máximo diez consultas DNS (RFC 7208, sección 4.6.4). Cuenta cada include, cada a, mx, ptr y exists, además del modificador redirect, y los cuenta en todo el árbol: un include que contiene otros tres cuesta cuatro. En la undécima consulta el receptor se detiene y devuelve permerror, que la mayoría trata exactamente igual que un registro SPF inexistente.
La trampa es que nada parece estar mal. El registro es corto, la sintaxis es válida, todos los servicios están. Se rompe el día en que un proveedor añade un include a su propio registro, algo que tú nunca ves. Por eso el generador muestra el coste junto a cada servicio, y por eso «Comprobar con DNS en vivo» vuelve a contar todo el árbol en el momento en que pulsas.
include:, a, mx, ptr, exists: y redirect=, cada aparición, también dentro de cada registro incluido. Un segundo límite, independiente, afecta a las consultas vacías (void lookups): nombres que no devuelven ningún registro. Más de dos también provocan un permerror.
ip4:, ip6: y all. Indicar tu propio servidor por su dirección en lugar de con a o mx ahorra una consulta cada vez, a cambio de tener que actualizar el registro si la dirección cambia.
Medido el 19 de octubre de 2026 contra DNS público, contado como lo hace un receptor. Un proveedor puede cambiar su registro cualquier día: toma estas cifras como una instantánea y deja la última palabra a la comprobación en vivo.
| Servicio | include | Consultas |
|---|---|---|
| Microsoft 365 | spf.protection.outlook.com |
1 |
| Google Workspace | _spf.google.com |
1 |
| IONOS | _spf-eu.ionos.com |
1 |
| Brevo | spf.brevo.com |
1 |
| SendGrid | sendgrid.net |
2 |
| Proton Mail | _spf.protonmail.ch |
2 |
| GoDaddy | secureserver.net |
3 |
| Namecheap Private Email | spf.privateemail.com |
4 |
| Mailgun | mailgun.org |
5 |
| Zoho Mail | zoho.com |
5 |
| Freshdesk | email.freshdesk.com |
7 |
Freshdesk por sí solo consume siete de diez. Junto con Zoho Mail y cualquier otro servicio, el registro supera el límite antes de incluir un solo servidor propio. El generador conoce 34 servicios con su coste medido; para un dominio que no conoce, la comprobación en vivo cuenta la cifra real.
El 19 de octubre de 2026 leímos los registros SPF de los 1.000 dominios .de mejor clasificados de la lista Tranco (lista 467YX), con las mismas reglas de recuento que usa el generador.
| Resultado | Dominios |
|---|---|
| Sin ningún registro SPF | 112 |
Termina en -all |
507 |
Termina en ~all |
320 |
Termina en ?all, que no protege nada |
22 |
Solo un redirect= a otro registro |
33 |
| Más de 10 consultas, SPF falla en todas partes | 17 |
| Entre 8 y 10 consultas, a un cambio del fallo | 144 |
| Más de 255 caracteres | 79 |
Diecisiete grandes dominios alemanes publican un registro SPF que ningún receptor puede evaluar, y casi uno de cada seis registros está entre ocho y diez consultas. Ninguno habría pasado por el generador sin un aviso. El método y los datos brutos están documentados; el recuento sigue exactamente el RFC 7208, como se describe arriba.
El último término indica a los receptores qué hacer con un servidor que no está en la lista.
~all (softfail) marca ese correo como sospechoso, pero pide al receptor que no lo rechace de inmediato. Es la opción correcta mientras sigues buscando todos los servicios que envían por ti: un remitente olvidado acaba en spam en lugar de desaparecer.
-all (fail) dice: quien no está en la lista no somos nosotros. Cámbialo cuando los informes agregados de DMARC de unas semanas ya no muestren ninguna fuente legítima que falle SPF. Con DMARC la diferencia se reduce, porque DMARC decide según su propia política; sin DMARC, -all es la afirmación más clara.
?all (neutral) y +all dejan el registro sin sentido. +all incluso autoriza a cualquier servidor de Internet a enviar como tu dominio. El generador ni siquiera lo ofrece.
ip4 con /33 o una dirección IPv6 en el campo IPv4 se omite del registro y se señala, en lugar de romperlo.SPF comprueba el remitente del sobre, la dirección que los servidores usan entre sí para las devoluciones. No comprueba la línea «De» que el lector ve en su programa de correo. Un mensaje falsificado puede superar SPF para el dominio del propio atacante y mostrar igualmente tu nombre en «De».
Ese hueco lo cierra DMARC: exige que el dominio de «De» coincida con un dominio que haya superado SPF o DKIM, y dice a los receptores qué hacer si no. Además, SPF se rompe al reenviar el correo, porque el servidor que reenvía no está en tu lista; una firma DKIM, en cambio, sobrevive al reenvío. Un dominio solo está bien protegido con los tres: SPF, DKIM y DMARC.
No. Un dominio puede publicar exactamente un registro TXT que empiece por v=spf1. Con dos o más, los receptores devuelven permerror e ignoran SPF por completo para ese dominio. Si varios servicios te piden que «añadas su registro SPF», junta sus include en un solo registro. Eso es justo lo que hace el generador.
Empieza con ~all mientras sigues reuniendo todos los servicios que envían por ti: un remitente olvidado acaba en spam en lugar de ser rechazado. Pasa a -all cuando los informes de DMARC muestren que todo el correo legítimo supera la comprobación. Con DMARC en quarantine o reject, su política pesa más que este calificador.
El receptor se detiene en la undécima consulta y devuelve permerror. La mayoría trata entonces el dominio como si no tuviera registro SPF, y DMARC solo puede superarse mediante DKIM. Quita los servicios que ya no uses, o sustituye un include por los rangos ip4 e ip6 que representa, sabiendo que tendrás que seguir tú mismo sus cambios.
No. El registro se crea en tu navegador. Solo los dos botones que necesitan DNS consultan a nuestro servidor: «Cargar registro publicado» lee el registro TXT público del dominio y «Comprobar con DNS en vivo» resuelve los include de tu registro. Ninguno de los dos lo guarda. El uso se cuenta por herramienta, sin tu dirección.
Espera a que el cambio llegue a los resolvers, normalmente unos minutos, a veces unas horas según el TTL del registro anterior. Después vuelve a cargar el registro aquí o ejecuta el Email Security Check, que revisa SPF junto con DKIM y DMARC. El DNS Checker muestra si los resolvers de todo el mundo ya ven el nuevo valor.
Solo si esos servidores envían correo. mx autoriza los servidores de tu registro MX, que reciben correo y a menudo no envían ninguno; a autoriza el servidor web, algo importante si un formulario de contacto o una tienda envían directamente desde él. Cada uno cuesta una consulta, así que deja fuera lo que no necesites.
No. SPF solo comprueba el remitente del sobre, no la dirección «De» que ve el lector. Sin DMARC, un atacante puede seguir poniendo tu dominio en la línea «De». SPF es el primero de tres registros; DKIM firma el mensaje y DMARC decide qué ocurre cuando ninguno de los dos coincide con tu dominio.
El registro se monta en el navegador a partir de los servicios, las direcciones y el calificador que elijas. El coste en consultas de los 34 servicios predefinidos se midió el 19 de octubre de 2026 resolviendo cada include de forma recursiva contra DNS público. Para cualquier otro include, el generador cuenta una consulta y marca el total como mínimo hasta que haces la comprobación en vivo.
«Cargar registro publicado» consulta los registros TXT del dominio a través de nuestro resolver y aplica el mismo validador que el Email Security Check, recuento recursivo incluido. «Comprobar con DNS en vivo» resuelve cada include del registro que has creado, en paralelo y con protección contra bucles, e indica el coste de cada uno: la cifra que un receptor ve hoy. Ambas peticiones cuentan para el límite diario de las herramientas gratuitas.
Lo que la herramienta no puede saber: qué servicios envían de verdad por tu dominio. Un servicio que envía con tu dirección y falta en el registro falla SPF, y ningún comprobador puede deducirlo solo del DNS. Los informes agregados de DMARC sí pueden. Por eso DMARC se configura justo después de SPF.