SPF Flattener

Qué es el SPF flattening (y qué no es)

El SPF flattening reemplaza los mecanismos que cuestan consultas (include:, a, mx, redirect, exists) por direcciones IP literales (ip4: / ip6:), que cuestan cero consultas. Sobre el papel "funciona" porque elimina las consultas intermedias.

La trampa: congela una delegación viva en una foto fija. Tus proveedores actualizan sus rangos de IP; tu aplanamiento estático no. Por eso conviene distinguir dos cosas que no son lo mismo:

• Aplanamiento estático: copias las IP a día de hoy y se quedan grabadas. Empieza a quedarse obsoleto en cuanto un proveedor cambia una IP.
• SPF dinámico (macros o alojado): el registro se recalcula o se actualiza solo, sin deuda de obsolescencia.

Ejemplo, antes:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all

Ejemplo, después (foto fija):

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:198.2.128.0/18 ~all

Ese "después" es una instantánea congelada que se degrada: el día que un proveedor añade o retira una IP, deja de reflejar la realidad. Si quieres profundizar en la diferencia, lee aplanamiento SPF frente a macros.

El límite de 10 consultas DNS y el permerror

La RFC 7208 §4.6.4 fija un máximo de 10 consultas DNS al evaluar un SPF. Coste por mecanismo:

Cuando superas las 10, el resultado es permerror, y eso es un doble fallo: tu correo legítimo puede acabar rechazado o en spam, los suplantadores dejan de quedar bloqueados de forma fiable y la alineación DMARC se rompe para todos tus flujos.

Hay un segundo límite que casi nadie comprueba: más de 2 consultas vacías (void lookups, una consulta que no devuelve registros) también provoca permerror según la misma RFC. La herramienta expone ese recuento de consultas vacías junto al de consultas normales.

Cuidado con confundir el permerror por consultas con el permerror por sintaxis: aplanar no arregla ni la sintaxis ni el caso de tener varios registros SPF en el dominio. Para esos casos la herramienta devuelve un veredicto de error que debes resolver antes. Si llegaste aquí por el mensaje literal, mira cómo corregir SPF too many DNS lookups y la guía del permerror SPF, o diagnostica el registro con el SPF Checker.

Por qué aplanar es arriesgado (cambio de IP)

El riesgo no es teórico. Un aplanamiento estático provoca tres problemas:

• Falsos negativos: una IP nueva y legítima de tu proveedor que aún no está en el registro falla SPF.
• Superficie de suplantación: una IP retirada que sigue autorizada en tu registro queda abierta a abuso.
• Fallos intermitentes difíciles de diagnosticar: unos correos pasan y otros no, sin patrón evidente.

Dos referencias documentadas, sin generalizar:

• Mailhardener documentó un caso real: tras aplanar, un proveedor añadió una IP de balanceador de carga y eso hizo que fallara aproximadamente 1 mensaje de cada 20.
• Según la telemetría de AutoSPF, un include de terceros cambia en mediana cada 11,5 días, y los destinos IPv6 cambian unas 2,1 veces más que los IPv4 (cifra indicativa de mejor esfuerzo).

Hay además una trampa de tamaño: aplanar resuelve el límite de consultas pero empeora el de tamaño (255 caracteres por cadena TXT, 512 bytes en UDP, en la práctica unos 450 a 600 caracteres útiles). El registro se hincha en decenas de bloques ip4: e ip6:.

Microsoft 365 y Google Workspace publican rangos de IP grandes y cambiantes, lo que hace frágil un aplanamiento estático. La herramienta muestra una etiqueta de riesgo de cambio por proveedor (bajo, medio o alto): es una clasificación editorial, no una cadencia inventada.

Para medir el impacto en la recepción, consulta la puntuación de entregabilidad.

Alternativas antes de aplanar (ordenadas por riesgo creciente)

Esta es la columna vertebral del enfoque: prueba estas opciones en orden, de la más segura a la más arriesgada.

1. Depura primero. Quita los include: sin uso o que nunca pasan, elimina ptr (desaconsejado por la RFC), retira a/mx redundantes y deduplica. Muchas veces vuelves por debajo de 10 sin congelar ni una IP. Cruza los datos con los informes agregados de DMARC para saber qué fuentes envían de verdad.
2. Delegación por subdominio. Un subdominio dedicado por flujo de envío, cada uno con su propio presupuesto de 10 consultas. Sin miedo: con alineación DMARC relajada (aspf=r) la alineación se mantiene, DMARC no se rompe.
3. Macros SPF (RFC 7208 §7). Registro dinámico, sin deuda de obsolescencia; opción avanzada.
4. SPF alojado o CNAME autoactualizable. Se mantiene al día, pero con honestidad: implica dependencia del proveedor y pérdida de control directo sobre tu DNS.
5. Traslada la confianza a DKIM + DMARC (con ARC y SRS). La clave conceptual: el aplanamiento nunca arregla los fallos de reenvío ni de listas de correo, porque SPF comprueba la IP que conecta, y esa cambia al reenviar. La robustez viene de DKIM (sobrevive al relay) y de la alineación DMARC vía DKIM, reforzada con ARC y SRS. Puedes montar la política con el generador DMARC.

