Tu configuración SPF funciona bien con un remitente. Después añades Google Workspace, Mailchimp, Zendesk y una API transaccional, y Microsoft empieza a rechazar mensajes con 550 5.7.515. El registro que parecía limpio al principio acaba de superar el límite de 10 consultas, y ahora todos los mensajes salientes fallan silenciosamente la autenticación.
Esa es la trampa. SPF tiene un límite estricto incorporado al protocolo, y muchos equipos lo alcanzan al añadir el tercer o cuarto servicio de envío. La solución habitual, pegar otro include:, deja de funcionar justo cuando más se necesita. Para aprender la sintaxis básica, empieza por nuestra guía sobre el registro SPF para correo. Este artículo se centra en la arquitectura: cómo diseñar una configuración SPF que admita varios remitentes, soporte cambios de proveedor y no necesite reescribirse cada trimestre.
Por qué falla una configuración SPF con varios remitentes
La configuración SPF falla porque RFC 7208 limita la evaluación a 10 consultas DNS por registro. Cada mecanismo include, a, mx, exists y redirect cuenta, y el cálculo es recursivo. Si el include de un proveedor contiene otros tres includes, todos consumen parte del límite. Al llegar a 11, los servidores receptores devuelven PermError y pueden rechazar el mensaje.
El patrón de fallo suele ser el mismo. Empiezas con dos includes y margen suficiente. Marketing añade HubSpot, soporte incorpora Freshdesk e ingeniería utiliza SendGrid para las alertas de la aplicación. La cadena de cada proveedor se anida más de lo que sugiere la documentación. De pronto tienes 12 consultas y Google devuelve 550 5.7.26 en todos los mensajes.
| Mecanismo | ¿Consume una consulta? | Nota operativa |
|---|---|---|
include: | Sí, incluidas las anidadas | Habitual para proveedores, pero el anidamiento es imprevisible |
ip4: / ip6: | No | Sin coste de consultas; úsalo para remitentes estáticos bajo tu control |
mx | Sí | A menudo se usa en exceso; sustitúyelo por ip4 cuando sea posible |
a | Sí | Poco eficiente para SPF; es preferible ip4 |
ptr | Sí | Obsoleto. No lo utilices |
redirect | Sí | Transfiere la evaluación al registro de otro dominio |
-all / ~all | No | Final de la política; incluye siempre uno |
El cálculo no es complicado. Simplemente permanece oculto hasta que algo falla. Por eso, una configuración SPF para varios remitentes debe empezar por la arquitectura y no por copiar y pegar.
Audita el registro SPF antes de añadir nada
El primer paso en cualquier configuración SPF con varios remitentes es retirar lo que ya no debería estar allí. Muchos dominios conservan includes de servicios cancelados hace meses o años, y cada uno desperdicia parte del presupuesto de consultas. Primero limpia; después construye.
Comprueba qué está publicado realmente:
dig txt yourdomain.com +shortDespués sigue cada include para saber hasta dónde llega:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortContrasta los resultados con los informes agregados de DMARC. Si no sale tráfico desde las IP de un proveedor, ese include solo ocupa espacio. Elimínalo.
Tres mejoras rápidas durante la auditoría:
- Sustituye
mxpor la IP real medianteip4:; ahorras una consulta. - Elimina los includes de servicios que ya no utilizas.
- Busca registros SPF duplicados. Dos registros TXT que empiecen por
v=spf1en el mismo dominio provocan un PermError inmediato.
Solo esto suele liberar 2-3 consultas. Para ver una limpieza detallada, consulta nuestra guía para configurar un registro SPF.
Segmentación por subdominios: la configuración SPF que escala
La configuración SPF que permite gestionar varios remitentes con fiabilidad sin alcanzar el límite de 10 consultas es la segmentación por subdominios. SPF se evalúa con el dominio de Return-Path, no con el encabezado From visible. Mueve los remitentes no corporativos a subdominios y cada flujo obtiene un nuevo presupuesto de 10 consultas.
Este es el patrón:
Dominio raíz: solo correo entre personas
Mantén limpio el dominio raíz. Incluye únicamente al proveedor principal de buzones.
v=spf1 include:spf.trekmail.net -allUn include y una consulta. El correo de la dirección ejecutiva no deja de funcionar porque marketing haya añadido otra herramienta.
Subdominio de marketing: campañas y boletines
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot y Mailchimp consumen las consultas de news.example.com, no las del dominio raíz. Si se limita este subdominio, el correo corporativo continúa circulando.
Subdominio de soporte: sistemas de tickets
; help.example.com
v=spf1 include:mail.zendesk.com -allSubdominio transaccional: alertas y recibos de aplicaciones
; alerts.example.com
v=spf1 include:amazonses.com -allCuando Zendesk envía como support@help.example.com, el receptor consulta el DNS de help.example.com. Nunca toca el registro SPF del dominio raíz. Ese es el objetivo.
| Método anterior | Método nuevo |
|---|---|
| Todos los remitentes amontonados en un único registro SPF raíz | El dominio raíz solo contiene el proveedor principal de buzones |
| Un cambio de proveedor puede romper todo el correo saliente | Los fallos quedan aislados en el subdominio afectado |
| Todo comparte el mismo presupuesto de consultas | Cada subdominio tiene su propio presupuesto de 10 consultas |
| Hay que reescribir SPF cada vez que añades una herramienta | La arquitectura soporta los cambios de proveedor |
Aplanamiento de SPF: el último recurso
Si los requisitos empresariales obligan a que todo el correo salga del dominio raíz, sin permitir subdominios, el aplanamiento de SPF es una vía de escape. Este proceso resuelve los includes de proveedores en direcciones IP sin procesar y las enumera como mecanismos ip4:, que no consumen consultas. Funciona, pero crea una tarea de mantenimiento.
El riesgo es que la información quede obsoleta. Los proveedores SaaS cambian sus IP con regularidad. Si SendGrid añade mañana un nuevo rango y el registro aplanado todavía contiene las direcciones de ayer, el correo saliente empezará a fallar SPF. No aplanes el registro manualmente salvo que puedas comprobarlo a diario. Utiliza un servicio de SPF dinámico automatizado que vigile las IP de los proveedores y actualice el registro TXT de forma programada.
El aplanamiento es una solución provisional, no un diseño. La segmentación por subdominios es la solución estructural. Utiliza el aplanamiento solo cuando hayas agotado de verdad las demás opciones.
Comprueba que la configuración SPF funciona
Después de cualquier cambio en SPF, verifica lo que devuelve realmente el DNS público. No dependas del panel del registrador, de interfaces con datos en caché ni de los indicadores verdes del proveedor. Consulta directamente el dominio y confirma que existe exactamente un registro SPF válido por nombre de host.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortDebe haber un registro TXT que empiece por v=spf1 en cada nombre de host. No dos. Tampoco uno actual junto a otro olvidado tras una migración de hace dos años.
Después envía un mensaje de prueba a Gmail, ábrelo, pulsa el menú de tres puntos, elige «Mostrar original» y busca:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSCualquier resultado FAIL o SOFTFAIL indica un problema en la configuración SPF. Corrígelo antes de enviar grandes volúmenes. Si también investigas problemas de reputación que van más allá de SPF, nuestra guía de señales de reputación del remitente explica el contexto general.
Cómo simplifica TrekMail la configuración SPF en varios dominios
Configurar SPF para un dominio resulta molesto. Hacerlo para 50 dominios de clientes, cada uno con proveedores de envío y DNS distintos y diferentes niveles de abandono, consume mucho tiempo. TrekMail mantiene una huella SPF pequeña y previsible para dejar margen al resto.
El include principal es include:spf.trekmail.net. Una consulta. Sin redirecciones anidadas ni cadenas de expansión imprevisibles. Compáralo con Microsoft 365, que a menudo consume 2-3 consultas mediante redirecciones internas, o con Google Workspace, cuyo comportamiento puede variar por región.
Para quien trabaja por cuenta propia, esto permite mantener una configuración SPF sencilla incluso después de añadir una herramienta de marketing. Para los equipos, reduce los errores DNS durante el alta. Para las agencias que administran decenas o cientos de dominios de clientes, ofrece una plantilla repetible: añade el include de TrekMail, separa los demás proveedores en subdominios y evita el problema del límite de consultas. Si gestionas correo para muchas marcas, consulta la arquitectura general del alojamiento de correo multidominio.
El comprobador de estado DNS de TrekMail también señala los conflictos SPF en el panel antes de que provoquen fallos en producción. Puedes ver el problema antes que tus clientes. Para consultar toda la configuración DNS, abre Registros DNS obligatorios en la documentación.
Conclusión: diseña SPF una vez y deja de modificarlo
Una buena configuración SPF empieza por la arquitectura, no por la sintaxis. Audita los includes obsoletos. Separa los remitentes entre subdominios para que cada flujo disponga de su propio presupuesto de 10 consultas. Mantén limpio el dominio raíz: un proveedor de buzones, un include y un -all. Verifica con dig, no con paneles.
Si quieres aplicar este patrón a uno o cien dominios sin pagar por usuario, TrekMail ofrece alojamiento multidominio a precio fijo, un único include SPF limpio, almacenamiento compartido y un comprobador DNS que detecta pronto los errores de configuración. Según las condiciones actuales, el plan Nano cubre 10 dominios con SMTP propio, sin tarjeta de crédito y de forma gratuita. Los planes de pago empiezan en $3.50/month con Starter y SMTP gestionado, e incluyen una prueba gratuita de 14-day (se requiere tarjeta). Consulta los planes vigentes en trekmail.net/pricing.
