Encontraste un generador de registros SPF gratuito, marcaste todas las casillas, Google Workspace, Mailchimp y tu CRM, y pegaste el resultado directamente en el DNS. Dos semanas después, Gmail rechaza tus facturas con 550 5.7.26. Outlook devuelve 550 5.7.515. Tu cola de soporte está llena.
El generador produjo un resultado con una sintaxis válida. No produjo un registro operativo. Es justo en esa diferencia donde muere la entregabilidad. Si todavía estás montando toda la estructura DNS, empieza por configurar el correo en tu dominio; SPF forma parte de un conjunto más amplio con MX, DKIM y DMARC.
Esta guía explica por qué los generadores automatizados fallan en producción, cómo auditar sus resultados en cinco minutos con herramientas que ya tienes y qué aspecto presenta un registro SPF listo para producción.
Qué hace realmente un generador de registros SPF
Un generador de registros SPF es una herramienta web que crea un registro TXT de DNS concatenando mecanismos include: específicos de cada proveedor según las casillas seleccionadas. Eliges los remitentes y obtienes una cadena. No consulta tu DNS activo, no cuenta las consultas recursivas ni sabe cuántos registros SPF tiene ya tu dominio.
La mayoría de los generadores gratuitos son simples ensambladores de cadenas: producen algo que parece correcto sin comprobar que funcione en tu entorno DNS real. El resultado es sintácticamente correcto. Eso no significa que sea correcto desde el punto de vista operativo.
Los 3 fallos que pasan por alto todos los generadores de SPF
Todos los grandes fallos de SPF en producción se deben a uno de tres problemas. Un generador convencional no ve ninguno, porque trabaja sin acceso a los datos de tu DNS activo ni a la lógica de recuento que usan los receptores durante la evaluación.
1. PermError por un registro doble
Un dominio debe tener exactamente un registro SPF. La norma RFC 7208 es clara: si el servidor receptor encuentra dos registros TXT que empiezan por v=spf1, devuelve PermError, un fallo permanente. Gmail y Yahoo tratan PermError como si no hubiera ningún SPF. Tus correos se rechazan o se envían discretamente al spam.
Los generadores nunca comprueban si ya existe un registro. Si tu dominio lleva activo más de unos meses, es muy probable que ya tenga uno, creado por el registrador, el proveedor anterior o quien configuró Google Workspace hace tres años. Publicar el resultado del generador sin comprobarlo crea el duplicado. Acabas de romper algo que funcionaba.
2. El límite de consultas recursivas
RFC 7208 limita la evaluación de SPF a exactamente 10 consultas DNS. El recuento incluye cada include:, a, mx, exists y redirect, además de todas las consultas anidadas que activen esos include. Un generador cuenta los mecanismos seleccionados. No cuenta lo que contienen.
| Proveedor seleccionado | Recuento del generador | Consultas reales |
|---|---|---|
| Google Workspace | 1 | 4 (_netblocks.google.com anidados, etc.) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| Total | 4 | 10-12 → PermError |
El generador muestra 4 consultas. El servidor receptor llega a la n.º 11 y se detiene. Todos los mensajes de tu dominio fallan en SPF. No hay ninguna advertencia en la interfaz ni correo de rechazo. Te enteras por los clientes molestos.
3. El límite de consultas vacías (RFC 7208 §11.1)
Hay una restricción secundaria: no se permiten más de 2 consultas DNS que devuelvan resultados vacíos (NXDOMAIN). Un solo error tipográfico en un include: crea una consulta vacía. Con dos errores de este tipo, todo el registro SPF falla, aunque la comprobación sintáctica del generador lo haya aprobado.
Situación:
include:spf.trekmaill.net(una 'l' adicional). La sintaxis es válida. El generador lo marca como correcto. El servidor receptor hace una consulta, no encuentra nada y registra la consulta vacía n.º 1. Basta un segundo include incorrecto para que todo el registro falle.
Cómo auditar el resultado antes de publicarlo
Antes de publicar lo que haya producido tu generador, ejecuta estas tres comprobaciones en el DNS activo. Se tarda cinco minutos y se detectan todos los problemas críticos que el generador pasó por alto: registros duplicados, profundidad excesiva de consultas y sintaxis incorrecta. Funciona en macOS, Linux y el Símbolo del sistema de Windows.
Paso 1: comprueba si ya existe un registro
Ejecuta esto antes de hacer cambios en el DNS:
nslookup -type=txt yourdomain.comSi ves dos líneas que empiezan por v=spf1, tienes un duplicado. Combínalas manualmente en un solo registro antes de publicar nada nuevo.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allPaso 2: cuenta las consultas recursivas
Consulta el contenido de cada include: de tu registro:
dig +short txt _spf.google.comResultado:
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"Ese solo include:_spf.google.com activa 4 consultas reales. Repite el proceso con cada proveedor del registro y súmalas. Si el total supera 10, necesitas reestructurarlo, normalmente trasladando el correo transaccional a un subdominio (send.yourdomain.com) con su propio registro más corto.
Paso 3: audita los mecanismos
Compara la cadena producida por el generador con esta tabla:
| Mecanismo | Estado | Acción |
|---|---|---|
ptr | Obsoleto | Elimínalo. RFC 7208 desaconseja expresamente su uso. Es lento y poco fiable. |
+all | Inseguro | Elimínalo. Autoriza a todo internet a enviar como tu dominio. |
ip4: 1.2.3.4 | Sintaxis no válida | Elimina el espacio. Debe ser ip4:1.2.3.4. |
?all | Débil | Evítalo. Una política neutral no protege contra la suplantación. |
~all | Aceptable | SoftFail. Úsalo solo durante migraciones, no como configuración permanente. |
-all | Correcto | HardFail. Los remitentes no autorizados se rechazan. Úsalo en producción. |
Lista de comprobación de sintaxis SPF
Tanto si usaste un generador para el primer borrador como si escribiste la cadena a mano, revisa esta lista antes de tocar el DNS. Las comprobaciones cubren todos los fallos que un generador no puede detectar: registros duplicados, límites de consultas recursivas y opciones de política inseguras.
- Un registro por dominio. Si existe un duplicado, combínalos. Nunca publiques dos.
- Empieza por
v=spf1. Sin variaciones. La cadena exacta. - Termina en
-allo~all. Nunca en+allo?all. - Las IP antes de los include. Los mecanismos
ip4:eip6:no consumen consultas DNS. Ponlos primero para agilizar la evaluación. - Sin referencias a sí mismo.
include:yourdomain.comcrea un bucle infinito. Elimínalo. - No aplanes las IP manualmente salvo que cuentes con automatización para mantenerlas actualizadas. Si Google cambia sus IP y tú no actualizas el registro, el correo deja de funcionar sin avisar.
- Total de consultas ≤ 10. Cuéntalas todas, incluidos los include anidados.
Un registro listo para producción:
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allPrimero las IP (sin coste de consultas), después los include y al final el fallo estricto. Eso es todo.
Por qué las agencias y pymes superan las posibilidades de los generadores SPF
Un generador funciona para un solo dominio con uno o dos remitentes. Al aumentar la escala, con agencias que gestionan decenas de clientes o pymes con una amplia gama de SaaS, se convierte en un riesgo operativo recurrente sin visibilidad centralizada de las consultas o los registros duplicados de toda la cartera.
El método antiguo: un registro SPF único por cliente, cada uno procedente de una sesión distinta del generador y sin registro de auditoría. Un dominio alcanza el límite de consultas. Pasan tres días antes de que alguien lo note. La reputación de entrega del cliente sufre las consecuencias.
Para obtener una visión completa de la protección de la infraestructura de correo en una empresa, consulta la guía sobre seguridad del correo empresarial, que presenta toda la base necesaria más allá de SPF.
Cómo elimina TrekMail el problema de los generadores SPF
La complejidad de SPF surge al gestionar varios remitentes de terceros y mantenerse por debajo del límite de 10 consultas. TrekMail elimina ambos problemas para tu infraestructura de correo principal, lo que evita tener que ejecutar un generador, contar consultas anidadas o auditar mecanismos para el dominio de envío principal.
Para pymes: un include, sin mantenimiento
En el plan Starter de TrekMail ($3.50/mo), la entrega saliente se realiza mediante el SMTP gestionado de TrekMail. Tu registro SPF se reduce a una sola línea:
v=spf1 include:spf.trekmail.net -allTrekMail gestiona la rotación de IP y la reputación del remitente tras ese include. No necesitas modificar el registro de forma habitual. No hace falta usar un generador ni repetir una auditoría de consultas seis meses después al incorporar una nueva herramienta SaaS.
Para agencias: una plantilla para cada cliente
El método antiguo: 100 clientes, 100 registros SPF procedentes de 100 ejecuciones distintas del generador, cada uno con su propio riesgo de consultas recursivas. Cualquiera puede fallar sin avisarte.
El método TrekMail: una plantilla para todos los dominios de clientes:
v=spf1 include:spf.trekmail.net -allEn el plan Agency ($23.25/mo), puedes gestionar 1,000+ dominios desde un solo panel. Estandarizar el correo corporativo en TrekMail elimina el problema de las consultas recursivas en el canal de comunicación principal. Si estás ampliando una configuración multidominio, descubre cómo el alojamiento de correo multidominio cambia el modelo de gestión.
Para conocer toda la configuración DNS que TrekMail espera junto con SPF, incluidos MX, DKIM y DMARC, el documento sobre registros DNS necesarios explica los cuatro en un solo lugar.
Preguntas frecuentes sobre generadores de registros SPF
Estas son las preguntas que surgen cuando la primera sesión con un generador produce un registro que no funciona. Todas se remontan a la diferencia entre la validación sintáctica, que realiza el generador, y la validación operativa, que exige consultar el DNS activo.
¿Puedo usar dos generadores para comparar los resultados?
Puedes hacerlo, pero un segundo generador no resuelve el problema fundamental. Dos herramientas distintas darán dos cadenas distintas, y ninguna detectará los registros duplicados del DNS activo ni contará con precisión las consultas recursivas. Los pasos de CLI anteriores ofrecen una comprobación fiable.
El generador dice que el registro es válido. ¿Por qué se rechaza el correo?
Para un generador de SPF, "válido" significa que la sintaxis es correcta, no que el registro funcione en tu entorno. Las dos causas más comunes de esta discrepancia son un registro duplicado que provoca PermError o más de 10 consultas recursivas. Ambas exigen consultar el DNS activo, no solo validar el resultado en una interfaz.
¿Cuándo debo usar -all y cuándo ~all?
Usa -all (HardFail) en producción: los remitentes no autorizados se rechazan. Usa ~all (SoftFail) solo durante una migración si no sabes con certeza si has incluido a todos los remitentes. Es un estado temporal, no el objetivo final. Un generador que utiliza de forma predeterminada ?all o +all prioriza que el registro parezca funcionar por encima de la entregabilidad real.
Resumen
Un generador gratuito es un punto de partida razonable para redactar la cadena SPF, pero no un buen punto final para producción. Los tres fallos que pasa por alto, registros duplicados, exceso de consultas recursivas y errores de consultas vacías, provocan rechazos silenciosos y PermError que pueden llevar horas de diagnóstico.
La solución no es un generador mejor. Es una auditoría de cinco minutos mediante la CLI: busca registros duplicados, cuenta las consultas anidadas y revisa los mecanismos. Después, publica.
Si prefieres omitir por completo el proceso del generador, TrekMail consolida los envíos salientes en un solo include:. Una línea en el DNS. Sin cálculos de consultas. Sin depurar PermError.
Inicia una prueba gratuita de 14 días; se requiere tarjeta de crédito y puedes cancelar en cualquier momento.
