SPF y el límite de 255 caracteres: cadenas y división

ejemplo.es.  IN  TXT  ( "v=spf1 ip4:192.0.2.0/28 ip4:198.51.100.0/26 include:_spf.google.com "
                        "include:spf.protection.outlook.com include:sendgrid.net ~all" )

Dónde se rompe en la práctica: interfaces DNS y copiar-pegar

Ante un valor de más de 255 caracteres, las interfaces de los proveedores de DNS se reparten en tres familias. La primera rechaza en seco: mensaje de error explícito, el valor no se guarda. Molesto pero sano — el fallo es visible y se corrige en un minuto, dividiendo a mano. La segunda familia divide automáticamente: la interfaz acepta el valor largo y lo segmenta en cadenas conformes al generar la zona. Cloudflare procede así, y es el comportamiento ideal: el valor se pega de un bloque y los resolutores reciben un registro correcto.

La tercera familia es la peligrosa: la que trunca o corrompe en silencio. Un campo de formulario con un maxlength invisible amputa el valor pegado en el carácter 255, a menudo en plena mitad de un mecanismo — el registro publicado termina entonces en include:_spf.ejemplo- seguido de nada. Resultado: SPF sintácticamente inválido, permerror sistemático. Bajo DMARC, un permerror de SPF equivale a la ausencia de SPF: toda la autenticación descansa desde ese momento en DKIM, y los flujos que solo llevan SPF — ciertas herramientas de negocio, viejos servidores de aplicaciones — fallan sin más.

El copiar-pegar añade su propia capa de trampas: un salto de línea insertado por un cliente de correo o un procesador de textos, comillas tipográficas sustituidas a las rectas por un corrector automático, una interfaz que espera el valor desnudo y almacena las comillas como caracteres literales. Ninguna de estas corrupciones dispara una alerta en el momento de la introducción; solo se revelan en la verificación externa, una vez propagado el registro — de ahí el reflejo dig detallado más abajo.

El tamaño de las respuestas: UDP, EDNS y robustez

El límite por cadena no es la única razón para vigilar el peso de un SPF. El DNS transporta históricamente sus respuestas por UDP, con un techo de 512 bytes por mensaje heredado de la RFC 1035. La extensión EDNS0 elevó ese techo — la mayoría de los resolutores anuncian hoy 1 232 bytes, el valor recomendado desde el DNS Flag Day de 2020 —, pero el mecanismo de socorro no ha cambiado: una respuesta demasiado grande se marca como truncada (bit TC), y el cliente debe reintentar por TCP. Ahora bien, viejos cortafuegos siguen bloqueando el puerto 53 en TCP, y ciertos equipos intermedios maltratan los paquetes UDP voluminosos. Una respuesta obesa se convierte entonces en una respuesta perdida: el verificador devuelve temperror, y el mensaje legítimo queda diferido, o evaluado sin autenticación.

Un detalle agrava el cálculo: una consulta TXT devuelve todos los registros TXT del nombre, no solo el SPF. Los tokens de verificación acumulados con los años — google-site-verification=…, MS=…, validaciones de herramientas SaaS olvidadas — comparten la misma respuesta e hinchan su tamaño. Un SPF de 300 bytes dentro de una respuesta que ya carga 600 bytes de tokens cruza el umbral mucho antes de lo previsto. La RFC 7208 recomienda explícitamente mantener la respuesta en dimensiones modestas: la robustez aboga por la concisión, incluso cuando la división en cadenas hace la longitud perfectamente «legal».

Adelgazar un registro SPF obeso

Antes de dividir, mejor acortar. Un SPF obeso es casi siempre un SPF sedimentado: años de añadidos, nunca una retirada. La limpieza sigue un orden lógico.

• Los mecanismos muertos. La plataforma de emailing abandonada hace dos años, el servidor retirado, la agencia cuyo contrato terminó: sus include: y sus ip4: siguen en el registro. Los informes DMARC zanjan la cuestión — una fuente ausente de los informes desde hace meses puede salir.
• Las redundancias. Un ip4: que designa una dirección ya cubierta por un include:, dos include: del mismo proveedor bajo nombres distintos, un mx cuando los servidores entrantes nunca envían nada: bytes regalados.
• La agregación CIDR. Cuatro direcciones contiguas listadas una a una (ip4:192.0.2.16 ip4:192.0.2.17 ip4:192.0.2.18 ip4:192.0.2.19) se comprimen en un solo bloque ip4:192.0.2.16/30. En rangos más amplios, el ahorro se cuenta en decenas de bytes.
• El mecanismo ptr. Desaconsejado por la propia RFC 7208, costoso y poco fiable: su sitio está en los archivos, no en el registro.
• La delegación por subdominio. La palanca más potente: la newsletter sale de news.ejemplo.es, la facturación de billing.ejemplo.es, cada uno con su propio SPF corto. El dominio principal solo carga con sus flujos propios, y cada registro respira.

