SPF dinámico, SPF automático y SPF alojado: ¿cuál de ellos corrige realmente tu registro SPF?

Acabas de añadir una nueva plataforma de atención al cliente o de automatización de marketing a tu conjunto de herramientas, has actualizado tu DNS y, de repente, tus correos electrónicos transaccionales empiezan a rebotar. Al revisar los encabezados sin procesar de los correos, te encuentras con el error «PermError: demasiadas consultas de DNS».

Si empiezas a buscar una solución, te encontrarás directamente con tres términos que se promocionan como soluciones integrales: Dynamic SPF, Auto SPF y Hosted SPF. Todos los proveedores afirman que su plataforma ofrece «consultas ilimitadas», pero los nombres no te dicen prácticamente nada sobre lo que realmente se publica en tu DNS público ni sobre cómo se evalúa la autenticación en el momento de la entrega.

Esta es la realidad técnica tal y como es: estas tres denominaciones representan dos mecanismos fundamentalmente diferentes, no tres variaciones del nombre de un mismo producto. El SPF dinámico y el SPF automático se basan en instantáneas de IP almacenadas que deben resolverse y actualizarse continuamente en el DNS. El SPF alojado (concretamente, el PowerSPF de PowerDMARC) utiliza la evaluación de macros en el momento de la consulta para resolver la IP del remitente de forma dinámica en el momento exacto de la entrega. Dado que la evaluación en el momento de la consulta no crea ninguna instantánea estática, PowerSPF es el único mecanismo en el que tu registro no puede quedar obsoleto de forma silenciosa y bloquear el correo legítimo cuando un proveedor rota los rangos de IP, todo ello con un consumo de tan solo una única consulta DNS. Antes de elegir un proveedor, comprueba cuántas consultas DNS utiliza tu registro en este momento para evaluar tu exposición de referencia.

Por qué se ha producido un error en tu registro SPF: el límite de 10 consultas y el error «PermError»

Para corregir un registro SPF que supera el límite, primero hay que comprender por qué existe ese límite en la especificación del protocolo. Según el apartado 4.6.4 del RFC 7208, cualquier agente de transferencia de correo (MTA) receptor que evalúe una política SPF debe detener el procesamiento y devolver un PermError si la evaluación requiere más de 10 mecanismos de consulta DNS.

Contabilidad de búsqueda de mecanismos (RFC 7208, apartado 4.6.4)

Este límite se diseñó específicamente para proteger a los resolutores receptores de bucles infinitos y de ataques de denegación de servicio por amplificación de DNS. Sin embargo, el presupuesto se agota mucho más rápido de lo que la mayoría de los equipos de TI prevén, ya que los mecanismos «include:» se anidan de forma recursiva. Al añadir una línea «include» de un único proveedor de SaaS, se heredan todos los mecanismos «include:», «a» y «mx» contenidos en el árbol de registros de dicho proveedor.

Ejemplo real de registro de sobrepaso de límite

None
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:thirdparty.salesforce.com include:servers.mcsv.net ~all

Un PermError no es una advertencia leve; provoca que la evaluación del SPF falle inmediatamente. Según DMARC (RFC 7489), si DKIM tampoco supera la comprobación y no está estrictamente alineado con ese dominio de envío concreto, el mensaje completo falla la autenticación DMARC.

Más allá del límite de 10 términos de búsqueda, los registros SPF complejos suelen alcanzar el límite de 512 bytes de la carga útil UDP del DNS. Cuando una respuesta DNS supera los 512 bytes, los resolutores deben recurrir al protocolo TCP, lo que aumenta la latencia del establecimiento de conexión y provoca tiempos de espera de autenticación transitorios. Es fundamental comprender qué hace la instrucción «SPF include» y analizar en detalle la sintaxis general de los registros SPF, especialmente cuando se trata de gestionar múltiples registros SPF en entornos de dominios complejos.

SPF dinámico, SPF automático y SPF alojado: comparación rápida

La tabla siguiente desglosa el funcionamiento interno de cada mecanismo, comparando la arquitectura básica, los costes de búsqueda y los límites operativos.

