Qué es el aplanamiento de SPF (SPF flattening) y cuándo usarlo de verdad

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
  ip4:167.89.0.0/17 ip4:168.245.0.0/17 ... -all

La trampa: las IP de los proveedores cambian

Esto es lo que las guías entusiastas suelen olvidar decir. Los rangos de IP detrás de un include de proveedor no están fijados. Microsoft, Google, SendGrid y los demás añaden, retiran o reorganizan sus servidores con regularidad. Ese es precisamente todo el interés del include: apunta a un registro que el proveedor mantiene al día.

Aplanar rompe ese vínculo. La operación congela una instantánea de las IP del proveedor en la fecha del aplanamiento. El día en que este cambia a un nuevo rango no recopiado, el correo emitido desde ese rango falla en SPF, y nada lo señala en el momento. Es la ironía cruel del aplanamiento: un PermError corregido hoy a cambio de fallos silenciosos mañana.

El otro coste oculto: el tamaño del registro

El mantenimiento no es el único reverso del aplanamiento: hay uno puramente mecánico. Sustituir un puñado de include por todos los rangos de direcciones que contienen puede transformar un registro de una línea en un registro enorme. Ahora bien, el DNS impone verdaderas restricciones: una cadena TXT está limitada a 255 caracteres, así que un registro largo debe trocearse en varias cadenas, y una respuesta muy voluminosa puede superar lo que ciertos resolutores gestionan cómodamente en UDP, provocando truncamiento y nuevos intentos. Nada insalvable, pero es fragilidad añadida exactamente allí donde se buscaba robustez, y cada re-aplanamiento vuelve a mover el registro. Antes de aplanarlo todo, la pregunta merece plantearse: ¿no produce el remedio un registro tan masivo que se convierte en un riesgo operativo por sí solo?

Aplanamiento manual o automatizado

Para gestionar este riesgo, dos escuelas:

• El aplanamiento manual consiste en resolver y recopiar las IP a mano. Simple de entender, pero es precisamente ahí donde muerde la deuda: sin vigilancia, el registro caduca en cuanto el proveedor se mueve. A reservar para proveedores cuyos rangos son estables y documentados.
• El aplanamiento automatizado delega el seguimiento a un servicio que re-aplana periódicamente y actualiza el registro (a menudo mediante una delegación DNS o un include hacia un registro gestionado). La deuda de mantenimiento se cambia entonces por una dependencia de ese servicio y, en la práctica, un include (hacia el servicio) reaparece en el SPF. No es un mal, pero la mecánica del include no ha desaparecido de verdad: solo ha cambiado de sitio.

Cuándo el aplanamiento es una buena idea…

El aplanamiento no hay que demonizarlo. Tiene su lugar cuando:

• el recuento está realmente bloqueado por encima de diez resoluciones y las otras palancas no bastan;
• los proveedores tienen rangos de IP estables (ciertas infraestructuras cambian rara vez);
• una vigilancia está en marcha para señalar la evolución de una IP de proveedor, o un servicio automatizado fiable toma el relevo.

En esas condiciones, es una herramienta legítima para mantener un registro complejo bajo la barra.

…y cuándo vale más evitarlo

Para muchas organizaciones, el aplanamiento es una respuesta desproporcionada. Antes de recurrir a él, más vale agotar las opciones más sanas:

1. Hacer limpieza de los include inútiles. La mitad de los desbordamientos viene de herramientas que ya no se usan. Es gratis y sin riesgo.
2. Separar los flujos por subdominio. Marketing en news.ejemplo.es, transaccional en notif.ejemplo.es: cada subdominio tiene su propio presupuesto de diez resoluciones, y los include mantenidos por los proveedores siguen en su sitio. Es el enfoque más duradero, y el que recomendamos en primer lugar.
3. Sustituir solo los proveedores con IP estables por ip4:, dejando en include los que se mueven.

En la gran mayoría de los casos, estas tres palancas bastan para volver a bajar de diez sin la deuda del aplanamiento completo. La secuencia detallada está en el límite de 10 búsquedas DNS.

Un caso real: la pyme multiproveedor

