Se alcanzó el límite de SPF: corrige los registros DNS antes de que afecten al correo electrónico legítimo

Qué es el límite de SPF

SPF permite al propietario de un dominio especificar qué fuentes están autorizadas a enviar mensajes en su nombre. Los destinatarios utilizan la política SPF publicada para comprobar si el remitente está autorizado.

El límite de SPF es el número máximo de consultas DNS que un servidor receptor puede realizar durante una evaluación. Cuando un servidor de correo electrónico receptor comprueba tu registro SPF, no puede realizar más de 10 consultas DNS. Si el recuento supera las 10, el receptor debe devolver un error permanente (PermError).

No todos los mecanismos o modificadores de SPF cuentan para ese total. Los principales que sí cuentan son:

• include
• a
• mx
• ptr
• exists
• redirect

Los términos all, ip4 e ip6 no cuentan para el límite de 10 consultas, ya que no activan consultas DNS durante una evaluación de SPF. También existen sublímites adicionales relacionados con mx y ptr, lo cual es una de las razones por las que los registros complejos se vuelven frágiles más rápido de lo que los equipos esperan.

En la práctica, el límite de SPF es una medida de protección del protocolo. Existe para evitar una carga de consultas excesiva. Cuando tu política supera lo que permite el protocolo, el resultado no es una validación degradada. Es un error.

¿Qué ocurre cuando el SPF tiene demasiadas consultas DNS?

Cuando el SPF tiene demasiadas consultas DNS, el servidor receptor devuelve un PermError. Esto significa que el receptor no pudo interpretar correctamente la política SPF publicada del dominio debido a las reglas del protocolo. Un PermError es una condición de error que requiere actualizaciones del DNS.

El efecto en las etapas posteriores es más complejo. DMARC no exige que tanto SPF como DKIM se superen. Un DMARC aprobado puede seguir dándose si DKIM se supera. Por lo tanto, un permerror de SPF no provoca automáticamente un fallo de DMARC si DKIM sigue superándose.

Por eso, a menudo este problema se manifiesta como un problema de entrega antes de que se identifique como un problema de configuración de SPF.

Lo primero que pueden notar los equipos es que:

• Los correos electrónicos para restablecer la contraseña han dejado de llegar
• No se envían las facturas ni los avisos de pago
• Los correos electrónicos de asistencia no llegan a determinados destinatarios
• El rendimiento de la campaña disminuye

¿Qué provoca el error «Demasiadas consultas DNS de SPF»?

Demasiados includes

Esta es la causa más común. Cada include apunta a otro registro. Esto resulta práctico cuando los proveedores tienen sus propios registros, pero el número aumenta rápidamente. Una unidad de negocio añade una plataforma. Otra añade dos más. Al final, el registro supera lo que permite el protocolo.

Uso excesivo de los mecanismos de consulta de DNS

Los registros también se vuelven peligrosos cuando los equipos dependen en gran medida de a, mx, exists o redirect. Estos términos son válidos, pero todos ellos contribuyen al límite de consultas DNS. Un registro puede parecer breve en el DNS, pero al comprobarlo puede generar demasiadas consultas.

Registros de proveedores anidados

El registro visible no siempre es el verdadero problema. Un include puede apuntar a otro registro con varios includes más. Sobre el papel, tu registro SPF puede parecer manejable. En realidad, el recuento total de consultas puede superar con creces el límite.

Remitentes antiguos que nunca se eliminaron

Los antiguos sistemas de tickets, las herramientas de campañas ya retiradas y los proyectos puntuales suelen permanecer en los registros SPF mucho después de que el servicio haya dejado de utilizarse. El riesgo aumenta con el tiempo porque las entradas sin uso siguen contando al comprobar el SPF.

Sin propiedad centralizada

El SPF suele quedar a cargo de varios equipos. Marketing gestiona un remitente. TI gestiona otro. El servicio de asistencia gestiona un tercero. Seguridad revisa la política solo cuando surge algún problema. Sin una propiedad centralizada, el registro SPF crece como subproducto de las compras y las operaciones.

Cómo reducir las consultas SPF

1. Hacer un inventario de todos los servicios que envían correos electrónicos

Empieza por analizar el panorama real de los remitentes. Documenta todas las plataformas, herramientas, proveedores y servicios de terceros que envían correos electrónicos utilizando el dominio. Incluye los sistemas transaccionales, las herramientas de CRM, las plataformas de RR. HH. y los servicios financieros.

No optimices el SPF antes de saber qué sistemas deben seguir funcionando.

2. Comprueba el registro SPF y todos los términos de consulta DNS

