Aplanador SPF — cuenta lookups, expande includes anidados, genera un registro plano
Escribe un dominio. El navegador resuelve el registro SPF publicado en el ápex, sigue recursivamente cada mecanismo include, a, mx, redirect y exists vía DNS sobre HTTPS, cuenta el total de consultas DNS contra el límite RFC 7208 de 10, cuenta void lookups contra el límite separado de 2, y genera una versión aplanada con todos los mecanismos resueltos a direcciones ip4 e ip6 directas. Ves el registro original, la matemática de lookups, la salida aplanada lista para publicar, y avisos si el resultado excede 255 caracteres por string TXT o 450 caracteres totales. Sin cuenta, sin límites de tasa; toda la resolución corre en tu navegador.
Aplana el registro SPF de un dominio
Introduce cualquier dominio. La consulta corre en tu navegador vía DNS sobre HTTPS de Cloudflare. Includes recursivos grandes pueden tomar unos segundos.
DNS sobre HTTPS vía cloudflare-dns.com · Sin datos enviados a nuestros servidores
El aplanado SPF reemplaza cada mecanismo que consulta DNS en tu registro con las direcciones IP a las que esos mecanismos resuelven — convirtiendo una cadena de lookups anidados en una lista estática de IPs
RFC 7208 — la especificación SPF — fija un límite duro de 10 consultas DNS durante la evaluación de cualquier registro SPF. Los mecanismos que consumen un lookup son include:, a, mx, ptr, exists y el modificador redirect=. Los mecanismos que no consumen lookup son ip4:, ip6: y all. Los receptores deben devolver un resultado permerror cuando la evaluación excede 10 lookups, sin importar cuán sintácticamente correcto sea el resto del registro. Un límite separado y menos citado capa los "void lookups" — consultas DNS que devuelven NXDOMAIN o respuesta vacía — en 2 por evaluación; excederlo también produce permerror.
La aritmética se vuelve implacable rápido con stacks reales de remitentes. Solo Google Workspace consume alrededor de 4 lookups cuando expandes sus includes anidados; Microsoft 365 (spf.protection.outlook.com) añade 2; SendGrid añade 1; Mailchimp transaccional y marketing añaden 3+; Salesforce añade 2+; HubSpot añade 1-2. Una empresa que corre Google + un proveedor transaccional + una plataforma marketing + un CRM + una o dos herramientas de nicho fácilmente cae en 12-14 lookups. El registro se ve limpio — media docena de entradas include: — pero cada receptor que lo evalúa devuelve permerror, cada chequeo de alineación DMARC falla en la pata SPF, y la colocación en bandeja se degrada en Gmail, Outlook y Yahoo simultáneamente. El fallo es silencioso: ningún rebote explica "SPF too many lookups" en lenguaje claro, y los operadores normalmente lo encuentran corriendo un check como el de arriba.
El aplanado resuelve el problema de lookups pre-resolviendo cada mecanismo de consulta en el momento que publicas el registro. La herramienta camina el TXT de cada include, sigue includes anidados recursivamente, recolecta cada dirección ip4: e ip6: que encuentra, y reescribe tu SPF como una lista plana. Resultado: un registro con cero mecanismos include: (o un número pequeño, si mantienes uno o dos estratégicamente) y una larga lista de literales IP. El conteo de lookups cae a 1 — solo el lookup raíz del SPF mismo — y los receptores evalúan el registro entero sin nunca tocar el techo de 10 lookups.
El compromiso es mantenimiento. Cuando Google añade un nuevo rango de envío a _spf.google.com, tu include:_spf.google.com vivo recoge el cambio automáticamente; tu registro aplanado no. Los grandes proveedores actualizan sus rangos IP publicados silenciosamente y en su propio calendario — típicamente unas pocas veces al año para los grandes, más frecuentemente para servicios menores. Un registro aplanado obsoleto significa que correo legítimo de una IP de proveedor recién introducida empieza a fallar SPF, lo que significa fallar alineación DMARC, lo que significa degradación de inbox. La disciplina es: aplana cuando debes, monitoriza mensualmente, re-aplana cuando el siguiente check revele drift.
Para clientes en LATAM y España el contexto regulatorio refuerza la importancia operativa. La AEPD ha priorizado en sus guías 2024-2025 la autenticación de dominio como medida técnica razonable bajo Art. 32 RGPD; un permerror SPF sostenido durante meses, que cualquier auditor B2B puede detectar en segundos, debilita el argumento de medidas apropiadas. La ANPD brasileña hace énfasis análogo bajo LGPD; el INAI mexicano lo incorpora en sus criterios de seguridad para responsables del tratamiento. Para una fintech mexicana, una aseguradora colombiana o un retailer chileno con clientes B2B europeos, mantener SPF bajo el límite de 10 lookups y DMARC en enforcement es parte del estándar mínimo razonable que un auditor de seguridad de cliente esperará ver.
Cada mecanismo en un registro SPF, cuántos lookups cuesta y qué vigilar
include:dominio 1 lookup mínimo, más todos los lookups anidados dentro de ese registro incluido. La fuente más común de exceso. Cada gran proveedor SaaS publica su propio SPF, y esos registros a menudo anidan 2-4 includes más dentro.
a · a:dominio 1 lookup. Resuelve el registro A/AAAA del dominio (o del dominio del registro SPF si es desnudo). Reemplaza con ip4: o ip6: cuando conozcas la IP.
mx · mx:dominio 1 lookup para el registro MX, luego 1 lookup adicional por servidor MX devuelto para resolver sus IPs. Un dominio con 3 servidores MX consume 4 lookups por un solo mecanismo mx.
redirect=dominio 1 lookup, más todos los lookups dentro del registro redirigido. Se comporta como reemplazo completo del SPF. Combinar redirect con otros mecanismos es técnicamente inválido por RFC 7208.
exists:dominio 1 lookup. Prueba si un nombre de dominio resuelve. Raro en remitentes modernos; usado en SPF basado en macros para evaluación por destinatario.
ptr · ptr:dominio 1 lookup, pero RFC 7208 explícitamente desaconseja ptr por problemas de rendimiento y fiabilidad. Quítalo. Siempre.
ip4:direccion · ip6:direccion 0 lookups. Literal IP estático — el objetivo del aplanado. Acepta tanto direcciones individuales como rangos CIDR.
all · -all · ~all · ?all · +all 0 lookups. Disposición final: -all fallo duro, ~all fallo blando (más común), ?all neutro, +all pasa todo (efectivamente desactiva SPF — nunca usar). Siempre el último mecanismo del registro.
Aplanar es uno de cinco enfoques razonables para mantenerse bajo 10 lookups. La elección correcta depende de cuán a menudo cambia tu stack de envío
1. Quita lo que no usas
Siempre el primer paso. La mayoría de registros SPF cargan includes para servicios que la empresa probó hace seis meses y nunca dieron de baja. Mailgun, Postmark, ese ESP que alguien evaluó y nunca migró — quítalos. El registro más limpio es el que autoriza solo lo que está enviando hoy. Normalmente vemos 2-4 lookups recuperados solo por quitar entradas obsoletas.
2. Reemplaza mx y a con IPs directas
Si las IPs de tu servidor de correo son estables — lo que suelen ser para Postfix autoalojado o un MTA gestionado — reemplaza los mecanismos mx y a con literales ip4:. Un solo mecanismo mx puede consumir 4+ lookups cuando está anidado. Las IPs directas consumen cero. El compromiso es monitorización: cuando re-IPees, actualiza SPF.
3. Aplana todo (esta herramienta)
La opción nuclear. Reemplaza cada include: con las IPs a las que esos includes resuelven hoy, baja el conteo de lookups a 1, y acepta la carga de mantenimiento de re-aplanar mensualmente. Correcto para remitentes con stack de proveedor estable (Google + 1-2 SaaS), incorrecto para remitentes constantemente evaluando nuevas herramientas.
4. Delegación por subdominio
Enrutar diferentes tipos de remitente a través de diferentes subdominios: transaccional desde tx.ejemplo.com, marketing desde mkt.ejemplo.com, interno desde mail.ejemplo.com. Cada subdominio tiene su propio registro SPF, cada uno se mantiene bajo 10 lookups, y el ápex lleva solo los remitentes más críticos. Añade complejidad DNS pero resuelve limpiamente el problema arquitectónico.
5. SPF hospedado (AutoSPF, EasySPF, PowerSPF)
Reemplaza tu SPF con un único include apuntando a un servicio hospedado. Ellos resuelven y refrescan las IPs de tus proveedores continuamente, tú mantienes un SPF de una línea, y pagas una cuota mensual ($10-$30/mes a volúmenes SMB típicos). Correcto para equipos que cambian de proveedores frecuentemente y quieren externalizar el mantenimiento. El compromiso es dependencia: si su servicio cae o cambia términos, tu autenticación se rompe.
Aplanar arregla permerror. No arregla alineación DMARC, firma DKIM ni elegibilidad BIMI — esos son problemas separados sobre el mismo conjunto de registros
Un registro SPF con cero lookups aún falla DMARC si el dominio del remitente del sobre no se alinea con el del header From. Un registro SPF plano aún es inútil sin firma DKIM, porque DMARC requiere que SPF o DKIM pase y se alinee; un remitente que falla alineación SPF pero pasa alineación DKIM aún pasa DMARC. El modelo mental correcto es: SPF autoriza IPs a enviar por tu dominio, DKIM prueba que el mensaje no ha sido manipulado, DMARC orquesta ambos con política. Arreglar lookups SPF te saca del modo de fallo permerror; no te lleva a autenticación grado-enforcement por sí solo.
El trabajo más largo — el que nuestros clientes gestionados nos contratan para hacer — es el despliegue de sin-autenticación a DMARC p=reject: ingerir informes agregados para identificar cada remitente legítimo, arreglar alineación SPF y DKIM para cada uno, poner la delegación de subdominio correcta en su lugar, y validar la cadena de extremo a extremo antes de declarar enforcement. El aplanador SPF de arriba es un paso en ese trabajo.
Lo que los equipos preguntan al correr el aplanador SPF por primera vez
¿Cada cuánto necesito re-aplanar?
+
Una vez al mes es la respuesta operativamente honesta. Los grandes proveedores — Google, Microsoft, SendGrid — actualizan sus rangos SPF publicados unas pocas veces al año, a menudo sin anuncio público. Los proveedores menores actualizan más frecuentemente. Un registro aplanado que funcionó perfectamente en enero empieza a tirar correo legítimo en marzo cuando uno de los proveedores añade una nueva región de envío. La disciplina que funciona en práctica: programa un recordatorio mensual de calendario, corre el aplanador, compara la nueva salida con lo publicado actualmente, actualiza si algo cambió.
¿Puedo aplanar el include de Microsoft 365? ¿El de Google Workspace?
+
Técnicamente sí, operativamente no recomendado para esos dos específicamente. Microsoft y Google actualizan sus rangos de IP de envío en su propio calendario y con mayor frecuencia que los proveedores menores. Un include Microsoft 365 aplanado con dos meses tiene probabilidad no trivial de perder IPs de envío recién añadidas, causando que correo legítimo de tu tenant falle SPF. La documentación de Microsoft recomienda mantener include:spf.protection.outlook.com en tu SPF top-level y aplanar includes menos actualizados a su alrededor. Google publica una recomendación similar. El patrón que funciona: mantén los 1-2 includes de proveedores principales vivos, aplana todo lo demás, y termina en 3-4 lookups totales en vez de 12-14.
¿Qué es un "void lookup" y cómo evito chocar con el límite de 2?
+
Un void lookup es una consulta DNS que no devuelve registro — sea NXDOMAIN (el dominio no existe) o respuesta vacía (el dominio existe pero no tiene registro de ese tipo). RFC 7208 limita estos a 2 por evaluación SPF; el tercer void lookup produce un permerror, sin importar cuántos lookups regulares tengas.
Las fuentes usuales: un include: apuntando a un dominio que ha sido decomisionado (el SaaS cerró, el subdominio fue eliminado), un mecanismo a o mx para un hostname que ya no resuelve, o un mecanismo ptr (los lookups ptr son particularmente propensos a respuestas void en IPs sin rDNS configurado). El aplanador de arriba marca cualquier void lookup que encuentra durante la resolución; revisa y quítalos antes de publicar.
¿Aplanar romperá mi alineación DMARC?
+
No — aplanar solo afecta el conteo de lookups, no la matemática de alineación. La alineación DMARC depende de si el dominio del remitente del sobre (el MAIL FROM, usado para SPF) coincide con el dominio del header From. Un registro SPF aplanado autoriza las mismas IPs que el original; si tu correo pasaba alineación SPF antes, pasará después. Lo que puede romperse es DMARC pass globalmente, no alineación específicamente — si la IP de un proveedor cambia después de que aplanas y tu registro se vuelve obsoleto, el correo de ese proveedor empieza a fallar autenticación SPF de plano.
¿Pueden combinarse múltiples registros SPF?
+
No — RFC 7208 prohíbe explícitamente múltiples registros SPF en el mismo dominio. Si un dominio tiene dos o más registros TXT empezando con v=spf1, los receptores tratan la configuración como inválida y devuelven permerror, ignorando ambos registros. Este es uno de los errores SPF más comunes que vemos: una herramienta de seguridad publica un nuevo registro sin quitar el existente, y SPF se rompe silenciosamente en todo el dominio. La solución es consolidación. Combina los mecanismos de cada registro en un solo registro TXT empezando con v=spf1, borra los demás, espera la propagación DNS (típicamente 24 horas), y verifica con un lookup nuevo.