Aunque las tres soluciones mantienen el número de consultas DNS por debajo del límite establecido por el RFC, Hosted SPF (PowerSPF) es el claro ganador en cuanto al mecanismo principal. Al utilizar la expansión de macros en el momento de la consulta en lugar del «flattening» de direcciones IP, PowerSPF elimina por completo el problema de que los datos estén desactualizados, en lugar de limitarse a acortar el intervalo entre las actualizaciones de la base de datos.

Qué hace realmente el SPF dinámico

Cómo funciona

«SPF dinámico» es un término acuñado principalmente por Red Sift (OnDMARC) y adoptado por proveedores como DmarcDuty, DMARC Advisor y Dmarcly. La arquitectura central se basa en un registro DNS alojado por el proveedor. Cuando autorizas un nuevo servicio de envío en el panel de control de tu plataforma, la infraestructura del proveedor resuelve el árbol «include:» de destino y actualiza el registro alojado al que apunta tu dominio principal. Red Sift promociona esta característica afirmando que las actualizaciones se producen «en el momento de la autenticación». Es fundamental destacar que el SPF dinámico está diseñado para no utilizar macros, evitando intencionadamente la sintaxis de macros en favor de una gestión limpia de las inclusiones SPF.

¿Quién utiliza este término?

La etiqueta la utilizan con fines comerciales Red Sift OnDMARC, DmarcDuty, DMARC Advisor y Dmarcly. Aunque el lenguaje de marketing varía, todas estas implementaciones se basan en servidores de seguimiento en segundo plano para supervisar los cambios en las direcciones IP de terceros y reescribir los registros alojados.

Puntos fuertes

La principal ventaja del SPF dinámico es que elude por completo el histórico debate sobre la compatibilidad con macros. Al publicar mecanismos SPF estándar (include:, ip4:, ip6:), garantiza la conformidad incluso con servidores de correo receptores no estándar o heredados. Además, las implementaciones de primer nivel, como Red Sift, cuentan con una resiliencia de respaldo documentada: si se produce un error temporal en el backend, el servicio utiliza la última configuración operativa conocida de la infraestructura de Google Cloud, lo que permite que el correo siga circulando.

Limitaciones

A pesar de su nombre «dinámico», Dynamic SPF sigue generando una instantánea de IP gestionada detrás de un puntero de referencia. La precisión de tu registro sigue dependiendo de la frecuencia de sondeo y del ciclo de actualización del proveedor. Si un proveedor de servicios en la nube añade un nuevo bloque de direcciones IP a su clúster de envío y envía correo inmediatamente, un retraso en el ciclo de reevaluación del proveedor puede provocar fallos SPF falsos positivos. Además, competidores como AutoSPF suelen centrarse en esta cuestión, señalando que las actualizaciones «programadas, y no en tiempo real» pueden seguir sin estar a la altura de los rápidos cambios en la infraestructura.

Qué hace realmente la función «Auto SPF» (aplanamiento del SPF)

Cómo funciona

Auto SPF solutions typically offer a hybrid approach, providing both scheduled SPF flattening and dynamic macro-based resolution. When operating in flattening mode, the system recursively queries all include:, a, and mx mechanisms, extracts the underlying IP blocks, and writes them into hosted sub-records on a scheduled loop. When operating in macro mode, tools like AutoSPF utilize %{ir} macro-flattening to evaluate connecting IPs dynamically at run-time, similar to Hosted SPF solutions.

Arquitectura de aplanamiento SPF

1. Registro original: v=spf1 include:_spf.google.com include:sendgrid.net ~all

2. Procesamiento del motor de aplanamiento:

• Resuelve _spf.google.com → 35.190.247.0/24, 172.217.0.0/19…
• Resuelve sendgrid.net → 167.89.0.0/17, 208.117.48.0/20…

3. Registro público simplificado publicado: v=spf1 ip4:35.190.247.0/24 ip4:167.89.0.0/17 ~all

Puntos fuertes

Auto SPF elimina por completo el trabajo manual que supone escribir y ejecutar scripts locales de Python para simplificar los registros. Es independiente del proveedor, asequible e ideal para organizaciones que desean resolver un único error de consulta SPF sin tener que suscribirse a una plataforma de ciberseguridad más amplia.

Limitaciones

La aplanación conlleva una serie de inconvenientes operativos:

1. Antigüedad de la instantánea: un registro simplificado es una instantánea de un momento concreto. Cuando un proveedor de correo electrónico amplía sus rangos de IP sin previo aviso, tu registro deja de ser preciso hasta que se complete la siguiente consulta programada.

2. Eficiencia en las consultas: la simplificación suele requerir dos consultas (una para la redirección CNAME y otra para la cadena TXT simplificada), mientras que las soluciones basadas en macros solo requieren una.

3. Aumento excesivo del tamaño de los registros: Al sustituir los «includes» por cientos de bloques CIDR sin procesar, la longitud de los registros se acerca directamente al límite de 512 bytes del protocolo UDP.

4. Divulgación de la infraestructura de IP públicas: El «flattening» expone toda tu pila de envío autorizada en un DNS público en texto claro, lo que proporciona a los atacantes un mapa exacto de tus proveedores externos. Los expertos del sector han desaconsejado sistemáticamente el «flattening» puro debido precisamente a estos riesgos estructurales.

Los matices de la comunicación

Aunque AutoSPF se promociona principalmente por sus capacidades de «aplanamiento» automatizado para usuarios que desean disponer de listas de direcciones IP estáticas y legibles en su DNS, es importante señalar que su plataforma también admite de forma nativa la resolución de macros en tiempo real para aquellas organizaciones que necesitan actualizaciones sin ningún tipo de retraso.

En qué se diferencia el SPF alojado (PowerSPF): macros en el momento de la consulta

«Alojado» es un modelo de prestación de servicios, no un mecanismo

Para evaluar estos productos de forma objetiva, hay que tener en cuenta que el término «alojado» se refiere a la forma en que se proporciona el registro, no a la tecnología que hay detrás. Tanto Dynamic SPF como Auto SPF y PowerSPF son servicios alojados; el usuario publica una única referencia estática en el DNS de su dominio y el proveedor gestiona la información que hay detrás. Lo que distingue al SPF alojado de PowerDMARC (PowerSPF) es el motor que hay detrás de esa referencia: la evaluación de macros en el momento de la consulta.

Proceso de evaluación de macros de PowerSPF

1. IP del MTA del remitente que se está conectando: 192.0.2.45

2. Receiver Queries Domain SPF Policy: v=spf1 exists:%{i}.abcde12345.macrospf.powerspf.com -all

3. Receiver Expands Macro %{i} to Connecting IP: 192.0.2.45.abcde12345.macrospf.powerspf.com

4. El receptor realiza una consulta DNS sobre el nombre de host ampliado:

• La consulta llega al DNS perimetral de PowerDMARC.
• 192.0.2.45 está autorizado en el panel de control → Devuelve 127.0.0.2 (existe un registro A).
• Resultado de la evaluación del SPF: APROBADO

Cómo identifica PowerSPF al remitente

En lugar de almacenar una lista de direcciones IP resueltas en tu DNS, PowerSPF utiliza las macros oficiales del RFC 7208. Cuando implementas PowerSPF, tu registro DNS público se configura con un mecanismo «exists:» estructurado de la siguiente manera:

v=spf1 exists:%{i}.abcde12345.macrospf.powerspf.com -all

When a receiving mail server processes an incoming message, it evaluates the macro %{i}, which the SPF specification defines as the connecting sender’s IP address. The receiver automatically inserts the sender’s IP into the string and executes a single DNS query:

192.0.2.45.abcde12345.macrospf.powerspf.com

La red DNS global de PowerDMARC recibe esta consulta. Si la dirección IP 192.0.2.45 está autorizada en tu panel de control de PowerDMARC, el servidor DNS devuelve una respuesta de registro A (127.0.0.2). El servidor receptor comprueba que el dominio existe y valida la comprobación SPF como «Aprobada».

Qué obtienes a cambio

1. Siempre 1 consulta DNS: independientemente de si autorizas 3 herramientas de envío o 50, tu registro consume exactamente 1 consulta DNS. Según las pruebas de referencia internas de PowerDMARC, pasar de un registro estándar de 5 consultas al funcionamiento de las macros SPF reduce el coste de las consultas a 1, mientras que la simplificación suele reducirlo a 2.