Cuándo aplanar está justificado de verdad

El caso es estrecho: ya has depurado, no puedes delegar ni pasarte a alojado, estás genuinamente por encima de 10 con remitentes todos esenciales, y te comprometes a resincronizar. Aplanar es deuda de mantenimiento, no un arreglo de una sola vez.

Cuando puedas, prefiere lo dinámico (macros o alojado) frente a lo estático. Si aun así aplanas de forma estática, vigílalo de forma continua con el SPF Checker y asume el riesgo de cambio de IP que acabas de leer. En una línea: un aplanamiento estático de una sola vez es una deuda, no una solución. Para validar el envío de punta a punta, pasa por el Mail Tester.

Cómo leer el veredicto de la herramienta

La herramienta no te empuja a aplanar: te dice cuándo no hacerlo. Sus cinco veredictos:

• En regla (ok): estás por debajo del límite, no necesitas aplanar. Deja el registro como está.
• En riesgo (at_risk): cerca del límite, vigílalo y no añadas remitentes a la ligera.
• Por encima del límite (over_limit): permerror, arréglalo con prioridad.
• Error (error): no se puede aplanar todavía; corrige antes la sintaxis o el caso de varios SPF.
• Falta SPF (missing): publica primero un registro SPF.

El marcador del presupuesto te muestra "X / 10 consultas" y "V / 2 consultas vacías". Refuerza la regla principal: veredicto verde, registro intacto.

Preguntas frecuentes

P: ¿Qué es el SPF flattening y necesito aplanar de verdad?

R: El SPF flattening reemplaza los mecanismos que cuestan consultas (include, a, mx, redirect, exists) por direcciones IP literales (ip4/ip6). La mayoría de los registros se mantienen por debajo de 10 consultas y no lo necesitan. Si la herramienta te da un veredicto verde, deja el registro como está.

P: ¿Cómo funciona el límite de 10 consultas DNS (RFC 7208)?

R: La RFC 7208 limita la evaluación SPF a 10 consultas DNS. Cada include, a, mx, ptr, exists y redirect cuenta una consulta; ip4, ip6 y all cuestan cero. Por encima de 10 el resultado es permerror. Existe un segundo límite olvidado: más de 2 consultas vacías también provoca permerror.

P: ¿Cómo soluciono el error "too many DNS lookups" o permerror?

R: No aplanes por reflejo. Depura primero los include sin uso o que nunca pasan, quita ptr y elimina duplicados: eso suele devolverte por debajo de 10. Después valora la delegación por subdominio. Aplanar va el último.

P: ¿Es seguro el aplanamiento SPF?

R: Conlleva un riesgo real: un aplanamiento estático congela las IP de los proveedores. En un caso documentado por Mailhardener, añadir una IP de balanceador de carga hizo que fallara aproximadamente 1 mensaje de cada 20. Según la telemetría de AutoSPF, un include de terceros cambia en mediana cada 11,5 días. Prefiere opciones dinámicas.

P: ¿Cuáles son las alternativas al aplanamiento?

R: Ordenadas por riesgo creciente: depurar, delegar por subdominio (con alineación DMARC relajada aspf=r), macros SPF, SPF alojado/CNAME y trasladar la confianza a DKIM + DMARC. Empieza siempre por la opción más segura.

P: ¿El aplanamiento rompe DMARC o arregla los fallos de reenvío?

R: El aplanamiento no arregla los fallos de reenvío ni de listas de correo, porque SPF comprueba la IP que conecta y esa cambia al reenviar. La robustez DMARC viene de la alineación por DKIM; la delegación por subdominio con aspf=r mantiene intacta la alineación.

P: ¿Aplanamiento estático frente a SPF alojado o dinámico?

R: El estático es una foto fija de IP que se degrada con el tiempo; el dinámico (macros o alojado) se actualiza solo. No los confundas: solo el dinámico evita la deuda de mantenimiento.

P: Aplané y arreglé las consultas, pero mi registro es ahora demasiado largo, ¿por qué?

R: El límite de tamaño (255 caracteres por cadena, 512 bytes en UDP) es independiente del de consultas. Aplanar cambia el problema de consultas por uno de tamaño. La solución pasa por fragmentar la cadena o dividir en subdominios.

P: ¿SPF Flattener, SPF Generator o SPF Checker, cuál uso?

R: El SPF Checker diagnostica tu registro; el SPF Generator crea uno nuevo desde cero; el SPF Flattener es el optimizador de último recurso que te dice antes si de verdad hace falta aplanar.

Herramientas complementarias

Recursos útiles

• RFC 7208 - Sender Policy Framework (SPF): el origen del límite de 10 consultas, de las consultas vacías y de las macros
• RFC 4408 - SPF (versión anterior): versión heredada de la especificación
• dmarcian - SPF Best Practices: autoridad que concluyó su experimento de aplanamiento
• Mailhardener - Do not flatten your SPF record: la fuente del caso de aproximadamente 1 de cada 20
• Google Workspace - configurar y solucionar SPF: guía para configurar y diagnosticar SPF con Google
• Microsoft 365 - configurar SPF: guía para configurar y diagnosticar SPF con Microsoft