Macros SPF y el mecanismo exists: ir más allá del límite de 10 búsquedas

Las macros SPF: un dominio que se reescribe solo

Las macros son toda una sección de la RFC 7208 (sección 7) que casi nadie usa a mano. Permiten insertar, dentro de un mecanismo, variables que se sustituyen en el momento de la evaluación por datos de la conexión en curso. Las más útiles:

• %{i} — la dirección IP del cliente que intenta enviar el mensaje.
• %{ir} — la misma dirección, pero invertida (para la IPv4 203.0.113.5 da 5.113.0.203).
• %{d} — el dominio evaluado.
• %{v} — la cadena in-addr para IPv4, ip6 para IPv6 (útil para distinguirlas).

La inversión de %{ir} no es un capricho: reproduce la lógica del DNS inverso (in-addr.arpa), donde se lee la dirección de lo más específico a lo más general. El resultado es que cada octeto de la IP se convierte en una etiqueta DNS distinta, lo que permite construir árboles de zonas muy finos. Ya empiezas a ver hacia dónde vamos.

El núcleo: una resolución, un número ilimitado de IP

Junta las dos piezas y obtienes esto:

v=spf1 exists:%{ir}._spf.example.com -all

Un único mecanismo con coste de resolución, así que una sola resolución en el recuento de diez. Pero observa lo que ocurre al evaluar. Un servidor recibe un mensaje cuya IP emisora es 203.0.113.5. Reescribe la macro y consulta:

5.113.0.203._spf.example.com

En ese momento, decide tu servidor DNS. La zona _spf.example.com, que tú controlas, responde de una de dos maneras:

• devuelve un registro A (por convención 127.0.0.1) → el exists coincide → la IP está autorizada, SPF pasa;
• devuelve NXDOMAIN (nombre inexistente) → el exists no coincide → caes en el -all, SPF falla.

El interruptor reside por completo en cómo responde tu zona a estos nombres sintéticos. Puedes conectarla a una base de datos de decenas de miles de IP, a una generación dinámica, a reglas geográficas, a una lista por remitente… Una resolución, N autorizaciones. El límite de diez no se aleja: simplemente deja de aplicarse, porque ya solo tienes un mecanismo con coste de resolución, y la inteligencia ha migrado del fichero de zona a la lógica del servidor DNS.

Así es precisamente como algunos grandes emisores ofrecen a sus clientes «un solo include, remitentes ilimitados»: detrás de su include se esconde a menudo un exists con macro que autoriza dinámicamente su parque de IP cambiante, sin hacer estallar jamás el recuento de sus clientes.

Un ejemplo concreto de principio a fin

Imagina una empresa que envía desde un parque de IP amplio y cambiante: varios centros de datos, direcciones que se añaden y se retiran cada semana. Como include clásico, ese parque consumiría por sí solo la mayor parte del presupuesto de diez, y la menor incorporación podría volcarlo en PermError. Con la técnica de macros:

v=spf1 include:_spf.corp.example exists:%{ir}.%{v}._auth.example.com -all

El include cubre el correo estándar (Microsoft 365, por ejemplo, que dejas mantenido por el proveedor). El exists delega todo el parque dinámico a la zona _auth.example.com. El %{v} distingue allí IPv4 de IPv6, de modo que una sola regla sirve a ambas familias. Cuando una IP envía, la zona consulta el inventario al día y responde en consecuencia. Añadir mil direcciones mañana no cambia nada en el registro SPF publicado: sigue en dos mecanismos con coste de resolución, muy por debajo de la barrera. El mantenimiento ha abandonado el DNS público por el inventario interno, donde de todos modos es más fácil de mantener al día.

Las contrapartidas (porque las hay)

Si esta técnica fuera perfecta, todo el mundo la usaría y el error «too many lookups» ya no existiría. No lo es, por buenas razones.

Necesitas una zona DNS programable. El exists con macro solo sirve si tu servidor DNS puede responder dinámicamente a nombres sintéticos que nunca ha visto. Un alojamiento DNS estático clásico, donde escribes registros uno a uno en una interfaz, no sabe hacerlo. Necesitas o un DNS que programas tú mismo, o un servicio especializado que exponga esta mecánica. Ese es el verdadero coste de entrada.