2. Ausencia total de datos obsoletos en las instantáneas: dado que la dirección IP de conexión se evalúa en tiempo real en el momento de la entrega, no existe ninguna lista de direcciones IP almacenada en caché que pueda quedar desactualizada.

3. Privacidad total de la IP: Tus rangos de IP autorizados nunca se publican en registros DNS públicos en texto sin cifrar.

4. Sin aumento de tamaño: la cadena del registro DNS sigue siendo muy breve y estática, por lo que es totalmente inmune a los errores de truncamiento UDP de 512 bytes.

Configuración y operaciones del segundo día

Para configurar el SPF alojado (PowerSPF) es necesario añadir un único registro CNAME a tu DNS, un proceso que lleva menos de cinco minutos. Una vez configurado, tu equipo de TI no tendrá que volver a tocar los registros DNS. La autorización o revocación de los remitentes se realiza directamente desde el panel de control de PowerDMARC, con aplicación global inmediata.

Capacidades de gobernanza empresarial

Las herramientas de solución puntual simplifican los registros de forma aislada, pero PowerSPF funciona dentro de una plataforma de seguridad completa. Ofrece:

• Análisis detallados de SPF que desglosan el volumen de envío por origen, mecanismo y dirección IP individual.
• Detección automática de PermError, consultas nulas y errores sintácticos con instrucciones de corrección integradas.
• Integración de SSO/SAML para empresas, respaldada por las certificaciones SOC 2 Tipo 2 e ISO 27001.
• Un acuerdo de nivel de servicio (SLA) con un tiempo de actividad del 99,995 % que se ejecuta en una infraestructura periférica de alta disponibilidad.
• Integración completa junto con la aplicación de DMARC, la gestión de DKIM, la presentación de la marca mediante BIMI y la gestión de políticas MTA-STS.

El modo de fallo que nadie incluye en su página de precios

Para comprender por qué es importante el mecanismo central, imaginemos una situación operativa habitual:

Una empresa de tamaño medio configura una herramienta de «flattening» de SPF para gestionar seis servicios en la nube, entre los que se incluyen un importante CRM y un proveedor de correo electrónico transaccional. Todas las autenticaciones se realizan sin problemas y el número de consultas se reduce de 13 a 2.

Seis semanas más tarde, el proveedor de correo electrónico transaccional asigna un nuevo bloque de direcciones IP a su clúster de envío para gestionar el aumento del tráfico. El proveedor actualiza su propio registro SPF principal (_spf.vendor.com). Sin embargo, tu herramienta de simplificación solo vuelve a resolver los registros externos siguiendo una programación fija de 4 o 12 horas.

Análisis de la reducción del desfase temporal

Durante ese periodo intermedio, los mensajes transaccionales legítimos —como notificaciones de facturas, restablecimientos de contraseñas y confirmaciones de pedidos— se envían desde las nuevas direcciones IP del proveedor. Cuando los servidores receptores comprueban tu registro SPF simplificado, la nueva IP no aparece.

La comprobación del SPF falla. Si DKIM no funciona correctamente, no está alineado o ha sido eliminado por un servidor de retransmisión intermedio, el mensaje no supera la comprobación de DMARC. Los servidores receptores aplican tu política de DMARC, lo que hace que el correo corporativo legítimo acabe en las carpetas de spam o se descarte por completo.

Dado que este modo de fallo es parcial y específico de una fuente concreta, rara vez activa alertas inmediatas en la red. El correo electrónico principal sigue fluyendo con normalidad, pero un flujo transaccional crítico se interrumpe de forma imperceptible.

La diferencia: con la evaluación de macros en el momento de la consulta, no hay ninguna instantánea de la base de datos de direcciones IP que pueda quedar desactualizada. Cuando el proveedor envía un correo desde un servicio de envío recién autorizado, PowerSPF evalúa la dirección IP de conexión en tiempo real según la política de tu panel de control en el mismo instante en que se realiza la entrega.