Debes contar cada término de consulta DNS que el servidor receptor evalúa durante la comprobación de SPF. Esto también incluye los includes anidados.

Presta atención a estos mecanismos y modificadores:

• include
• a
• mx
• ptr
• exists
• redirect

Si el recuento ampliado es igual o superior a 10, tienes un problema de límite de SPF.

3. Eliminar remitentes que no se utilizan o que están duplicados

Esta suele ser la forma más rápida de reducir tu registro. Los sistemas retirados, las entradas duplicadas de proveedores y los proyectos temporales suelen permanecer en los registros SPF.

Comprueba si cada remitente sigue siendo necesario. Si una plataforma ya no envía correos electrónicos, elimínala. Si hay varios servicios que se repiten de forma redundante, consolídalos siempre que sea posible.

4. Simplificar siempre que lo permita el control administrativo

Cuando controles la infraestructura de envío, utiliza entradas SPF estables y directas en lugar de largas cadenas de includes. Las entradas estáticas de ip4 e ip6 no consumen el presupuesto de consultas de SPF. Suelen ser más fáciles de usar que los registros de terceros.

Esto puede reducir rápidamente el número de búsquedas y facilitar la revisión del registro.

5. Trasladar los flujos de correo electrónico a subdominios alineados

A veces, la solución adecuada es la separación, no la compresión. Si los correos de marketing, asistencia y transaccionales se envían todos desde el mismo dominio raíz, separar determinados flujos hacia subdominios alineados puede reducir la complejidad del SPF y mejorar la propiedad.

6. Utiliza una herramienta de simplificación de SPF

La simplificación de SPF puede reducir el número de consultas al sustituir las búsquedas de DNS por direcciones IP ya resueltas. Utilizada con cuidado, es una de las formas más prácticas de mantenerse dentro del límite de SPF sin dejar de permitir el envío por parte de terceros.

Los registros simplificados deben mantenerse actualizados a medida que cambia la infraestructura del proveedor. Una solución de simplificación estática sin actualizaciones continuas puede quedar obsoleta y provocar fallos de autorización de forma inadvertida más adelante.

7. Volver a realizar la prueba de SPF y confirmar que el registro se mantiene dentro de los límites

Una vez realizados los cambios, vuelve a comprobar el registro y valida de nuevo el recuento total de consultas. Confirma que la política se mantiene dentro de los límites del protocolo y que sigue autorizando a todos los remitentes necesarios.

Este es también el momento en el que los equipos deben confirmar que los flujos de correo electrónico importantes siguen pasando DMARC después de los cambios en el SPF.

8. Supervisar el registro para detectar desviaciones por parte del proveedor

Un registro SPF puede pasar de estar en buen estado a ser de riesgo sin que se produzca ningún cambio directo en tu propio DNS. Los proveedores pueden actualizar sus propios registros SPF o añadir nuevos includes. Dado que SPF cuenta las consultas en todos los registros vinculados, los cambios por parte de los proveedores pueden acercarte cada vez más al límite con el tiempo.

Por eso es importante realizar revisiones periódicas. La tarea no termina solo porque el registro sea válido hoy. Se da por concluida cuando el dominio puede asimilar los cambios futuros sin sobrepasar el límite de SPF.

Comprueba el estado de tu SPF antes de que la incorporación de un nuevo remitente convierta un registro manejable en un problema de entrega.

Cómo ayuda Sendmarc a reducir el riesgo de SPF y de autenticación del correo electrónico

Sendmarc ayuda a los equipos a detectar antes el riesgo de SPF y a gestionar la autenticación del correo electrónico de forma más coherente en todos sus dominios.

Esto es importante porque los problemas de SPF rara vez se producen de forma aislada. Un dominio que está cerca del límite de SPF suele presentar también una visibilidad deficiente del remitente, una cobertura DKIM inconsistente, registros DNS obsoletos o una propiedad fragmentada entre equipos y proveedores. Si estos problemas no se resuelven, los mismos problemas de SPF suelen reaparecer.

Sendmarc ayuda a los equipos a gestionar los registros SPF, DKIM, DMARC, BIMI, MTA-STS y TLS-RPT de forma más coherente en todos sus dominios. Esto facilita ver dónde está creciendo el riesgo de autenticación y qué registros se están volviendo demasiado complejos.

Para los equipos que se enfrentan específicamente a la complejidad de SPF, la Solución de simplificación de SPF de Sendmarc ofrece una forma práctica de reducir los términos de consulta DNS.

Obtén visibilidad sobre el riesgo de SPF, reduce la resolución manual de problemas y mantén el flujo de correos críticos a medida que crece tu huella de remitente.