Crear un registro SPF: organiza los remitentes y controla las consultas

Si necesitas crear un registro SPF para un dominio, el objetivo es sencillo: autorizar a los remitentes correctos sin crear un lío en el DNS que acabe fallando meses después. Muchos problemas empiezan igual. Añades un proveedor. Después otro. Entonces Microsoft devuelve un 550 5.7.515, Google un 550 5.7.26 y terminas revisando registros TXT a las 11 de la noche.

Ese es el problema. SPF parece fácil hasta que deja de serlo. El registro del dominio raíz se convierte en un cajón de sastre, los includes recursivos se acumulan y una evaluación adicional puede llevarlo a PermError. Si administras un dominio empresarial, los servicios de un cliente o varias marcas, no es un detalle menor: puede perjudicar la entrega, aunque PermError no implique un rechazo automático. Para entender mejor la configuración del dominio, empieza por correo empresarial para pequeñas empresas.

Esta guía presenta una arquitectura más sostenible: mantener el correo corporativo en el dominio raíz, separar el correo masivo y de aplicaciones mediante subdominios de envío efectivos y tratar el presupuesto de consultas como un recurso limitado. Así puedes crear registros SPF más fáciles de mantener, aunque tendrás que revisarlos cuando cambien los remitentes.

Por qué fallan tantos registros SPF

SPF falla porque los receptores limitan los términos que provocan consultas DNS durante la evaluación. Si creas un registro SPF acumulando demasiados includes en un dominio, puedes superar ese límite, obtener PermError y provocar problemas de entrega o rechazos según la política del receptor, aunque la sintaxis parezca correcta.

El RFC 7208 lo establece claramente. Entre los términos que provocan consultas DNS están include, a, mx, ptr, exists y redirect. Los receptores deben limitar a 10 los términos de este tipo evaluados, incluidos los recursivos; no es un recuento de todos los paquetes DNS. Superar el límite produce un error permanente, no una advertencia. El RFC también establece que varios registros SPF en un mismo nombre de dominio producen PermError; otros registros TXT ajenos a SPF pueden coexistir.

Por eso el consejo habitual se queda corto. Muchas guías recomiendan crear un registro SPF metiendo todos los remitentes en un valor TXT en @. Parece ordenado, pero convierte el dominio raíz en una infraestructura compartida por boletines, sistemas de soporte, avisos de aplicaciones, herramientas de prospección y buzones de personas. Si un proveedor amplía su cadena de includes, puede afectar a todos los envíos que utilicen esa política.

Un mal patrón: un único registro SPF raíz que intenta autorizar todas las herramientas que la empresa ha utilizado alguna vez.

Las recomendaciones de Google para remitentes también destacan la importancia de autenticar correctamente el correo y cuidar la alineación, especialmente en los envíos masivos. SPF es solo una parte del conjunto, pero un fallo de SPF suele ser el primer síntoma visible.

La verdadera restricción: el presupuesto de 10 consultas

La regla es esta: al crear la política SPF, dispones de un presupuesto fijo de 10 términos evaluados que provocan consultas DNS. El cómputo es recursivo. Si un include lleva a más términos de este tipo y se evalúan, también cuentan. Tu proveedor DNS no corrige una política SPF mal dimensionada.

Qué cuenta para el presupuesto:

• include
• a
• mx
• ptr (evítalo)
• exists
• redirect

Qué no cuenta para el presupuesto:

• ip4
• ip6
• all

También importan las consultas vacías. El RFC 7208 recomienda que los receptores las limiten a dos. Una errata en el destino de un include puede consumir parte de ese margen. Superar el límite recomendado, no simplemente alcanzarlo, puede producir otro PermError.

Si necesitas crear un registro SPF para un dominio que envía mediante varios proveedores, conviene calcular el presupuesto real. El riesgo no depende solo de cuántos proveedores haya, sino de los términos que se evalúan en sus políticas y de tu arquitectura.

Crear un registro SPF con una arquitectura separada

