Registro SPF: configuración, ejemplos y errores comunes

Si preparas una infraestructura de correo en 2026, el registro SPF es una pieza importante de la autenticación. Una configuración incorrecta puede contribuir al spam o al rechazo, pero SPF no determina por sí solo si el mensaje llega a la bandeja de entrada.

Desde febrero de 2024, Google y Yahoo aplican requisitos de autenticación más exigentes al tráfico correspondiente. Un SPF ausente o incorrecto puede intervenir en rechazos como SMTP 550, según la política y las demás verificaciones, sin que todos los mensajes sin SPF reciban necesariamente esa respuesta.

Para una empresa con un solo dominio, el problema puede afectar a una presentación para inversores. Para un proveedor que administra 500 dominios de clientes, puede generar una mañana de lunes llena de consultas sobre envíos a Gmail. Una revisión previa reduce riesgos, aunque no evita todas las incidencias.

Esta guía explica qué hace SPF, cómo construir el registro, qué errores pueden afectar al correo y cómo mantener la configuración cuando gestionas muchos dominios.

Qué es SPF y qué no hace

Sender Policy Framework (SPF) es un protocolo de autorización basado en DNS, definido en el RFC 7208. Publica una política que permite al receptor comprobar qué servidores están autorizados para una identidad SMTP determinada. No es un escudo general de seguridad ni autentica todo el contenido.

Cómo funciona la comprobación

Cuando Gmail recibe un mensaje de alice@yourcompany.com, SPF no comprueba directamente el From que ves en la interfaz. Evalúa el dominio del remitente del sobre SMTP, reflejado en Return-Path al entregar el mensaje, o HELO cuando corresponde. Consulta su política DNS y compara la IP de la conexión con las autorizaciones.

Si una regla de autorización coincide, SPF puede pasar. Si la evaluación llega a SoftFail (~all) o HardFail (-all), devuelve ese resultado. No son órdenes automáticas de aceptación o rechazo; también existen otros resultados y decide el receptor.

La diferencia entre From y Return-Path

El 90% citado en el texto de origen es una ilustración, no una estadística medida. La distinción importante es que SPF no comprueba directamente el From visible en Outlook o Apple Mail, sino la identidad SMTP correspondiente.

La dificultad: Mailchimp puede usar un Return-Path propio para gestionar rebotes, como bounce-mc.us1.mailchimp.com. El receptor consulta entonces SPF de Mailchimp, no necesariamente el de tu dominio. Tu registro puede ser válido y no participar en ese envío.

Por eso SPF solo no basta para verificar la identidad visible. Consulta cómo interactúan SPF, DKIM y DMARC en la guía de configuración de autenticación del correo.

Por qué sigue siendo necesario

SPF complementa DKIM y DMARC. Su ausencia puede incumplir requisitos aplicables; Microsoft puede devolver 550 5.7.515 Access Denied en determinados flujos sujetos a sus reglas de autenticación. No atribuyas ese código universalmente a SPF ni prescindas de la revisión técnica.

Configuración básica con un proveedor

Una pequeña empresa que envía con TrekMail, Google Workspace o Microsoft 365, quizá junto a una herramienta de marketing, necesita una política SPF coherente para cada dominio SMTP utilizado. Con pocos servicios puede resultar sencilla, pero conviene evitar un error frecuente.

Regla básica: como máximo un registro SPF aplicable por nombre de dominio; si publicas SPF, debe ser uno solo.

Al añadir un servicio, no publiques un segundo TXT que empiece con SPF en el mismo nombre. Varios registros SPF aplicables producen PermError; el receptor no los combina automáticamente. Otros registros TXT ajenos a SPF sí pueden coexistir.

Componentes de un registro

Consulta la guía de configuración SPF para ejemplos paso a paso. Valida las plantillas con las instrucciones actuales de cada proveedor antes de publicarlas.

TrekMail para pequeñas empresas

El texto de origen compara Google Workspace a $6-$18 por usuario al mes con diez usuarios a $720-$2,160 al año. También cita Starter de TrekMail a $3.50 al mes con hasta 100 usuarios. Son referencias ilustrativas, no cotizaciones actuales. Añadir include:spf.trekmail.net puede formar parte del SPF si corresponde al transporte utilizado; exige revisar todos los remitentes y el resto de la autenticación. El modelo de tarifa fija depende de los límites y condiciones vigentes, no garantiza correo funcional con una sola línea.

Varios proveedores: el caso de las agencias

Una agencia con decenas de dominios puede encontrar HubSpot para ventas, Zendesk para soporte, Klaviyo para marketing y TrekMail para correo corporativo. Inventaría cada flujo: no todos requieren aparecer en el SPF raíz si utilizan dominios de sobre distintos.

