Cómo aplanar un registro SPF
Para aplanar un registro SPF, resuelva cada mecanismo que provoca consultas (include, a, mx) en direcciones ip4/ip6 explícitas, deduplique y agregue los rangos, y publique después un único registro por debajo del límite de 10 consultas de la RFC 7208.
Aplanar un registro SPF significa sustituir los mecanismos que provocan consultas DNS — include:, a, mx, exists, ptr y redirect — por los rangos explícitos ip4: e ip6: a los que resuelven. El resultado es un registro que autoriza exactamente a los mismos remitentes pero que obliga a los servidores receptores a realizar muchas menos consultas DNS (idealmente ninguna), manteniéndole con seguridad por debajo del límite de 10 consultas de la RFC 7208. Esta guía recorre el proceso paso a paso, muestra cómo es un registro aplanado y explica cómo mantenerlo exacto una vez publicado.
Esta página forma parte de nuestra guía más amplia sobre SPF flattening. Si desea evitar por completo el trabajo manual, el SPF Checker expande cada include y cuenta sus consultas en segundos.
Por qué querría aplanar un registro SPF en primer lugar
La autenticación SPF está limitada a 10 consultas DNS por evaluación según la RFC 7208. Cada término include:, a, mx, exists y redirect cuenta dentro de ese presupuesto, y cada uno puede provocar más consultas recursivas dentro del dominio al que apunta. Añada una plataforma de marketing, un CRM, un helpdesk y un servicio de facturación, y un único registro v=spf1 puede dispararse discretamente hasta 15-40 consultas.
Cuando cruza el límite, los receptores devuelven un PermError. Un PermError no solo hace fallar un mensaje: invalida todo el registro, de modo que el correo legítimo de cualquier origen autorizado puede empezar a fallar la comprobación SPF. Como nada rebota de forma ruidosa, los equipos a menudo no se dan cuenta hasta que un cliente informa de una factura o un correo de restablecimiento de contraseña que no llegó.
El aplanamiento resuelve esto resolviendo esos mecanismos indirectos por adelantado y publicando las IP en bruto. Un receptor que evalúa un registro totalmente aplanado hace una simple comparación de IP sin recorrido recursivo del DNS, lo que además significa una validación más rápida y ninguna exposición a una caída temporal del DNS de un tercero.
Cómo es un registro SPF aplanado
Este es un registro típico sin aplanar que se apoya en tres includes:
v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -allCada include es al menos una consulta, y el include de Google por sí solo anida varias más. Aplanada, la misma autorización se convierte en una lista directa de IP:
v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -allNo se produce ninguna consulta en el momento de la evaluación porque todas las direcciones autorizadas ya están detalladas. Se conserva el cualificador -all para que la política siga siendo estricta.
Cómo aplanar un registro SPF, paso a paso
Paso 1: Localice y audite su registro actual
Recupere su registro SPF existente con una consulta dig TXT sudominio.com (o el panel de control de su proveedor de DNS) y confirme que tiene exactamente un registro TXT v=spf1. Varios registros SPF con el mismo nombre son en sí mismos un PermError. Anote qué mecanismos provocan consultas (include, a, mx, exists, redirect, ptr) frente a las entradas ip4/ip6 sin coste que puede conservar tal cual.
Paso 2: Cuente sus consultas
Antes de cambiar nada, mida cuánto se ha pasado del presupuesto. Analice su dominio con el SPF Checker, que expande recursivamente cada include y le da un recuento exacto de consultas. Si está en 8 o más, o ya está viendo PermError, el aplanamiento (o la delegación) está justificado. Si está en 3 o menos includes estables, es posible que no necesite aplanar en absoluto.
Paso 3: Resuelva recursivamente cada mecanismo a IP
Este es el núcleo del aplanamiento. Para cada término que provoca una consulta, resuélvalo hasta direcciones explícitas:
| Mecanismo | Cómo resolverlo | Resultado |
|---|---|---|
include: | Recupere el registro SPF del destino y expanda sus mecanismos recursivamente | ip4:/ip6: por cada IP que autoriza |
a | Resuelva los registros A/AAAA del dominio | Un ip4:/ip6: por dirección |
mx | Resuelva los registros MX y, después, los A/AAAA de cada host de correo | ip4:/ip6: por cada IP de host MX |
ptr | No lo aplane: está obsoleto, es lento y poco fiable | Elimínelo |
exists: | Normalmente no se puede aplanar (depende de macros en tiempo de ejecución) | Consérvelo tal cual o aíslelo en un subdominio |
ip4/ip6 | Ya son estáticos | Consérvelos sin cambios |
Recorra el grafo en profundidad (depth-first) y lleve el control de qué dominios ya ha visitado para poder detectar includes circulares: si un include apunta de vuelta a un dominio que ya está en su pila de resolución, deténgase y consérvelo como include en lugar de entrar en un bucle infinito.
Paso 4: Deduplique y agregue los CIDR
La expansión recursiva produce solapamientos. Dos proveedores pueden compartir una IP, o puede reunir varios bloques /25 adyacentes que se combinan limpiamente en un /24. Deduplique cada dirección y, después, agregue los rangos adyacentes en superredes solo cuando la unión permanezca por completo dentro del espacio autorizado de un mismo proveedor. Sobreagregar entre proveedores no relacionados autoriza IP que usted no controla: una regresión de seguridad, no una optimización.
Paso 5: Vigile el tamaño del registro
Las cadenas TXT de DNS están limitadas a 255 caracteres por segmento entre comillas; los registros más largos deben dividirse en varias cadenas concatenadas dentro del mismo registro. Como regla práctica, mantenga la respuesta total por debajo de unos 450-900 bytes para evitar la fragmentación por UDP y los problemas con middleboxes. Si la lista aplanada es demasiado grande, divida las IP en etiquetas auxiliares (p. ej. spf-a.example.com, spf-b.example.com) que contengan solo entradas ip4/ip6 e inclúyalas desde el registro principal: cada auxiliar cuesta una consulta, así que mantenga el total ≤ 10.
Paso 6: Vuelva a añadir el cualificador all y valide
Añada su mecanismo de terminación original: se recomienda -all para una aplicación estricta en el caso de remitentes de producción. Después, vuelva a analizar el registro con un validador de SPF para confirmar que la sintaxis está limpia, que sigue habiendo un solo registro y que el recuento de consultas es el esperado. Si migra con cautela, puede publicar con ~all durante un breve periodo y luego cambiar a -all una vez que la supervisión muestre tasas de aprobación estables.
Paso 7: Publique con un TTL bajo y súbalo después
Antes de publicar, baje el TTL del registro a 60-300 segundos para poder corregir rápidamente cualquier error. Publique el nuevo registro aplanado, verifique que se resuelve correctamente desde varios resolvedores públicos (Google, Cloudflare, Quad9) y vigile sus informes agregados de DMARC por si hay alguna caída en las tasas de aprobación de SPF. Una vez que las cosas estén estables, vuelva a subir el TTL a 1-4 horas.
La trampa: los registros aplanados quedan obsoletos
Aquí está el problema que hace tropezar a la mayoría de quienes aplanan a mano. En el momento en que aplana, su registro es una instantánea. Cuando Google, Mailchimp, Amazon SES o cualquier otro proveedor rota sus IP de envío — y los grandes ESP lo hacen constantemente — su lista codificada a mano deja de coincidir con la realidad. El correo procedente de las nuevas IP falla la comprobación SPF en silencio, y usted vuelve a las facturas perdidas y a los restablecimientos de contraseña fallidos, salvo que ahora la causa es invisible porque el registro parece correcto.
Los remitentes respaldados por CDN y de marketing son los peores infractores: los datos internos de AutoSPF a través de más de 1.200 dominios muestran que los remitentes respaldados por CDN rotan entre el 8 y el 15 % de su conjunto de IP mensualmente, frente a menos del 0,5 % de los servidores de correo internos. Aplanar a ciegas un proveedor de alta rotación es buscarse problemas.
Las conclusiones prácticas:
- Aplane los orígenes estables (relés locales, IP estáticas en la nube) de forma agresiva.
- Deje los ESP volátiles como includes, o aíslelos tras un subdominio delegado como
mail-out.example.comque la raíz incluye con una única consulta. - Nunca trate el aplanamiento como algo de una sola vez: necesita una nueva resolución continua.
Automatice el reaplanamiento con AutoSPF
Hacer los pasos 1-7 a mano cada vez que un proveedor cambia de IP no es realista. Esto es exactamente para lo que está diseñado el servicio de aplanamiento automático de SPF de AutoSPF. Ejecuta continuamente el algoritmo de aplanamiento determinista anterior: vuelve a analizar sus includes cada 15 minutos y, cuando cambian las IP de un proveedor de nivel superior, actualiza automáticamente su registro publicado a través de la API de su proveedor de DNS, con intercambios atómicos, TTL escalonados y reversión de un solo clic si una comprobación canary falla.
Fundamentalmente, AutoSPF resuelve a las mismas IP exactas a las que resuelven sus includes: nunca amplía la autorización con fusiones de CIDR demasiado amplias, así que no autoriza por accidente a remitentes que no pretendía. Usted mantiene un registro pequeño y estable en la raíz; AutoSPF lo mantiene correcto en segundo plano.
Para decidir cuáles de sus orígenes aplanar frente a delegar, consulte nuestra guía sobre las mejores herramientas de SPF flattening. Si prefiere evitar por completo codificar IP a mano, compare los enfoques en SPF flattening frente a macros. Y antes de aplanar, conviene confirmar que el cambio no alterará sus otros registros de autenticación: consulte ¿el SPF flattening afecta a DKIM y DMARC?.
Preguntas frecuentes
¿Aplanar un registro SPF rompe DKIM o DMARC?
No, cuando se hace correctamente. El aplanamiento solo cambia qué IP autoriza SPF: no toca las firmas DKIM ni la alineación de DMARC. El riesgo es indirecto: si un registro aplanado obsoleto empieza a fallar la comprobación SPF para correo legítimo, eso puede arrastrar a la baja las tasas de aprobación de DMARC. Mantenga el registro resuelto de nuevo y ambos se mantendrán sanos.
¿Cuántas consultas DNS usa un registro SPF aplanado?
Un registro totalmente aplanado usa cero consultas DNS en el momento de la evaluación, porque cada IP autorizada figura de forma explícita como ip4:/ip6:. Si conserva algunos includes volátiles o divide las IP en etiquetas auxiliares, cada una de ellas añade una consulta; simplemente mantenga el total en el límite de 10 de la RFC 7208 o por debajo.
¿Puedo aplanar los mecanismos ptr y exists?
En general no. ptr está obsoleto, es lento y simplemente debería eliminarse. exists: suele apoyarse en macros en tiempo de ejecución (evaluando MAIL FROM o HELO en el momento de la comprobación), por lo que no puede reducirse a una lista estática de IP. Conserve exists tal cual, o aíslelo en un subdominio delegado para limitar su impacto en las consultas.
¿Con qué frecuencia necesita actualizarse un registro SPF aplanado?
Con la misma frecuencia con la que sus remitentes cambian sus IP. Los servidores de correo internos pueden ser estables durante semanas, pero los grandes ESP y las CDN pueden cambiar de dirección a diario. Por eso el aplanamiento manual es frágil y AutoSPF vuelve a analizar cada 15 minutos, publicando un registro actualizado automáticamente cada vez que cambia un conjunto de IP de nivel superior.
¿Qué ocurre si mi registro aplanado se vuelve demasiado grande?
Los registros TXT de DNS están limitados a 255 caracteres por cadena, y los registros de gran tamaño corren el riesgo de fragmentación por UDP. Si la lista de IP aplanada es demasiado grande, divídala en etiquetas auxiliares (cada una con solo entradas ip4/ip6) e inclúyalas desde el registro principal, o delegue los proveedores volátiles en un subdominio. Procure mantener la respuesta total por debajo de ~900 bytes y las consultas ≤ 10.
¿Debo aplanar mi registro SPF manualmente o usar una herramienta?
El aplanamiento manual funciona para una solución de una sola vez, pero no puede seguir el ritmo de los proveedores que rotan IP: un registro aplanado a mano desautoriza en silencio a remitentes en cuanto cambia un rango de nivel superior. Una herramienta gestionada como AutoSPF se encarga por usted de la resolución recursiva, la deduplicación, la gestión del tamaño y el reaplanamiento continuo, y por eso es el enfoque recomendado para cualquier cosa que vaya más allá de un único remitente estático.