SPF con más de diez consultas DNS: por qué tu registro deja de valer

Qué es el límite

El SPF es un registro de texto que dice qué servidores pueden enviar correo con tu dominio. Casi nunca lista direcciones: lista permisos de otros, con include:, que a su vez apuntan a otros registros, que a su vez pueden apuntar a más. Para que un buzón no se quede resolviendo registros sin fin, la norma pone un tope: diez consultas DNS por comprobación.

Cuentan include, a, mx, redirect y exists, y cuenta todo lo que hay anidado dentro de cada include. No cuentan ip4 ni ip6, que ya son direcciones. Hay un segundo límite menos conocido: dos consultas que no devuelvan nada. Un include de una herramienta que cerró, o un a: de un nombre que ya no existe, gastan de ese cupo.

Pasado el límite, el buzón devuelve un error permanente. No es un fallo blando: para DMARC es como si el SPF no existiera. Y lo peor es que el registro sigue pareciendo correcto en el panel.

Por qué se llega sin darse cuenta

• Los includes esconden consultas. include:_spf.google.com parece uno y son cuatro, porque dentro lleva tres más. Un proveedor de correo puede sumar dos o tres consultas más de las que ves escritas.
• Las plantillas del hosting. Algunos hostings publican dos o tres includes para un solo servicio, y hay revendedores cuyo include lleva dentro el de Microsoft entero. Quien contrata Microsoft 365 a través de ellos tiene a Microsoft dos veces.
• Las variantes. Hay proveedores con un include distinto por región (.eu, .com) o con nombres antiguos y nuevos que apuntan a lo mismo. La documentación los lista todos y mucha gente los pone todos.
• Lo que se quedó. La herramienta de newsletter que se dejó hace dos años, la agencia que ya no está, el CRM de prueba. Nadie quita un include por si acaso.
• a y mx que no envían. El a: del propio dominio apunta a la web, que hoy suele estar detrás de una red de distribución y no envía correo. El mx: apunta a los servidores que lo reciben, que tampoco. Cada uno gasta una consulta a cambio de nada.

Cómo se arregla

1. Retirar lo que no envía. Si tienes DMARC con informes, en ellos se ve qué permisos se usan de verdad. Si no, pregunta a cada herramienta si todavía envía con tu dominio.
2. Quitar a y mx salvo que tu propio servidor envíe correo. Si tu web está en un hosting y el hosting envía los formularios, su include ya lo cubre.
3. Un solo registro. Si hay dos SPF, fúndelos en uno. Dos registros no valen ninguno.
4. Aplanar. Sustituir los includes por las direcciones que resuelven, en ip4 e ip6, que no cuentan. Es lo que más consultas ahorra, con dos condiciones: las direcciones cambian, así que hay que volver a resolver cada pocas horas y republicar, y el registro crece, así que hay que respetar los límites de longitud del DNS, partiéndolo en varias páginas enlazadas si hace falta. Lo que no se puede aplanar, como un ptr o un exists, se deja escrito tal cual.
5. Un subdominio por herramienta. Una herramienta que envía desde news.tudominio.com lleva su propio SPF, con su propio cupo de diez. Muchas plataformas de newsletter ya lo hacen así.

Lo que vemos en los dominios que vigilamos

• Más de la mitad de los permisos no se usan. Cruzando cada permiso del SPF con los informes de 30 días, en nuestra cartera más de la mitad de los include, a, mx e ip4 publicados no ha enviado ni un correo en ese tiempo. Cuatro de cada diez de esos permisos sin uso son a y mx: la web y los servidores de entrada, que no envían nada.
• Aplanado, un SPF normal se queda en una a cuatro consultas, con hueco de sobra para añadir herramientas sin acercarse al límite.
• Lo inaplanable existe. Un ptr dentro del include de un proveedor de buzones, o un exists con macros en el de una plataforma de envío, no se pueden convertir en direcciones. Se publican tal cual y cuentan su consulta. No son un error.
• La dirección de la web cambia a cada rato. Hay hostings cuyo a: devuelve direcciones distintas en cada consulta, porque la web va por una red de distribución. Aplanarlo es perseguir un blanco móvil: ese mecanismo se deja escrito.
• Dos SPF por accidente. No es raro, al dar de alta un dominio, encontrar un segundo registro SPF que añadió un panel al activar una herramienta, al lado del que ya existía. Desde ese momento ninguno de los dos vale, y nadie lo nota hasta que algo falla.