La compensación técnica realista: ninguna arquitectura de seguridad está exenta de riesgos. La «aplanamiento» traslada tu dependencia de seguridad a la periodicidad de actualización de la base de datos del proveedor; sin embargo, dado que las direcciones IP «aplanadas» se almacenan en caché en registros TXT estándar del DNS, la autenticación de tu correo electrónico se mantiene incluso si el backend del proveedor queda fuera de línea. La evaluación de macros traslada tu dependencia a la accesibilidad del servicio DNS de macros del proveedor en el momento de la consulta. Si un proveedor que utiliza macros sufre una interrupción del DNS autoritativo, las comprobaciones SPF entrantes devolverán un «TempError» o fallarán por completo hasta que se restablezca el servicio. Los proveedores de alto nivel abordan este problema manteniendo redes periféricas con un SLA de tiempo de actividad del 99,995 %, distribuidas a nivel mundial.

Dos objeciones que te plantearán los competidores

1. «La evaluación basada en macros crea un único punto de fallo».

Los competidores que se basan exclusivamente en el «aplanamiento» tradicional suelen señalar que la evaluación de macros en el momento de la consulta requiere una consulta DNS en tiempo real al servidor del proveedor para cada envío de correo electrónico.

Verificación de datos: Se trata de una distinción arquitectónica válida. Si la infraestructura DNS de un proveedor de macros deja de estar disponible, el receptor no puede expandir la macro, lo que provoca un error temporal de SPF (SPF TempError). El «flattening» tradicional evita esto, ya que los registros TXT estándar permanecen almacenados en caché en todo el mundo. Para mitigar este riesgo, los proveedores de macro-SPF para empresas (como PowerSPF) operan redes DNS Anycast altamente redundantes y distribuidas a nivel mundial para garantizar respuestas a las consultas en menos de un milisegundo y un tiempo de actividad máximo.

2. «Las macros SPF no funcionan correctamente en servidores de correo receptores más antiguos».

Competitors using traditional flattening often claim that macro syntax (exists:%{i}) breaks compatibility with legacy email gateways.

Verificación de datos: La expansión de macros y el mecanismo «exists:» son componentes fundamentales del apartado 7 del RFC 7208, publicado en 2014 (y anteriormente del RFC 4408 en 2006). No se trata de extensiones propietarias de ningún proveedor. Todos los servidores de correo electrónico receptores que cumplen con el RFC en Internet, incluidos Microsoft 365, Google Workspace, Proofpoint, Cisco Secure Email y Mimecast, admiten la expansión de macros de forma nativa.

Aunque es posible que alguna puerta de enlace heredada que no cumpla con los requisitos —algo excepcionalmente poco frecuente— no analice correctamente las macros, este riesgo marginal debe sopesarse frente al riesgo diario garantizado de que las instantáneas de IP estáticas queden desactualizadas debido al «aplanamiento» tradicional.

¿Qué solución deberías elegir?

Matriz de decisión

Escenario 1: Tienes entre 2 y 3 servidores de envío en la nube estables y menos de 10 consultas

Si tu dominio solo utiliza Google Workspace y un único servicio de asistencia técnica, es posible que no necesites adquirir ningún software de gestión de SPF. Revisa tu registro con una herramienta de búsqueda, elimina las líneas «include:» que no se utilicen y sustituye los mecanismos MX o A innecesarios por reglas limpias. Si no superas las 10 consultas, mantén tu configuración DNS estándar.

Escenario 2: Gestionas entre 5 y 30 herramientas en la nube con rotaciones de IP activas

Si tu organización se basa en un conjunto moderno de herramientas de marketing, ventas y recursos humanos, la «aplanamiento» tradicional supone un riesgo constante para la capacidad de entrega. La evaluación de macros en el momento de la consulta mediante PowerSPF es la opción técnica óptima, ya que elimina la obsolescencia de las instantáneas, protege tu topología de IP interna y limita las consultas a 1.

Escenario 3: Proveedores de servicios de gestión (MSP) y equipos empresariales que gestionan carteras multidominio

Si gestionas la autenticación del correo electrónico en docenas de dominios de clientes, evaluar herramientas puntuales de forma aislada complica la gestión. Necesitas un panel de control multitenant, controles de acceso basados en roles, análisis granulares de direcciones IP y un conjunto completo de herramientas de autenticación. Explorar alternativas a AutoSPF llevará a los equipos empresariales a plataformas unificadas como PowerDMARC.

Conclusión