Una forma de reducir el riesgo es separar el correo entre personas del correo masivo o de aplicaciones. Mantén el proveedor principal de buzones en el dominio raíz y configura los remitentes especializados con subdominios que realmente utilicen en MAIL FROM o return-path. Cambiar únicamente el From visible no separa el presupuesto SPF. También debes conservar la alineación DMARC mediante SPF o DKIM, según el modo estricto o relajado.

El patrón es este:

1. Dominio raíz @ para el correo entre personas.
2. Subdominios de MAIL FROM o return-path para boletines, soporte, alertas transaccionales y otros remitentes especializados.
3. Un registro SPF por nombre de host, sin duplicados ni políticas antiguas. Pueden existir otros TXT que no sean SPF.

Ejemplo de registro raíz para el envío gestionado de TrekMail, sujeto a su configuración vigente:

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

Es una política fácil de revisar: un include y una terminación explícita. Ese include puede tener dependencias recursivas; comprueba su coste efectivo.

Ejemplo ilustrativo para un subdominio de marketing, que debe contrastarse con las instrucciones oficiales actuales de cada proveedor:

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

Mailchimp y HubSpot solo consumen el presupuesto de marketing.example.com si ese es el dominio de MAIL FROM o return-path que utilizan realmente y su configuración admite este esquema. En ese caso, sus cambios de SPF no afectan directamente a la política de example.com; la alineación DMARC sigue necesitando una configuración adecuada.

TrekMail también encaja en este esquema. Su documentación de dominios presenta include:spf.trekmail.net como include básico para el envío gestionado, y su comprobador DNS puede ayudar a detectar conflictos; no sustituye una verificación completa. Si estás configurando buzones y DNS, consulta Añadir un dominio a TrekMail y Comprobar el estado del DNS.

Paso a paso: crear registros SPF sin improvisar

Para crear registros SPF mantenibles, primero haz un inventario de todos los remitentes, asigna a cada uno el nombre de host adecuado y después prepara el registro TXT. No empieces por el DNS, sino por identificar quién envía y con qué dominio de sobre. Así evitarás acumular includes arbitrarios en el dominio raíz.

Sigue este proceso:

1. Enumera todos los servicios que envían correo utilizando tu dominio.
2. Clasifica cada remitente como corporativo, transaccional, de soporte o de marketing.
3. Decide qué nombre de host de MAIL FROM debe utilizar cada uno y verifica la alineación DMARC.
4. Utiliza la política SPF mínima que autorice todos los envíos legítimos de ese host.
5. Publica un registro TXT de SPF por host; otros TXT ajenos a SPF pueden coexistir.

Después prepara el registro real, siguiendo las instrucciones oficiales vigentes del proveedor y su configuración de MAIL FROM personalizado.

Ejemplo de SMTP gestionado de TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Ejemplo combinado de TrekMail y SMTP propio para Nano o configuraciones híbridas, no una receta universal:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

Si utilizas TrekMail con Nano, el modelo descrito requiere tu propio proveedor SMTP para enviar. Autoriza al proveedor que realmente entrega el correo y al dominio de sobre correspondiente; usar TrekMail como alojamiento no exige automáticamente incluir TrekMail y SES juntos. El ejemplo combinado solo sirve cuando ambos están justificados, y SES requiere seguir sus instrucciones de MAIL FROM personalizado. Según las condiciones descritas en el artículo, los planes de pago parten de $3.50/mes e incluyen SMTP gestionado. Nano se describe como gratuito, sujeto a las condiciones vigentes. Los planes de pago también ofrecen una prueba gratuita de 14 días que requiere tarjeta de crédito. Comprueba las condiciones vigentes y consulta SMTP propio (BYO) y SMTP gestionado de TrekMail.

Publicar y verificar el registro

Después de crear el registro SPF, publícalo como TXT y comprueba qué devuelve el DNS público. No te fíes únicamente de la interfaz del registrador, de un panel con información en caché o del indicador verde de una herramienta. Consulta el dominio y confirma que solo hay un registro SPF válido. Estas herramientas suelen consultar un resolutor con caché, no garantizan una respuesta directa de los servidores autoritativos ni un plazo exacto de propagación.