Dos técnicas vecinas merecen una remisión más que un tratamiento aquí. El aplanamiento — sustituir los include: por sus direcciones IP resueltas — reduce las consultas DNS pero alarga el registro, exactamente lo contrario del objetivo de esta página; sus promesas y sus trampas se examinan en el aplanamiento SPF y sus riesgos. En cuanto a las macros de la RFC 7208, capaces de compactar radicalmente ciertos casos de uso, tienen su propio artículo: las macros SPF y el mecanismo exists.

255 caracteres y 10 lookups: dos límites que nada une

El límite de los 255 caracteres se confunde con regularidad con el otro techo célebre de SPF: los diez mecanismos que desencadenan una consulta DNS (include, a, mx, ptr, exists, más el modificador redirect). Y sin embargo no comparten nada. El primero es una restricción de codificación del DNS: se mide en bytes y se sortea limpiamente con la división en cadenas. El segundo es una regla del propio SPF: se cuenta en resoluciones DNS y desemboca en un permerror normativo a partir de la undécima consulta.

La confusión nace de que ambos golpean a las mismas víctimas — los registros que crecieron sin vigilancia —, pero los remedios divergen, y a veces chocan frontalmente. El aplanamiento cura los lookups agravando el tamaño; la división en cadenas cura el tamaño sin retirar una sola consulta. Un registro muy corto puede reventar el techo de consultas (tres include: anidados bastan), mientras que un registro de 350 bytes compuesto únicamente de ip4: no consume ni un lookup. Identificar cuál de los dos techos plantea realmente el problema es, pues, el requisito previo a toda corrección — el techo de las diez consultas DNS tiene su propio manual de uso, y conviene leerlo antes de tocar nada.

La verificación: dig, comillas y recuento

La verificación no exige más que dig, presente en cualquier máquina Unix (o nslookup -type=TXT en Windows):

$ dig +short TXT ejemplo.es
"v=spf1 ip4:192.0.2.0/28 include:_spf.google.com " "include:sendgrid.net ~all"
"google-site-verification=kX3v…"

La salida lo dice todo. Cada par de comillas materializa una cadena: dos pares en la línea SPF significan que el registro está dividido y que la división sobrevivió a la interfaz del proveedor. El espacio de unión se controla a simple vista — aquí, al final de la primera cadena. El recuento global cabe en un comando:

$ dig +short TXT ejemplo.es | grep spf1 | wc -c

Lo esencial no es el total, sino el reparto: cada cadena individual debe quedarse por debajo de los 255 bytes, algo que la presencia de varias cadenas entre comillas demuestra de un vistazo. Tres reflejos completan el utillaje: verificar tras la propagación (el TTL del registro antiguo puede enmascarar el cambio durante horas), interrogar a un resolutor público (@1.1.1.1, @9.9.9.9) en lugar de la caché local, y vigilar los informes DMARC en los días siguientes — un permerror por truncamiento se lee allí negro sobre blanco, donde la interfaz DNS jamás mostrará nada.

En resumen

El «límite de los 255 caracteres» de SPF es en realidad una regla del DNS: 255 bytes por cadena de caracteres de un registro TXT, nunca por registro. Un SPF largo sigue siendo conforme si está dividido en varias cadenas que el verificador concatena sin añadir espacios; las roturas reales vienen de las interfaces que truncan en silencio, de los copiar-pegar corrompidos y de las respuestas DNS que se han vuelto demasiado grandes para UDP. El orden correcto de las operaciones: adelgazar primero (mecanismos muertos, redundancias, agregación CIDR, subdominios dedicados), dividir después si aún hace falta, verificar siempre con dig — y no confundir nunca este límite de bytes con el techo de las diez consultas DNS, que obedece a otras leyes y reclama otros remedios.

Para saber en unos segundos si el registro de un dominio roza el límite, está dividido con limpieza o arrastra bytes muertos, un análisis DMARC gratuito muestra el estado de SPF junto a DKIM y la política DMARC, división incluida. Y para seguir en el tiempo lo que los informes cuentan de las fuentes reales del dominio, la creación de una cuenta abre la vigilancia continua — el límite de los 255 bytes, ese, no se moverá.