Tanto el SPF dinámico como el SPF automático y el SPF alojado reducirán hoy con éxito el número de consultas DNS por debajo del umbral de 10 consultas establecido en el RFC. Sin embargo, solo la evaluación de macros en el momento de la consulta garantiza que tu registro no se desajuste silenciosamente mañana.

Al verificar la autorización del remitente en tiempo real en el momento de la entrega, Hosted SPF (PowerSPF) elimina la obsolescencia de las instantáneas, oculta tu huella de IP interna y reduce el coste de las consultas DNS a 1, todo ello dentro de una plataforma de nivel empresarial respaldada por un SLA con un tiempo de actividad del 99,995 %.

Próximos pasos:

1. Utiliza nuestra herramienta gratuita de búsqueda de SPF para comprobar el número actual de consultas de tu dominio y detectar las inclusiones anidadas.

2. Si tu registro supera las 10 consultas, inicia una prueba de PowerSPF (SPF alojado) para corregir tu registro en menos de cinco minutos.

3. ¿Gestionas una empresa o una cartera de MSP? Concierta una demostración técnica con nuestro equipo de ingeniería para conocer nuestro panel de control de autenticación multitenant.

Preguntas frecuentes

¿El SPF dinámico es lo mismo que el «aplanamiento del SPF»?

El SPF dinámico es un término que engloba una categoría más amplia, mientras que la «aplanamiento del SPF» es un mecanismo específico. Muchos proveedores que ofrecen «SPF dinámico» se basan, en realidad, en el aplanamiento automático del SPF, que resuelve periódicamente las cadenas «include:» en direcciones IP estáticas publicadas en registros alojados.

¿Cuál es la diferencia entre el SPF alojado y el «spf flattening»?

SPF Flattening extrae rangos de IP y los publica como bloques de IP estáticos en tu DNS. El SPF alojado (concretamente, PowerSPF de PowerDMARC) utiliza la evaluación de macros en el momento de la consulta para comprobar la IP del remitente en tiempo real en el momento de la entrega, lo que evita el almacenamiento de IP estáticas y previene que los datos quedaran obsoletos.

¿Funcionan las macros de SPF con Microsoft 365 y Google Workspace?

Sí. La expansión de macros y el mecanismo «exists:» están totalmente estandarizados según el §7 de la RFC 7208. Tanto Microsoft 365 como Google Workspace procesan de forma nativa la evaluación del SPF basada en macros sin problemas de compatibilidad.

¿Existe realmente lo de «búsquedas ilimitadas en el SPF»?

Ningún registro puede superar el límite de 10 consultas establecido en el RFC 7208 durante la evaluación. Las plataformas que ofrecen «consultas ilimitadas» optimizan la arquitectura de tus registros, mediante el aplanamiento o el uso de macros, de modo que, independientemente del número de remitentes que añadas, el servidor receptor realice como máximo 1 o 2 consultas.

¿Qué ocurre con mi correo electrónico si mi proveedor de SPF alojado sufre una interrupción del servicio?

Los proveedores de primer nivel, como PowerDMARC, utilizan redes periféricas distribuidas con un acuerdo de nivel de servicio (SLA) que garantiza un tiempo de actividad del 99,995 %. En caso de interrupción del servicio, los nodos DNS redundantes siguen respondiendo y las reglas de respaldo evitan los fallos de autenticación.

¿Cómo puedo solucionar el error de «demasiadas consultas DNS» en mi registro SPF?

Puedes solucionar un registro de superación del límite revisando y eliminando las instrucciones «include:» obsoletas, trasladando a determinados remitentes a subdominios específicos o implementando una solución de macros alojada, como PowerSPF, para reducir el coste de la evaluación a una sola consulta.

• Acerca de
• Últimas publicaciones

Milena Baghdasaryan

Especialista en contenidos en PowerDMARC

Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.

Últimos mensajes de Milena Baghdasaryan (ver todos)

• Cómo elaborar un plan de respuesta ante incidentes desde cero - 8 de septiembre de 2026
• La nueva forma en que los hackers engañan a los asistentes financieros basados en IA - 7 de septiembre de 2026
• Prácticas recomendadas de seguridad del DNS: una lista de comprobación completa para reforzar la seguridad - 7 de septiembre de 2026