La acumulación de proveedores y el límite SPF : por qué falla el correo electrónico empresarial

Resumen sobre el apilamiento de proveedores:

SPF solo los remitentes que figuran explícitamente en el registro, y la RFC 7208 limita este número a 10 consultas DNS.
Si se supera ese límite, se produce un PermError, que la mayoría de los servidores receptores interpretan como un error de autenticación.
La acumulación de proveedores, y no el número de proveedores, es la principal causa de los incumplimientos del límite de consultas.
Corregir un registro que se acerca al límite implica revisar su uso y sustituir includes con direcciones IP directas y utilizando subdominios.
No se debe confiar en el recuento de ningún validador por sí solo; hay que comprobar manualmente la totalidad de include cadena para confirmar tu total real.

Has añadido un SPF a tu DNS. Has incluido tu proveedor de correo electrónico, tu CRM y tu plataforma de marketing. A simple vista, parece que está todo completo. Pero si tu registro no tiene en cuenta el límite de 10 consultas DNS, es posible que ya lo hayas superado.

SPF un mecanismo básico de autenticación del correo electrónico. Sin embargo, sus limitaciones intrínsecas y implementación hacen que la mayoría de las organizaciones lo implementen de forma incompleta.

En esta entrada se explica cómo SPF , cómo el hecho de superar el límite de 10 consultas provoca fallos reales, cómo la acumulación de proveedores hace que el número de registros supere dicho límite y cómo rediseñar tu include cadena.

Contra qué SPF (y contra qué no SPF

SPF un protocolo de autenticación de correo electrónico basado en el DNS. El propietario de un dominio publica un registro TXT en el que se enumeran los servidores autorizados para enviar correo electrónico en nombre de dicho dominio.

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

SPF solo lo que se indica explícitamente. Si un servicio de envío no tiene una SPF , sus mensajes no superan SPF, independientemente de si utilizas ese servicio de forma legítima. A efectos de una auditoría, esto significa que no basta con comprobar la sintaxis del registro. También es necesario confirmar exactamente a qué remitentes autoriza.

El límite de 10 búsquedas

La RFC 7208, la norma que define SPF, establece un límite máximo de 10 consultas de DNS según SPF . Este límite se aplica a los mecanismos que requieren consultas DNS: include, a, mxy exists. Mecanismos como ip4 y ip6 No consumas consultas.

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

Fíjate en este SPF :

Host	Tipo	Valor
`@`	`TXT`	`v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.mandrillapp.com include:servers.net include:mail.zendesk.com include:spf.salesforce.com -all`

El registro contiene 7 include mecanismos. Cada uno include provoca al menos una consulta DNS, y un include La cadena puede anidar más búsquedas.

Este es el problema de la acumulación de proveedores.

Cómo el «vendor stacking» perjudica tu SPF

Las empresas suelen enviar mensajes desde numerosas fuentes: un servidor de correo electrónico principal, una plataforma de automatización de marketing, un CRM, un servicio transaccional y, posiblemente, varias herramientas regionales o departamentales que se han ido incorporando con el tiempo. Cada proveedor requiere una SPF , normalmente un include mecanismo, que apunta a su SPF .

El problema no es el número de proveedores. El problema es que cada proveedor controla su propia SPF y la optimiza según sus propias necesidades, no las tuyas. Los proveedores añaden y modifican rangos de IP, y sus include Las cadenas se amplían con el tiempo. No es posible detectar esos cambios a menos que se realicen auditorías periódicas.

La consecuencia operativa: un registro que se resuelve dentro del límite de 10 consultas en el momento de la implementación puede sobrepasar dicho límite meses más tarde, cuando un proveedor actualice su propia SPF .

El disco en sí nunca se estropeó; el apilamiento de los discos por parte de los proveedores fue lo que causó el daño desde el exterior.

SPF : Rediseño de tu `include` Cadena

Para las empresas que ya se acercan al límite de 10 búsquedas, la solución al problema de la acumulación de proveedores no consiste en añadir más includes. Cada uno de los pasos que se indican a continuación contribuye a lograr el mismo resultado: un SPF listo para producción que se mantenga válido aunque los proveedores modifiquen su infraestructura.

Revisa lo que realmente utilizas. Obtén tus informesDMARC e identifica todas las fuentes de envío que superan SPF; a continuación, comprueba cómo afecta cada una de ellas a tu recuento total de consultas. Elimina SPF obsoletas correspondientes a servicios que ya no utilizas. Los proveedores antiguos y las plataformas en desuso suelen permanecer en SPF mucho tiempo después de haber sido retirados del servicio.
Cambia tu include encadenar con rangos de IP directos siempre que sea posible. Si un proveedor realiza envíos desde un conjunto de direcciones IP estable y documentado, sustituye su includes con ip4 o ip6 mecanismos. Esto elimina costo de búsqueda costo ese remitente y reduce el número total de búsquedas.
Utiliza subdominios para servicios de envío específicos. Si el registro de tu dominio principal está a punto de alcanzar su capacidad máxima, delega los correos electrónicos transaccionales o de marketing a un subdominio. Cada subdominio puede tener su propio SPF con su propio límite de 10 consultas.
Valida después de cada cambio. Después de actualizar tu registro, realiza un recuento completo de búsquedas. No te fíes solo de la cifra que te dé solo validador. Abre cada include a mano, comprueba a qué apunta y cuenta cada referencia que añade, incluidas las anidadas include dentro de él.

Cómo ayuda Sendmarc

La gestión SPF gran escala, en múltiples dominios y con distintos proveedores de envío, requiere una visibilidad que la inspección del DNS por sí sola no proporciona. La función SPF de Sendmarc supervisa continuamente SPF de cada dominio y simplifica automáticamente los registros anidados includes en direcciones IP directas, lo que neutraliza la acumulación de proveedores y mantiene el registro dentro del límite de 10 consultas, incluso cuando los proveedores cambian su infraestructura.

Sendmarc realiza un seguimiento de cada elemento anidado include y cualquier cambio de proveedor que pueda afectar al número de consultas, para que tus dominios sigan estando protegidos a medida que evoluciona tu entorno de envío.

Descubre las funciones SPF de Sendmarc.