El vendor stacking y el límite de consultas de SPF: por qué falla el correo electrónico empresarial

Contra qué protege SPF (y contra qué no)

SPF es un protocolo de autenticación de correo electrónico basado en DNS. El propietario de un dominio publica un registro TXT que enumera los servidores autorizados para enviar correo electrónico en nombre de ese dominio.

Cuando un servidor receptor recibe un mensaje, comprueba si la IP remitente coincide con el registro SPF del dominio. Si coincide, la comprobación se supera. Si no, el servidor receptor gestiona el mensaje según tu política DMARC.

SPF solo protege lo que figura explícitamente en la lista. Si un servicio de envío no tiene una entrada SPF, sus mensajes fallan SPF, independientemente de que utilices ese servicio de forma legítima. Para una auditoría, esto significa que comprobar la sintaxis del registro no es suficiente. También necesitas confirmar exactamente qué remitentes está autorizando.

El límite de 10 consultas

El RFC 7208, el estándar que define SPF, establece un límite estricto de 10 consultas DNS por evaluación SPF. Este límite se aplica a los mecanismos que requieren consultas DNS: include, a, mx y exists. Los mecanismos como ip4 e ip6 no consumen consultas.

Cuando un servidor receptor evalúa tu registro SPF y alcanza el límite de 10 consultas, el resultado es un PermError. La mayoría de los servidores receptores lo interpretan como un fallo de autenticación.

Considera este registro SPF:

El registro contiene 7 mecanismos include. Cada include genera al menos una consulta DNS, y una cadena de include puede anidar más consultas.

Este es el problema del vendor stacking.

Cómo el vendor stacking daña tu registro SPF

Las empresas suelen enviar mensajes desde muchas fuentes: un servidor de correo principal, una plataforma de automatización de marketing, un CRM, un servicio transaccional y, posiblemente, varias herramientas regionales o departamentales añadidas con el tiempo. Cada proveedor requiere una entrada SPF, normalmente un mecanismo include, que apunta a su registro SPF.

El problema no es el número de proveedores. El problema es que cada proveedor controla su propia infraestructura SPF y la optimiza para sus necesidades, no para las tuyas. Los proveedores añaden y cambian rangos de IP, y sus cadenas anidadas de include se expanden con el tiempo. No tienes visibilidad de esos cambios a menos que audites con regularidad.

La consecuencia operativa: un registro que se resuelve dentro del límite de 10 consultas en el momento de la implementación puede superarlo meses después, cuando un proveedor actualiza su propia infraestructura SPF.

El registro en sí nunca cambió – el vendor stacking causó el daño desde fuera.

Soluciones SPF: rediseñar tu cadena de include

Para las empresas que ya están cerca del límite de 10 consultas, la solución al vendor stacking no es añadir más includes. Cada uno de los pasos siguientes trabaja hacia el mismo resultado: un registro SPF listo para producción que se mantiene firme a medida que los proveedores cambian su infraestructura.

Audita lo que realmente utilizas. Consulta tus reportes agregados de DMARC e identifica cada fuente de envío que está superando SPF, y comprueba cómo afecta cada una a tu recuento total de consultas. Elimina las entradas SPF obsoletas de los servicios que ya no utilizas. Los proveedores antiguos y las plataformas en desuso suelen permanecer en los registros SPF mucho después de haber sido retirados.

Sustituya su cadena de include por rangos de IP directos siempre que sea posible. Si un proveedor envía desde un conjunto de IP estable y documentado, sustituye sus includes por mecanismos ip4 o ip6. Esto elimina el costo de consultas de ese remitente y reduce tu recuento total de consultas.

Utilice subdominios para servicios de envío específicos. Si el registro de su dominio principal está cerca de su capacidad, delega los correos electrónicos transaccionales o de marketing en un subdominio. Cada subdominio puede tener su propio registro SPF con su propio presupuesto de 10 consultas.

Valida después de cada cambio. Después de actualizar tu registro, realiza un recuento completo de consultas. No te fíes solo del número de un único validador. Abre cada include a mano, mira a qué apunta y cuenta cada consulta que añade, incluido cualquier include anidado en su interior.

Cómo ayuda Sendmarc

Gestionar SPF a gran escala, en múltiples dominios y proveedores de envío requiere una visibilidad que la inspección del DNS por sí sola no proporciona. La función de optimización de SPF de Sendmarc supervisa continuamente el registro SPF de cada dominio y aplana automáticamente los includes anidados en direcciones IP directas, neutralizando el vendor stacking y manteniendo el registro dentro del límite de 10 consultas incluso cuando los proveedores cambian su infraestructura.

Sendmarc rastrea cada include anidado y cada cambio de proveedor que podría alterar tu recuento de consultas, para que tus dominios permanezcan protegidos a medida que evoluciona tu entorno de envío.

Explora las capacidades de gestión de SPF de Sendmarc.