Tu SPF se vuelve opaco. Un auditor que lee exists:%{ir}._spf.example.com ya no puede enumerar tus IP autorizadas: el conjunto ha desaparecido del fichero de zona para vivir dentro de la lógica de un servidor. Es una pérdida de legibilidad asumida. Para un dominio sometido a revisión de cumplimiento, esa pérdida de transparencia no es trivial: ya no demuestras tu configuración leyendo un registro.

La depuración es más difícil. Cuando una fuente legítima falla, ya no puedes leer el registro para entender por qué: tienes que consultar tú mismo el nombre sintético que corresponde a su IP y ver qué devuelve tu zona. Es factible, pero menos inmediato que un registro en claro.

Desplazas el riesgo, no lo eliminas. La autorización ya no depende de un texto fijo, sino del comportamiento de un servicio. Un error en la lógica de tu zona, o su compromiso, puede autorizar a un atacante con el mismo silencio con que autoriza a tus servidores. El rigor que ponías en tu registro debes ponerlo ahora en tu backend DNS.

Macros, aplanamiento o subdominios: ¿cuál elegir?

Estos tres enfoques responden al mismo síntoma pero no juegan en la misma liga.

El aplanamiento de SPF congela las IP de los proveedores en tu registro: sencillo de montar, pero frágil, porque esas IP cambian y tu instantánea caduca. El reparto por subdominio da a cada flujo su propio presupuesto de diez resoluciones: es el enfoque más sano para la gran mayoría de las organizaciones, y el que recomendamos primero. Las macros con exists solo se justifican en un caso preciso: un parque de IP amplio, dinámico y controlado internamente, con una infraestructura DNS capaz de responder al vuelo. Para un sitio que apila cuatro include de proveedores estándar, es un mazazo: la limpieza y los subdominios bastan, sin la complejidad de una zona programada.

Dicho de otro modo: las macros no son «la mejor» solución, son la solución de los grandes emisores técnicos. Si no perteneces a esa categoría, ganarás pasando antes por nuestro analizador DMARC gratuito para ver si una simple limpieza te devuelve por debajo de la barrera; casi siempre es así.

Preguntas frecuentes

¿Es estándar o un apaño? Perfectamente estándar. El mecanismo exists y las macros están escritos con todas las letras en la RFC 7208 (secciones 5.7 y 7). No es un rodeo contra la especificación, es un uso que la especificación previó, solo que avanzado.

¿Los servidores destinatarios lo admiten? Los grandes operadores (Gmail, Microsoft, Yahoo…) implementan las macros correctamente. La cautela viene de validadores más antiguos o marginales, cuyo soporte de macros a veces es incompleto, de ahí el interés de conservar un -all limpio y un DKIM sólido como red de seguridad.

¿Aun así cuenta como una resolución? Sí, el exists cuesta una resolución. Y cuando una IP no está autorizada, la respuesta NXDOMAIN cuenta como una «void lookup», pero la RFC tolera dos, así que un único exists sin resultado se mantiene dentro de los márgenes. Lo que no debes hacer es apilar varios exists que fallen todos.

¿Y con IPv6? %{ir} funciona también en IPv6, pero la dirección se despliega allí en 32 etiquetas (el formato «nibble» del DNS inverso ip6.arpa). Tu zona debe, por tanto, manejar ambas formas; ahí es donde la macro %{v} (in-addr frente a ip6) ayuda a encaminar con limpieza.

¿Es arriesgado en cuanto a seguridad? El riesgo se desplaza a tu backend DNS. Mientras su lógica de autorización sea correcta y esté protegida, tu postura sigue siendo sana. Un error ahí, en cambio, tiene el mismo efecto que un +all mal colocado: abre la puerta. Manéjalo con el mismo rigor con el que evitas un PermError y cuidas el resto de tu configuración.

Deja que Thomas juzgue si de verdad lo necesitas

Las macros con exists son una herramienta de especialista, no un reflejo. Antes de programar una zona DNS, hay que estar seguro de que el problema lo merece. Thomas, tu CISO virtual, despliega tu SPF, mide tu recuento real de resoluciones, detecta los include más pesados y te dice con honestidad qué vía te conviene: una simple limpieza, un reparto por subdominio, un aplanamiento selectivo o, si tu parque de verdad lo exige, las macros. La herramienta adecuada para tu situación, no la más impresionante.

Analiza tu dominio gratis → o crea una cuenta para saber exactamente cómo está tu SPF.