Hay un fallo de correo que no da la cara. No genera un error visible, no salta ninguna alarma, y tu SPF puede estar completamente roto mientras tú crees que todo va bien. La causa es un límite técnico poco conocido: SPF solo admite 10 consultas DNS. Si te pasas, deja de funcionar del todo. Y superarlo es más fácil de lo que parece.
Qué es el límite de 10 lookups
Cuando un servidor recibe un correo tuyo, consulta tu registro SPF para comprobar si el servidor que lo envió tiene permiso. El problema es que muchos registros SPF no listan IPs directamente, sino que «incluyen» los registros de otros servicios (`include:`). Cada uno de esos includes obliga a hacer una consulta DNS adicional, y algunos, a su vez, incluyen más.
La especificación de SPF pone un tope: no se pueden hacer más de 10 consultas DNS para evaluar un registro. Es un límite pensado para evitar abusos, pero tiene un efecto secundario: si tu registro requiere más de 10, SPF no devuelve «fallo parcial». Devuelve un error permanente ( PermError ), y a efectos prácticos es como si no tuvieras SPF.
Por qué es tan fácil pasarse
Aquí está la trampa. Cada herramienta que envía correo en tu nombre suele pedirte que añadas su `include:` a tu SPF. Y una empresa normal usa más de las que cree:
– El correo corporativo (Google Workspace, Microsoft 365): 1 include, a veces con varias consultas por dentro.
– La herramienta de facturación o ERP.
– La plataforma de newsletters o marketing.
– El CRM.
– El sistema de tickets o soporte.
– La herramienta de firma electrónica.
Suma includes y, sin darte cuenta, superas el tope. Lo peor es que puede funcionar durante meses y romperse el día que añades una herramienta más, o el día que uno de tus proveedores amplía su propio registro. Un cambio que tú no hiciste puede tumbar tu SPF.
El síntoma: no hay síntoma
Esto es lo que hace el fallo tan traicionero. Cuando el SPF entra en PermError, tus correos no dejan de enviarse de golpe. Simplemente empiezan a autenticar peor, a caer más en spam, a rebotar en algunos proveedores. Como el deterioro es gradual y silencioso, casi nadie lo relaciona con el SPF. Se echa la culpa al contenido, al proveedor, a la mala suerte.
Cómo se arregla
La solución no es «quitar herramientas», sino optimizar el registro para que quepa dentro del límite. Las técnicas habituales:
– Limpiar includes obsoletos: herramientas que ya no usas pero cuyo `include:` sigue ahí, consumiendo consultas.
– Aplanar el registro (SPF flattening): sustituir los includes por las IPs que resuelven, reduciendo consultas. Tiene contrapartidas —si el proveedor cambia sus IPs, hay que actualizar— así que se hace con criterio.
– Reorganizar el envío: en algunos casos, mover ciertos servicios a subdominios propios para repartir la carga.
Ninguna de estas es complicada por separado, pero requieren saber qué se puede tocar sin romper otra cosa. Un aplanamiento mal hecho puede dejar fuera una IP legítima y bloquear una herramienta que sí usas.
Comprueba tu SPF antes de que rompa
Si usas varias herramientas de envío, hay una probabilidad real de que tu SPF esté cerca del límite o ya lo haya superado sin que lo sepas. La única forma de saberlo con certeza es analizarlo: contar las consultas reales que genera y ver si alguna fuente está fallando.
En Reliant revisamos tu SPF como parte del diagnóstico y te decimos si está dentro del límite, cuántas consultas te quedan de margen y qué fuentes conviene optimizar.
Pide tu diagnóstico gratuito y sal de dudas sobre uno de los fallos de correo más silenciosos que existen.