Ilustrémoslo con una situación muy común. Una pyme envía desde Microsoft 365 (mensajería), un router de marketing, una herramienta de facturación y un servicio de firma electrónica. Su SPF apila cuatro include, que se despliegan en trece resoluciones: PermError garantizado. La tentación es aplanarlo todo de golpe. Mala idea: tres de esos cuatro proveedores cambian sus rangos de IP varias veces al año.

La buena lectura del caso empieza por clasificar los proveedores según la estabilidad de sus IP, no según su volumen. Microsoft 365 publica un include rico pero bien mantenido: se conserva en include, porque congelarlo obligaría a correr detrás de sus actualizaciones mensuales. El servicio de firma, en cambio, solo tiene un puñado de IP fijas documentadas: se pueden inscribir en ip4: sin riesgo, ahorrando una resolución. El router de marketing, gran consumidor, se lleva a un subdominio news.pyme.com con su propio SPF, así que abandona por completo el recuento del dominio raíz.

Resultado: el dominio raíz ya no lleva más que Microsoft 365 (en include), la facturación (en include) y la firma (en ip4:), o sea cinco o seis resoluciones, bajo la barra, y sin aplanar el proveedor más inestable. Solo se ha aplanado lo que era seguro aplanar. Eso es el buen uso del aplanamiento: un bisturí dirigido a las IP estables, no un hacha sobre todo el registro. El mantenimiento residual se limita a vigilar el puñado de ip4: congelados, algo que un control trimestral cubre de sobra.

La cualificación terminal no hay que sacrificarla

Un reflejo a evitar, que a menudo se ve acompañar al aplanamiento: aprovechar la reforma para pasar a ~all «por seguridad». El aplanamiento no cambia nada en el rigor de un SPF: -all (hardfail) sigue siendo la buena cualificación terminal para un dominio dominado. Aplanar y debilitar son dos decisiones distintas, que sobre todo no hay que confundir. El matiz se explica en los mecanismos -all y ~all.

Verificar después del aplanamiento

Una vez el registro aplanado, dos controles se imponen:

1. El recuento de resoluciones ha vuelto a bajar de diez, y la sintaxis es válida: un vistazo en nuestro analizador gratuito, como se describe en cómo verificar un registro SPF.
2. Las fuentes siguen pasando, en el tiempo. Los informes agregados de las semanas siguientes merecen vigilancia: una fuente que empieza de repente a fallar en SPF es la señal de que un rango de IP ha cambiado y de que el aplanamiento ha envejecido.

Preguntas frecuentes

¿Mejora el aplanamiento la entregabilidad? No directamente. Corrige un PermError que, ese sí, lastraba la entregabilidad, así que el efecto neto puede ser positivo. Pero aplanar un SPF ya bajo el límite no aporta nada y añade deuda.

¿Hay que re-aplanar a menudo? Depende de la estabilidad de los proveedores. Algunos casi nunca se mueven, otros cambian sus rangos varias veces al año. Sin servicio automatizado, una revisión regular se impone: es justamente la deuda que hay que anticipar.

¿El aplanamiento sortea también los límites de DKIM? La pregunta no procede: DKIM no tiene límite de resoluciones. El problema de las diez búsquedas es propio de SPF. Es además una razón para cuidar la alineación DKIM, más robusta: ver cómo funcionan los tres protocolos juntos.

¿Se puede poner todo en ip4: y no tener ningún include? Técnicamente sí, pero la responsabilidad de cada IP de cada proveedor pasa entonces a ser interna, de por vida. Rara vez es razonable, salvo para una infraestructura de envío enteramente dominada por la organización.

¿El aplanamiento resuelve el doble registro SPF? No, son dos problemas distintos. Tener dos registros v=spf1 es un error de configuración que corregir fusionándolos en uno solo, independientemente del recuento de resoluciones.

Thomas elige el enfoque adecuado

¿Hay que aplanar, hacer limpieza o trocear en subdominios? La respuesta depende de los proveedores reales y de la estabilidad de sus IP. Thomas, el CISO virtual, despliega el SPF, identifica los include glotones, distingue los que se pueden congelar sin riesgo de los que se mueven, y recomienda la corrección más duradera para el caso tratado, no la más de moda.

Analizar un dominio gratis o crear una cuenta para mantener un SPF limpio y bajo la barra.