Combina los servicios que realmente usan la misma identidad SMTP en una política, respetando el límite de 10 consultas aplicable a los términos evaluados.

El límite de 10 consultas

El RFC 7208 §4.6.4 limita a 10 los mecanismos y modificadores evaluados que requieren consultas DNS, incluidos los anidados. No cuenta paquetes DNS individuales. Esta restricción limita el trabajo de evaluación y posibles abusos, pero también puede afectar a configuraciones legítimas.

Términos que consumen presupuesto: include:, a, mx, exists, redirect. La lista no es exhaustiva: ptr también consume este presupuesto.

Términos que no consumen ese presupuesto: ip4:, ip6:, all

El problema de los include anidados

Añadir include:bluehost.com parece consumir 1 término. Como ejemplo hipotético, si esa política evalúa también spf.protection.outlook.com y mail.bluehost.com, podrían evaluarse tres términos. Además, spf.protection.outlook.com puede tener su propia cadena. No presupongas que este ejemplo refleja los registros actuales ni que se recorre siempre toda la cadena.

Si la evaluación supera 10 términos pertinentes, devuelve PermError, distinto de fail. El receptor puede rechazar o filtrar según su política; no significa necesariamente pérdida silenciosa de todo el correo.

Cómo revisar el consumo

No lo adivines. Utiliza herramientas de línea de comandos o un visualizador fiable. En Mac o Linux:

dig +short txt yourdomain.com

Consulta después los dominios de cada include: y sigue la evaluación correspondiente, incluidos modificadores y términos anidados. La guía sobre límites y consultas del registro SPF explica cómo auditar las dependencias y corregir excesos.

Aplanamiento o separación por subdominios

Si tu configuración se acerca al límite de 10 o lo supera, puedes evaluar estas dos opciones. No todas las agencias llegan necesariamente a ese límite.

Opción 1: aplanamiento SPF, con mantenimiento

Aplanar significa resolver dependencias include: y sustituirlas por autorizaciones IP explícitas, como ip4:. Los términos ip4: no consumen ese presupuesto; cientos de direcciones aún pueden plantear límites de tamaño y mantenimiento. No es una sustitución mecánica válida de cualquier política SPF.

El riesgo: HubSpot, Klaviyo y otros servicios pueden cambiar sus IP. Al cabo de unos meses, una lista fija podría quedarse obsoleta: dejar de autorizar servidores nuevos o conservar direcciones que ya no deberían estar permitidas.

Si eliges aplanar, necesitas un proceso fiable para detectar cambios, revisar las autorizaciones, actualizar DNS y comprobar resultados. La automatización puede ayudar, pero no elimina los riesgos ni sustituye supervisión y reversión.

Opción 2: separación por subdominios

Otra opción es repartir identidades de envío entre subdominios. SPF evalúa el dominio del sobre SMTP, reflejado en Return-Path: ese dominio debe cambiar realmente para que la separación surta efecto.

¿Marketing necesita usar team@company.com o puede utilizar news@marketing.company.com? Cambiar el From visible no basta: configura también la identidad técnica apropiada.

Dominio raíz (company.com) - Mantén una política adecuada al correo corporativo y servicios esenciales. Ejemplo ilustrativo que debes verificar:

v=spf1 include:spf.trekmail.net -all

Subdominio de marketing (marketing.company.com) - Configura aquí los servicios que realmente usan este dominio de sobre. Ejemplo, no registro listo para publicar:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Cada evaluación de un dominio de sobre distinto tiene un presupuesto de 10 términos. Comprueba el alineamiento DMARC relajado o estricto. Separar marketing.company.com facilita la gestión, pero no protege de forma absoluta el correo del director: los receptores pueden agregar reputación por dominio organizativo o IP.

Consulta las plantillas de configuración SPF y la guía de configuración para varios remitentes. Adapta los ejemplos al inventario y a los registros actuales de los proveedores.

Validación después de publicar

Guardar el registro en el editor DNS no termina el trabajo. Estas comprobaciones ayudan a verificar la publicación y los envíos reales.

1. Comprobar la actualización DNS

Los cambios pueden tardar minutos u horas, según publicación y cachés TTL. Además de tu caché local, consulta un resolvedor público y, cuando corresponda, los servidores autoritativos:

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 selecciona el resolvedor público de Google, que también puede tener caché. Ver allí el registro confirma esa respuesta, no la actualización inmediata de todos los resolvedores del mundo.

2. Validar la sintaxis

Revisa errores de sintaxis y reglas que pueden alterar la evaluación:

• Espacio antes de v=spf1, que puede impedir identificar correctamente el registro.
• ip4: 192.1.1.1 - El espacio después de los dos puntos es incorrecto.
• Varios mecanismos all: el primero coincide siempre y los términos posteriores no se evalúan.
• Entradas include: duplicadas: pueden desperdiciar presupuesto en el recorrido evaluado aunque no sean siempre un error sintáctico.

Usa un validador antes de dar la configuración por terminada. El asistente DNS de TrekMail puede ayudar a detectar problemas según sus comprobaciones disponibles; valida también el resultado publicado.

3. El límite de consultas sin resultado

El RFC 7208 recomienda limitar a 2 las consultas sin resultado, como NXDOMAIN o una respuesta sin registros pertinentes. Es un límite distinto del presupuesto general, y superarlo, no alcanzarlo, puede causar PermError.

Por ejemplo, include:spf.trekmaill.net contiene una letra adicional. Si no existe, una consulta podría representar 1 resultado vacío; sin embargo, un include sin política SPF puede causar PermError por sí mismo. Dos erratas no son una demostración universal de superar el límite de consultas vacías.

Comprueba las respuestas DNS, no solo la forma del texto: una política puede tener sintaxis correcta y dependencias inexistentes.

4. Analizar las cabeceras de un envío real

Envía a una cuenta Gmail que controles. En el menú de tres puntos, abre «Mostrar original» y busca Authentication-Results añadido por el servidor receptor de confianza. Un resultado ilustrativo es:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral o spf=softfail merece revisión si esperabas pass, pero puede corresponder a la política o a un reenvío. Comprueba la IP, el dominio evaluado y la ruta; no implica automáticamente fallo de DMARC si existe DKIM válido y alineado. Consulta la comprobación del estado DNS.

Errores que afectan al correo

Estos patrones aparecen en incidencias de SPF. Conocerlos ayuda a investigar, sin afirmar que representen una proporción medida de todos los casos.

1. SPF y reenvío

SPF compara la IP de la conexión con la política de la identidad SMTP. Esa dependencia puede complicar el reenvío.

Alice envía a Bob, que reenvía a Charlie. Si se conserva el remitente del sobre de Alice, Charlie evalúa la IP de Bob frente a esa política y SPF puede fallar aunque el mensaje sea legítimo. El resultado depende de la autorización y de cómo se implemente el reenvío.

SPF por sí solo no resuelve todos los casos. DKIM firma datos determinados del cuerpo y las cabeceras; puede sobrevivir si no se modifican de forma incompatible. Para DMARC debe seguir siendo válido y alineado. SRS puede autorizar el dominio de sobre del intermediario, pero no restaura por sí solo el alineamiento con el From original.

Consulta cómo interactúan SPF, DKIM y SRS en el reenvío de correo de dominio, sin presumir entregabilidad garantizada.

2. El mecanismo ptr

A principios de los años 2000 se utilizaba el mecanismo ptr, basado en DNS inverso:

v=spf1 ptr -all

El RFC desaconseja ptr por su coste y sus limitaciones. Eso no significa que Gmail ignore universalmente cualquier política que lo contenga. Si heredas un registro con ptr, revisa sus autorizaciones y sustitúyelo de forma probada; no lo confundas con el PTR del servidor, que tiene otra función.

3. El riesgo de +all

Este ejemplo sigue ilustrando una configuración peligrosa; no lo publiques:

v=spf1 include:spf.google.com +all

Los calificadores significan:

• -all = HardFail para las IP que llegan a este término; el receptor decide si rechaza.
• ~all = SoftFail para esas IP; no impone aceptación con una marca.
• +all = Pass para cualquier IP cuya evaluación llegue a ese término.

+all puede autorizar IP arbitrarias para la identidad SPF evaluada y facilitar abusos. Las reglas negativas o errores anteriores aún pueden intervenir, y el receptor aplica otras verificaciones; no garantiza una suplantación exitosa. Una política con +all necesita revisión. Sustituye +all por una política limitada, como -all, después de inventariar y probar remitentes legítimos.

4. Return-Path de servicios externos

Una herramienta de marketing puede usar su propio dominio de rebotes sin que falte Return-Path. El dominio de seguimiento no es necesariamente el dominio de sobre personalizado. Para SPF alineado, el dominio evaluado debe alinearse con From, de manera organizativa en modo relajado o exacta en estricto. DMARC también puede pasar mediante DKIM válido y alineado.

Algunos proveedores permiten configurar un subdominio de retorno, como bounce.yourcompany.com. Comprueba soporte, instrucciones y modo de alineación; no es siempre obligatorio si DKIM ya aporta una vía alineada. Consulta alineación DMARC y reputación del dominio.

Generadores: utilidad y precauciones

Los generadores SPF varían en alcance y calidad. Pueden ayudar, pero necesitas revisar qué comprueban y qué información les proporcionas.