Mac o Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Debes encontrar un único valor SPF que empiece por v=spf1, sin otra política SPF duplicada ni una antigua olvidada tras una migración. Otros valores TXT no relacionados con SPF son compatibles.

Comprobaciones rápidas:

• Empieza por v=spf1
• Termina en -all cuando hayas completado el inventario de remitentes y las pruebas
• Incluye solo los remitentes que realmente utilizas
• Hay una única política SPF por host, no varias

Al cambiar de proveedor, conviene revisar los registros anteriores: pueden quedar MX y SPF que ya no corresponden a la configuración prevista. La documentación DNS de TrekMail trata estos casos. Si estás migrando toda la plataforma, pueden ayudarte estas guías: cómo crear correo con dominio propio y alojamiento de correo para varios dominios.

Errores habituales de SPF y cómo resolverlos

Muchos fallos de SPF se deben a demasiados términos evaluados que provocan consultas, registros SPF duplicados, dominios de envío incorrectos o erratas en includes. Un mapa claro de remitentes facilita detectarlos. Improvisar suele encarecer el diagnóstico.

Estas reglas prácticas evitan muchos problemas:

1. Utiliza ip4 para remitentes estáticos bajo tu control. No consume términos del presupuesto de consultas.
2. Separa el MAIL FROM del correo de marketing y el del correo directivo cuando el proveedor lo permita, manteniendo la alineación DMARC.

La documentación de Google acierta al presentar el objetivo completo: autenticación y alineación, no SPF por separado. SPF puede pasar y el correo incumplir DMARC si el dominio del From visible no se alinea con el dominio de sobre autenticado, según el modo estricto o relajado, y no existe una firma DKIM alineada que pase. Consulta las preguntas frecuentes de Google sobre las directrices para remitentes si investigas problemas de entrega masiva.

Cuándo puede facilitarte el trabajo TrekMail

TrekMail puede ayudar a mantener una configuración uniforme en varios dominios. El modelo descrito combina un include para el envío gestionado, almacenamiento compartido, facturación sin cobro por usuario, migración IMAP integrada y SMTP propio o gestionado según el plan. Revisa la disponibilidad, los límites y las condiciones actuales; un único include no garantiza un coste recursivo reducido.

Para quienes emprenden en solitario, la ventaja puede ser la sencillez: alojar los buzones en TrekMail, mantener ordenada la política raíz y evitar la facturación por puesto según el plan. Para equipos, una configuración uniforme puede facilitar las altas y reducir errores DNS. Para agencias y MSP, proporciona un patrón reutilizable en muchos dominios, aunque cada remitente y migración necesita verificarse.

Pasar de configuraciones SPF frágiles y distintas para cada cliente a una arquitectura repetible con un panel común y una política raíz verificada mejora la operación. No se trata solo de escribir una cadena TXT más corta.

Como referencia del artículo, Nano ofrece 10 dominios, 5GB de almacenamiento compartido y SMTP propio sin tarjeta obligatoria. Si necesitas envío gestionado y límites superiores, los planes de pago descritos parten de $3.50/mes, con una prueba gratuita de 14 días que requiere tarjeta de crédito. Consulta los precios de TrekMail para confirmar los planes, límites y condiciones vigentes.

Conclusión: crear un registro SPF que sea más fácil de mantener

Para crear registros SPF duraderos, deja de pensar en una lista enorme de permisos en el dominio raíz y piensa en arquitectura. Dominio raíz para el correo entre personas. Subdominios de MAIL FROM para remitentes especializados. Includes mínimos. -all explícito cuando el inventario esté completo. Verificación DNS después de publicar, teniendo en cuenta las cachés y la alineación DMARC.

Esta estrategia ayuda a controlar el presupuesto de consultas y a reducir fallos inesperados. No elimina las revisiones cuando cambian los proveedores, pero las facilita. Si estás renovando tu infraestructura de correo, explora TrekMail y comprueba si su modelo y sus condiciones actuales encajan con tu crecimiento.