SPF flattening
El SPF flattening resuelve los mecanismos include, a y mx de su registro SPF en las direcciones IP subyacentes, manteniendo las consultas DNS por debajo del límite de 10 de la RFC 7208 para que su registro siga siendo válido y el correo legítimo siga superando la autenticación.
El SPF flattening (aplanamiento de SPF) es la práctica de resolver todos los mecanismos que provocan consultas en su registro SPF — include:, a, mx, ptr, exists y redirect= — hasta las direcciones IP concretas que hay detrás de ellos, y publicar después esas direcciones directamente como entradas ip4: e ip6:. El objetivo es sencillo: mantener su registro dentro de los límites estrictos que aplican los receptores de correo, para que el correo legítimo siga autenticándose a medida que crece su infraestructura de envío.
Esta página es el eje central de todo lo relacionado con el SPF flattening. Explica qué es el aplanamiento, por qué el límite de 10 consultas fuerza la cuestión, cómo funciona el proceso paso a paso y dónde residen realmente las contrapartidas y los riesgos. Desde aquí puede profundizar en las tareas concretas: cómo aplanar un registro SPF, las mejores herramientas de SPF flattening, si el SPF flattening afecta a DKIM y DMARC, hacerlo en Cloudflare y cómo se compara el aplanamiento con SPF flattening frente a macros.
¿Qué es el SPF flattening?
Un registro SPF es un único registro TXT, que comienza con v=spf1, que indica a los servidores de correo receptores qué hosts están autorizados a enviar correo en nombre de su dominio. Cuando añade un servicio — un CRM, una plataforma de marketing, un helpdesk, un proveedor de correo transaccional — normalmente añade un include: para él. Cada include: apunta al registro SPF de otro dominio, y el receptor tiene que recuperar ese registro en el momento de la evaluación. Esas recuperaciones son consultas DNS, y se acumulan rápidamente.
El SPF flattening toma todas esas referencias indirectas y las pre-resuelve. En lugar de pedir al receptor que persiga include:_spf.google.com a través de registros _netblocks anidados, un registro aplanado simplemente enumera los rangos de IP subyacentes:
- Antes:
v=spf1 include:sendgrid.net include:_spf.google.com a mx -all - Después:
v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all
En el momento de la evaluación, el receptor ya no recurre a través de los includes ni resuelve los destinos A/MX: simplemente compara la IP que se conecta con los rangos CIDR que usted ha publicado. Eso reduce el número de consultas DNS en tiempo de ejecución a prácticamente cero y mantiene su registro ligero, rápido y fiable.
«El límite de 10 consultas es, con diferencia, la razón más habitual por la que los registros SPF de las empresas se rompen en silencio», afirma Brad Slavin, director general de DuoCircle y fundador de AutoSPF. «Según nuestra experiencia gestionando SPF para más de 2.000 dominios de clientes, el modo de fallo es siempre el mismo: un equipo añade una nueva herramienta SaaS, su include empuja el total por encima de 10, y el correo legítimo empieza a fallar, pero nadie se da cuenta hasta que un cliente se queja de facturas o restablecimientos de contraseña que no llegan.»
Por qué el límite de 10 consultas DNS obliga a aplanar
Según la RFC 7208, la evaluación de SPF está limitada a 10 consultas DNS de mecanismos y 2 consultas vacías (void) por comprobación. Superar cualquiera de los dos límites produce un PermError: un fallo permanente que indica a los servidores receptores que su correo no puede autenticarse. El servidor no reintenta y no evalúa el resto de su registro. Simplemente se detiene, y todos los mensajes de su dominio fallan la comprobación SPF.
La trampa es que este límite es invisible hasta que se cruza. Una pequeña empresa que envía a través de un único proveedor nunca lo alcanzará. Pero las pilas de correo modernas acumulan de forma rutinaria varios ESP, un CRM, un servicio de soporte y correo interno, y cada uno añade una o más consultas. Google Workspace por sí solo consume alrededor de cuatro de sus diez consultas a través de sus includes anidados. Añada Salesforce, Mailchimp, SendGrid y Zendesk y puede llegar fácilmente a entre doce y quince. La consulta número once nunca se evalúa, de modo que cualquier servicio que quede más allá de ese punto pierde la autorización en silencio.
Estos son los mecanismos que cuentan:
| Provoca una consulta DNS | No provoca una consulta |
|---|---|
include:example.com | ip4:x.x.x.x[/CIDR] |
a, a:example.com | ip6:… |
mx, mx:example.com | all |
ptr (desaconsejado por la RFC 7208) | |
exists:domain | |
redirect=example.com |
Como los mecanismos ip4: e ip6: no requieren resolución, el aplanamiento cambia cada mecanismo basado en consultas por otros que no las requieren. Ese es todo el mecanismo por el cual el aplanamiento le mantiene en conformidad. Una forma rápida de ver dónde se encuentra hoy es analizar su dominio con el SPF Checker, que expande cada include y cuenta sus consultas.
Por qué el aplanamiento importa para la entregabilidad y la seguridad
El límite de 10 consultas no es solo una nota técnica al pie: se sitúa justo en el camino entre su correo y la bandeja de entrada.
Entregabilidad. DMARC se apoya en SPF y DKIM. Si su registro SPF devuelve un PermError, DMARC lo trata como un fallo, y el correo legítimo puede quedar en cuarentena o ser rechazado. Desde 2024, Google, Yahoo y Microsoft exigen a los remitentes masivos que se autentiquen con SPF, DKIM y DMARC, y ahora rechazan de plano los mensajes no conformes en lugar de enviarlos a spam. En conjunto, esos proveedores cubren aproximadamente el 90 % de una lista de consumidores típica, de modo que un único registro que supere el límite puede cortar la entrega a la mayor parte de su audiencia de golpe.
Seguridad. Cuando SPF falla, los servidores receptores pierden la capacidad de distinguir su correo legítimo de los mensajes suplantados. Esa es precisamente la brecha que explotan el phishing y el fraude del correo corporativo (BEC). Mantener SPF válido — y dentro del límite — preserva la señal de autenticación que le separa de un atacante que suplanta su dominio.
Manejabilidad. A medida que su marca crece, también lo hace la lista de plataformas que envían en su nombre. El aplanamiento reduce una cadena dispersa de includes a una única lista limpia de rangos de IP que es fácil de leer, auditar y razonar.
Cómo funciona el SPF flattening, paso a paso
Ya se haga de forma manual o mediante automatización, el aplanamiento sigue la misma secuencia:
- Descubrimiento. Lea su registro SPF
TXTactual e identifique cada mecanismo que provoca una consulta:include,a,mx,exists,redirect. - Resolución recursiva. Siga cada cadena de
include, recuperando el registro SPF del destino y recurriendo hasta conocer todo el contenido de nivel superior. Resuelva los destinosa/mxa sus registrosA/AAAApara reunir tanto las direcciones IPv4 como las IPv6. - Deduplicar y comprimir. Fusione los rangos solapados y agregue los bloques contiguos en notación
CIDRpara que el registro se mantenga compacto. - Publicar. Reescriba el registro como
v=spf1 ip4:… ip6:… -all, respetando el límiteTXTde 255 caracteres por cadena (divídalo en varias cadenas concatenadas si es necesario), y actualice su DNS. - Validar. Confirme la sintaxis, verifique que el recuento de consultas es 0-1 y envíe correo de prueba para confirmar
SPF=passyDMARC=pass.
Para el recorrido completo con comandos y detalles específicos por proveedor de DNS, consulte cómo aplanar un registro SPF.
La trampa: un registro aplanado no es una solución de una sola vez
El aplanamiento resuelve el problema de las consultas, pero introduce uno nuevo. Cuando sustituye un include: dinámico por IP estáticas, asume la responsabilidad de mantener esas IP actualizadas. Los proveedores rotan su infraestructura de envío constantemente, y rara vez le avisan cuando lo hacen.
«El malentendido sobre el SPF flattening es que es una solución de una sola vez», afirma Adam Lundrigan, CTO de DuoCircle y arquitecto del motor de aplanamiento de AutoSPF. «Los rangos de IP de los proveedores cambian constantemente: Google rotó sus _netblocks tres veces solo en 2025. Un registro aplanado que no se vuelve a resolver automáticamente queda obsoleto y desautoriza en silencio a remitentes legítimos. Por eso AutoSPF vuelve a analizar cada 15 minutos.»
Esto es lo más importante que hay que entender sobre el aplanamiento. Un registro aplanado a mano es exacto el día en que lo publica y se va quedando desactualizado poco a poco. Cuando un proveedor añade un nuevo rango de IP, el correo procedente de ese rango empieza a fallar la comprobación SPF, y como el fallo es silencioso, suele enterarse por una factura rebotada o un restablecimiento de contraseña que no llegó, no por una alerta. En la telemetría de AutoSPF a través de 1.200 dominios, el aplanamiento redujo las tasas de PermError en un 93 % y mejoró las tasas de aprobación de DMARC entre un 7 y un 12 % en los primeros 30 días, pero solo cuando el registro se mantuvo actualizado. La rotación media de IP de los ESP es de 2 a 4 cambios por semana en los proveedores de gran volumen.
Las demás contrapartidas que conviene prever:
- Tamaño del registro. El aplanamiento puede empujar un registro
TXThacia los límites de tamaño de DNS. Procure mantener las respuestas por debajo de unos 1.000-1.200 bytes para evitar la fragmentación y el truncamiento por UDP, y prefiera rangosCIDRagregados a enumerar direcciones individuales. - Sobreautorización. Algunos includes autorizan mucha más parte de internet de la que usted realmente utiliza. Auditar y recortar antes de aplanar mantiene reducida su superficie de ataque.
¿Manual, con scripts o automatizado?
Hay tres formas de aplanar, con perfiles de riesgo muy distintos:
- Manual. Consulte cada include para conocer sus IP actuales, agréguelas y publíquelas a mano. Es gratuito y está totalmente bajo su control, pero requiere mucho trabajo y es propenso a quedar obsoleto en cuanto un proveedor cambia de IP. Solo es práctico para entornos pequeños y estáticos.
- Con scripts. Un script en Python o Go recurre a los includes, resuelve
A/MX, fusiona rangosCIDRy los envía al DNS mediante API según una programación. Es repetible y auditable, pero usted asume los casos límite, la protección frente a bucles y la fiabilidad continua. - Servicio automatizado (dinámico). Un servicio alojado vuelve a resolver continuamente sus includes, detecta los cambios de IP y republica automáticamente. Esto elimina por completo la carga de mantenimiento, a cambio de una dependencia gestionada.
Para cualquier organización que utilice proveedores dinámicos como Google Workspace, Microsoft 365, SendGrid o Amazon SES, es muy preferible un enfoque automatizado: toda la dificultad del aplanamiento consiste en seguir el ritmo de la rotación, y eso es exactamente lo que gestiona la automatización. Encontrará una comparación completa de las opciones en las mejores herramientas de SPF flattening.
Dónde encaja AutoSPF
El servicio de aplanamiento automático de SPF de AutoSPF está diseñado específicamente para el problema de mantenimiento que hace que el aplanamiento sea arriesgado. Descubre y expande sus includes anidados, resuelve las cadenas completas de A/MX/AAAA, deduplica y comprime los rangos en bloques CIDR mínimos, y publica un registro aplanado validado y consciente del tamaño que se mantiene por debajo del límite de 10 consultas.
Dos cosas lo distinguen:
- Vuelve a analizar cada 15 minutos y actualiza automáticamente su registro en el momento en que cambian las IP de un proveedor de nivel superior, de modo que un registro aplanado nunca queda obsoleto en silencio.
- Resuelve exactamente a las mismas IP a las que resuelven sus includes: sin rangos amplios y demasiado permisivos y sin sobreautorización. Su registro aplanado autoriza precisamente los hosts que autorizan sus includes reales, y nada más.
Además, ofrece registros versionados con reversión de un solo clic, publicación canary/staging y alertas de deriva cuando llega correo desde IP fuera de su conjunto aplanado actual. Se integra directamente con los principales proveedores de DNS, incluidos Route 53, Cloudflare, Google Cloud DNS y Azure DNS. Antes y después de cualquier cambio, puede confirmar que el registro se resuelve correctamente con el SPF Checker.
Aplanamiento entre proveedores de DNS y a escala
La mecánica del aplanamiento es la misma en todas partes, pero la publicación difiere según la plataforma. En Cloudflare, por ejemplo, gestiona el registro TXT a través del panel de control o la API y debe respetar su comportamiento de división en cadenas: los detalles se tratan en SPF flattening en Cloudflare.
A escala SaaS — miles de inquilinos, múltiples flujos de envío — el patrón ganador es por capas: segmente los flujos de correo en subdominios (por ejemplo, mkt.example.com para marketing, tx.example.com para transaccional), centralice la política con redirect= hacia un pequeño registro canónico, aplane por completo los proveedores de alta rotación en conjuntos ip4/ip6 agregados, y automatice la actualización con publicación basada en diferencias para que los registros sin cambios nunca causen movimiento en el DNS. Delegar los remitentes de gran volumen en subdominios también mantiene ligero su dominio organizativo y simplifica la alineación de DMARC.
¿Cambia el aplanamiento DKIM o DMARC?
El aplanamiento solo cambia cómo se expresan los remitentes autorizados en SPF — ip4/ip6 en lugar de include —, no la identidad de su dominio ni sus firmas DKIM. Mientras el SPF aplanado se publique en el dominio utilizado en su MAIL FROM/Return-Path, la alineación de DMARC no se ve afectada, y al eliminar el PermError normalmente mejora las tasas de aprobación de DMARC cuando SPF es el identificador alineado. La relación completa, incluyendo cómo DKIM suele sostener la alineación en los remitentes masivos, se trata en ¿el SPF flattening afecta a DKIM y DMARC?.
Aplanamiento frente a macros de SPF
El aplanamiento tradicional pre-resuelve los includes en IP estáticas, y por eso necesita una actualización constante. Las macros de SPF toman otro camino: utilizan la expansión dinámica para que un único registro pueda autorizar a un número efectivamente ilimitado de remitentes sin llegar nunca al límite de 10 consultas, a costa de mayor complejidad y de un peor soporte por parte de los resolvedores. Qué enfoque le conviene depende de su infraestructura y de su disposición al mantenimiento; el desglose completo está en SPF flattening frente a macros.
Preguntas frecuentes
¿Qué es el SPF flattening en términos sencillos?
El SPF flattening es el proceso de sustituir los mecanismos include:, a y mx de su registro SPF por las direcciones IP reales a las que resuelven. Esto ofrece a los servidores de correo receptores una lista ya preparada de IP autorizadas en lugar de obligarles a realizar consultas DNS, lo que mantiene su registro dentro del límite de 10 consultas definido por la RFC 7208 y evita los fallos de autenticación.
¿Por qué es necesario el SPF flattening?
El aplanamiento se hace necesario cuando su dominio supera el tope de 10 consultas DNS por evaluación que fija la especificación de SPF. Una vez cruzado ese límite, SPF devuelve un PermError y todos los mensajes de su dominio fallan la autenticación, lo que también puede hacer que DMARC falle. Como la mayoría de las organizaciones utilizan varios remitentes de terceros que cada uno añaden includes, los dominios en crecimiento alcanzan rápidamente el techo y necesitan aplanar para mantenerse en conformidad.
¿Mejora el SPF flattening la entregabilidad del correo?
Sí. Al eliminar las condiciones de PermError y TempError provocadas por demasiadas consultas o por includes de nivel superior lentos, el aplanamiento mantiene SPF aprobando de forma fiable. En los datos de clientes de AutoSPF, pasar de 12-18 consultas a un registro totalmente aplanado redujo los fallos de DMARC relacionados con SPF en más de un 80 % y mejoró la ubicación en bandeja de entrada del correo de marketing entre un 10 y un 15 % durante los envíos de mayor volumen.
¿Con qué frecuencia debe actualizarse un registro SPF aplanado?
Con la misma frecuencia con la que sus proveedores cambian de IP. Los ESP de alta rotación como SendGrid y Mailchimp justifican actualizaciones cada 12-24 horas, las suites estables como Google Workspace y Microsoft 365, diarias, y los rangos estáticos autoalojados, semanales. Un registro mantenido a mano casi siempre queda obsoleto; AutoSPF evita esto volviendo a analizar cada 15 minutos y republicando automáticamente cada vez que cambia un rango de nivel superior.
¿Es seguro el SPF flattening manual?
El aplanamiento manual solo es seguro para entornos pequeños y estáticos en los que las IP de envío rara vez cambian. Para cualquier dominio que utilice proveedores dinámicos, un registro construido a mano queda obsoleto en cuanto un proveedor rota su infraestructura, desautorizando en silencio a remitentes legítimos. El aplanamiento automatizado es muy preferible a cualquier escala real, porque seguir el ritmo de la rotación de los proveedores es la parte difícil.
¿Debo usar -all o ~all después de aplanar?
Use -all (fallo estricto) cuando tenga la certeza de que su lista aplanada está completa y se supervisa activamente, ya que ofrece a los receptores la señal más clara para rechazar el correo suplantado. Use ~all (fallo leve) durante el despliegue o mientras aún añade remitentes con frecuencia. Una buena práctica es mantener ~all hasta que los informes de DMARC muestren una ventana de aprobación limpia, y después endurecer a -all.