Herramientas útiles

Los visualizadores de cadenas include: ayudan a auditar dependencias y términos evaluados. Algunas herramientas de entregabilidad del correo ofrecen esta función; confirma que cubran el recorrido relevante.

Los validadores de sintaxis detectan ciertos errores de separadores y caracteres. Para dependencias inexistentes y consultas vacías también hace falta evaluación DNS, no solo análisis del texto.

Aspectos que debes revisar

Un asistente de un clic puede generar ?all, que devuelve Neutral para las IP que llegan a ese término. No equivale a pass ni demuestra universalmente desconfianza. Elige -all o ~all según inventario, pruebas y objetivos; no des por segura la salida predeterminada.

División de cadenas TXT: cada cadena admite hasta 255 octetos. Un SPF largo puede ocupar varias cadenas entrecomilladas dentro de un único registro. El receptor las concatena sin insertar espacios, así que deben conservar los separadores necesarios:

• Estructura correcta: "v=spf1 include:a..." "include:b... -all" representa dos cadenas en un registro, pero el ejemplo abreviado necesita un separador adecuado al concatenarse.
• Incorrecto: dos registros TXT SPF independientes causan PermError.

Comprueba cómo publica tu proveedor DNS las cadenas y valida el texto concatenado. Un generador puede dividirlas incorrectamente y producir sintaxis inválida.

Consulta la guía de herramientas y configuración SPF para orientar la revisión; no presupongas que toda herramienta mencionada está validada para tu caso.

Configuración y centralización con TrekMail

Las suites grandes ofrecen funciones que unos clientes necesitan y otros no. Algunos planes cobran por usuario; compara prestaciones, contratos y necesidades, sin asumir que todos incluyen servicios innecesarios.

Si TrekMail es el único transporte autorizado, este patrón puede servir como ejemplo, previa verificación de las instrucciones actuales:

v=spf1 include:spf.trekmail.net -all

No es una política completa para cualquier dominio por el mero hecho de alojarlo en TrekMail: puede haber otros remitentes o SMTP externo. La infraestructura administrada puede encargarse de IP, PTR y recursos de retroalimentación según su alcance. Eso no elimina la preparación gradual de los flujos, la revisión de abuso ni garantiza la entrega.

Un proveedor con 50 dominios que comparten exclusivamente el mismo transporte podría utilizar 50 políticas equivalentes. La estandarización ayuda cuando has repetido una configuración cien veces, pero cada cliente necesita inventario y validación propios. El modelo sin cobro por asiento depende del plan y no elimina variaciones legítimas entre dominios.

Para una migración, consulta la introducción a la migración IMAP y los registros DNS necesarios. IMAP copia datos de buzones accesibles; MX, SPF, DKIM y DMARC se revisan por separado con pruebas y un plan de transición. La importación masiva de dominios puede estar disponible según el panel y el plan: consulta cómo importar dominios.

Buenas prácticas para SPF

Los requisitos de autenticación se endurecieron en 2024 para determinados servicios y volúmenes. Un registro SPF adecuado ayuda a cumplirlos, pero su ausencia o validez no determina por sí sola el destino de todo correo legítimo.

Resumen de las comprobaciones:

1. Audita la publicación. Ejecuta dig +short txt yourdomain.com y distingue los registros SPF de otros TXT. Varios SPF aplicables, no simplemente varios TXT, causan PermError.
2. Combina las autorizaciones pertinentes. Una política SPF por nombre para los servicios que usan ese dominio de sobre, con cadenas TXT bien concatenadas.
3. Cuenta los términos evaluados. Usa un visualizador. Si superas 10, considera reducir dependencias o separar identidades por subdominio; aplanar exige mantenimiento.
4. Evalúa -all. Puedes pasar de ~all tras inventario y pruebas. Sustituye +all por autorizaciones limitadas sin interrumpir remitentes legítimos.
5. Comprueba Return-Path y alineación. Para Mailchimp o HubSpot, evalúa un dominio de rebotes personalizado cuando corresponda. DMARC necesita SPF aprobado y alineado o alguna firma DKIM válida y alineada.
6. No te quedes en SPF. El reenvío puede afectar a SPF y también a DKIM si altera datos firmados. Configura los tres: SPF, DKIM y DMARC.

Un registro ilustrativo de 50 bytes merece la misma revisión que uno largo. Valida la configuración inicial y después de cambios; una revisión anual puede complementar el seguimiento, pero no sustituirlo.

Centraliza la gestión DNS cuando resulte útil. Consulta la opción gratuita de TrekMail y las condiciones actuales de su alojamiento de tarifa fija y herramientas SPF, DKIM y DMARC.