Un correo electrónico para restablecer la contraseña se envía. Nunca llega. No hay mensaje de error del lado del remitente, no hay bounce, no hay alerta en tu herramienta de envío. Solo silencio. En algunos casos, la causa es un registro SPF que ha superado su límite de 10 consultas DNS, sin que nadie en la organización se dé cuenta. Esto se llama un PermError. Ocurre mucho más de lo que se piensa en empresas que utilizan varios servicios SaaS para sus envíos.
Qué es el límite SPF y por qué existe
El SPF (Sender Policy Framework) es un protocolo de autenticación de correo electrónico que permite a un dominio declarar qué servidores están autorizados a enviar en su nombre. El límite de 10 consultas DNS por verificación SPF está inscrito en la RFC 7208 (IETF, 2014), la especificación oficial del protocolo. No es opcional: la RFC estipula que una implementación de SPF debe devolver un error permanente si se supera este umbral.
La razón técnica es concreta. Cada mecanismo SPF de tipo include:, a, mx, ptr o exists desencadena una consulta DNS adicional. Sin un límite, una regla SPF maliciosa o mal configurada podría forzar a los servidores receptores a encadenar docenas de consultas DNS, creando una carga excesiva en los resolutores recursivos y abriendo la puerta a ataques de denegación de servicio. Los mecanismos ip4:, ip6: y all no desencadenan ninguna consulta y no cuentan en el límite.
Este límite data de una época en que raramente una empresa tenía más de uno o dos proveedores de envío de correos electrónicos. En 2014, Microsoft 365 no existía bajo ese nombre, Salesforce Marketing Cloud todavía se llamaba Exact Target y HubSpot era solo una fracción de su uso actual. El límite fue pensado para un mundo que ya no es el nuestro.
Por qué las empresas SaaS de hoy alcanzan este límite sin darse cuenta
El problema radica en la forma en que los servicios de correo electrónico modernos publican sus propios registros SPF. Un include: hacia un proveedor no cuesta solo una consulta: cuesta tantas como el proveedor haya definido en su propio registro, incluidas las inclusiones anidadas. Google Workspace (_spf.google.com) consume entre 3 y 5 consultas por sí mismo. Microsoft 365 (spf.protection.outlook.com) consume de 3 a 5 según la configuración regional. Añade SendGrid (1 a 3), Salesforce (1 a 3) y HubSpot (1 a 2): el total supera 10 antes incluso de haber agregado el servicio de facturación, la plataforma de recursos humanos o la herramienta de soporte.
Lo que agrava la situación: los proveedores pueden modificar su infraestructura DNS sin previo aviso. El servicio al que delegaste un include: hace seis meses puede haber agregado nuevos servidores entre tanto, haciendo pasar tu conteo de 9 a 12 consultas sin ninguna acción de tu parte. Según los datos de dmarcchecker.app sobre el top 1 millón de dominios (2024), el 2% de los dominios con un registro SPF válido ya tienen una configuración no válida causando un PermError. Esta cifra parece baja pero representa miles de organizaciones cuyos correos legítimos se ven afectados permanentemente, a menudo sin que el equipo de TI sepa.
Lo que realmente sucede cuando se supera el límite
Cuando una verificación SPF alcanza 11 consultas DNS, el servidor de recepción devuelve un resultado permerror, un error permanente no recuperable. Lo que sucede con el correo electrónico depende de la política DMARC configurada en el dominio del remitente.
Con p=none, el correo generalmente se entrega a pesar del PermError. El dominio se trata como no autenticado. Es una falsa tranquilidad: los correos pasan. No hay protección contra la suplantación del dominio. Con p=quarantine, los correos van a spam, sin alerta del lado del remitente. Con p=reject, la política más estricta y la que Google y Yahoo exigen desde febrero de 2024 para remitentes de más de 5000 mensajes al día, los correos son rechazados. Confirmaciones de pedidos, restablecimientos de contraseñas, alertas de seguridad y comunicaciones internas desaparecen sin dejar rastro en las herramientas de envío.
Es el escenario más difícil de diagnosticar. El correo sale. No regresa. No llega.
El aplastamiento SPF: por qué la solución rápida empeora las cosas
La reacción más común ante este problema es el «aplastamiento» SPF: se reemplazan todos los mecanismos include: por las direcciones IP correspondientes, lo que reduce el número de consultas a cero o casi. El resultado inmediato es positivo. Los efectos a medio plazo son más problemáticos.
El CTO de dmarcian resume bien el problema de fondo: la mayoría de los registros aplastados terminan autorizando rangos de direcciones IP demasiado amplios, pertenecientes a los grandes proveedores de alojamiento en la nube, de los cuales una parte no corresponde a ningún servidor de envío real del proveedor. Actores maliciosos pueden explotar estos rangos autorizados para enviar desde tu dominio. Se resuelve un problema de deliverability creando un problema de seguridad.
La otra dificultad es el mantenimiento. Los proveedores de correo electrónico cambian sus pools de IP regularmente, sin aviso. Un registro aplastado debe actualizarse manualmente ante cada modificación, de lo contrario los nuevos servidores del proveedor quedan excluidos y los correos que gestionan fallan la autenticación SPF. El aplastamiento convierte un problema de configuración en una carga operativa permanente.
Enfoques que duran
El primer paso es una auditoría del recuento real. Herramientas como MXToolbox, el SPF Record Checker de dmarcian analizan tu registro SPF y cuentan las consultas en cascada, incluidas las inclusiones anidadas. Sin esta auditoría, es imposible saber dónde está realmente el contador.
La segmentación por subdominios es la solución arquitectónica más fiable. Mover los correos de marketing a marketing.tudominio.com y los correos transaccionales a notificaciones.tudominio.com da a cada subdominio su propio cupo de 10 consultas. Esta separación tiene una ventaja adicional: un problema de reputación en las campañas de marketing no afecta a los correos transaccionales críticos.
Para los dominios que no pueden segmentar fácilmente, las macros SPF son una alternativa seria. Mueven la evaluación fuera de la cadena de consultas estándar, pasando la verificación a un servicio externo a través de una única consulta DNS. Algunas soluciones funcionan con este principio. El inconveniente es real: si la infraestructura del proveedor falla, la autenticación SPF del dominio cae con ella.
La medida más frecuentemente olvidada sigue siendo la eliminación de las entradas que se han vuelto inútiles. Muchos registros SPF acumulan include: hacia proveedores que la empresa ya no utiliza desde hace meses o mecanismos a y mx heredados de una configuración antigua. Una auditoría anual recupera a menudo varias consultas sin tocar la arquitectura de envío.
Vigilar en el tiempo, no solo corregir una vez
Un registro SPF conforme hoy puede superar el umbral mañana si un proveedor modifica su infraestructura. Los informes DMARC agregados (formato RUA) son el indicador más accesible: muestran la proporción de correos que pasan o fallan la autenticación SPF para cada dominio emisario declarado. Cualquier pico repentino de fallos SPF merece una investigación inmediata sobre el recuento de consultas.
El límite de 10 consultas SPF es una restricción de 2014 que la RFC 7208 no ha revisado desde entonces. Las organizaciones que migran a DMARC en modo enforcement, como Google lo exige desde 2024 para remitentes de gran volumen, lo descubren a veces en el peor momento: cuando sus correos críticos dejan de llegar y nadie sabe por qué.
¿Qué es un PermError SPF?
Un PermError SPF es un error permanente devuelto por el servidor de recepción cuando la verificación SPF no puede completarse, especialmente porque el número de consultas DNS supera 10. A diferencia de un TempError (error temporal recuperable), un PermError persiste hasta que se corrija el registro SPF. DMARC trata un PermError como un fallo SPF completo.
¿Los mecanismos ip4 y ip6 cuentan en el límite de 10 consultas?
No. Los mecanismos ip4:, ip6: y all no desencadenan ninguna consulta DNS y no cuentan en el límite. Solo los mecanismos que requieren una resolución DNS se contabilizan: include:, a, mx, ptr, exists y el modificador redirect.
¿Cómo saber si mi registro SPF supera el límite?
Herramientas como MXToolbox SPF Checker, el verificador de dominio de dmarcian analizan el registro SPF y cuentan las consultas DNS en cascada, incluidas las inclusiones anidadas. Un resultado superior a 10 confirma que el registro devuelve un PermError en cada verificación, cualquiera que sea la política DMARC establecida.
