Límite de 10 consultas de SPF: qué cuenta y cómo no superarlo

Un servidor de correo receptor comprueba SPF evaluando tu registro, y evaluarlo cuesta consultas DNS. Para mantener acotado ese coste, la RFC 7208 limita cuántos términos que provocan consultas puede evaluar una sola comprobación. Si se supera el límite, el resultado es permerror, un error permanente que no es un pass. Los verificadores suelen informar de ello como «demasiadas consultas DNS», y normalmente aparece justo después de añadir otro servicio de envío al registro.

Qué cuenta la especificación

La sección 4.6.4 de la RFC 7208 enumera los términos que provocan consultas DNS: los mecanismos include, a, mx, ptr y exists y el modificador redirect. Las implementaciones deben limitar el total de esos términos a 10 durante una evaluación y deben devolver permerror si se supera el límite. Los mecanismos all, ip4 y ip6 no necesitan ninguna consulta y no se cuentan, y tampoco el modificador exp, que solo se obtiene más tarde, tras un fallo.

Importan dos detalles. Primero, include no copia otro registro dentro del tuyo: solo se usa su resultado, y la RFC admite que el nombre se eligió mal. Un -all dentro de un registro incluido no pone fin a la evaluación global. Segundo, los mecanismos se evalúan de izquierda a derecha y el procesamiento se detiene en el primero que coincide. El límite se aplica a los términos que realmente se evalúan durante una comprobación, no al tamaño del registro sobre el papel.

Contar un registro a mano

Considera un registro hipotético de una empresa que usa dos plataformas de correo, un CRM, un servicio de asistencia y su propio servidor de correo:

v=spf1 include:mailer-a.example include:mailer-b.example include:crm.example include:helpdesk.example mx a ~all

Supón que los registros incluidos contienen los términos siguientes. Están inventados a modo de ilustración, y los registros de los proveedores reales son distintos y cambian con el tiempo.

El correo enviado a través de la primera plataforma coincide pronto y pasa. El correo del servidor que solo autoriza la última a necesita una undécima consulta, así que la comprobación devuelve permerror en lugar de una coincidencia. Esa asimetría es la razón por la que este fallo parece intermitente: depende del remitente cuyo correo se esté comprobando.

Otros límites de la misma especificación

• Consultas vacías. Una consulta que no devuelve registros, o que devuelve un error de nombre, es una consulta vacía. La RFC 7208 recomienda limitarlas a dos, y superar el límite produce permerror. Aparte de eso, un include: cuyo destino no tiene registro SPF, incluido un nombre que ya no existe, devuelve none, y el mecanismo include lo convierte de inmediato en permerror, de modo que un include obsoleto puede romper un registro por sí solo.
• Ramificación. Un mecanismo mx no puede desencadenar más de 10 consultas de direcciones. En el caso de ptr, los nombres posteriores a los 10 primeros se ignoran.
• Un solo registro. Si un dominio publica más de un registro cuya versión es exactamente v=spf1, el resultado es permerror.
• Tamaño. La RFC aconseja mantener el registro publicado lo bastante pequeño para que la respuesta quepa en 512 octetos, de modo que viaje en un único paquete UDP sin EDNS(0).
• Tipo de registro. SPF debe publicarse como registro TXT. El tipo de registro SPF específico que se usó durante el periodo experimental se ha retirado.
• Tiempo. Los receptores deberían limitar el tiempo dedicado a una evaluación, pero permitir al menos 20 segundos. Si se supera ese límite de tiempo, el resultado debería ser temperror, un error temporal, y no permerror.

Cómo volver a quedar por debajo del límite

1. Elimina lo que ya no uses. Un servicio cancelado sigue costando una consulta siempre que la evaluación llega a su include. Quitar los include muertos es la solución más barata.
2. Traslada remitentes a subdominios. Cada nombre tiene su propio registro y su propio cupo de 10. El correo cuyo remitente del sobre está en news.example.com se comprueba con el registro de ese nombre, no con el del dominio raíz. Con la alineación relajada, DMARC sigue asociando el subdominio con el dominio organizativo.
3. Sustituye a y mx por direcciones literales cuando los servidores son tuyos y rara vez cambian. ip4 e ip6 no cuestan nada.
4. Aplana con cuidado. Aplanar sustituye un include por las direcciones a las que se resuelve actualmente. Hoy pasa y falla en silencio cuando el proveedor cambia sus rangos.
5. Elimina ptr. La RFC dice que no debería publicarse. Cambiar redirect por include no ahorra nada, ya que ambos cuentan una consulta.
6. Ordena por volumen, pero no cuentes con ello. Como la evaluación se detiene en la primera coincidencia, poner primero los literales y tus remitentes de mayor volumen gasta menos consultas en la mayor parte del correo. Eso reduce la frecuencia con la que el límite causa problemas; no hace válido un registro que supera el límite, y puede ocultar el fallo hasta que envía un remitente de uso poco frecuente.

Un permerror importa más allá del propio SPF. DMARC (RFC 7489) pasa cuando SPF o DKIM pasan con un dominio alineado, y permerror no es un pass, así que SPF ya no puede aportar. Si DKIM también falta o no está alineado, el mensaje no supera DMARC. Para ver tu propio recuento, el comprobador SPF sigue cada include y cada redirect y cuenta las consultas de todo el árbol frente al límite de 10. Es un recuento del peor caso de términos, no solo de los que desencadenaría un mensaje concreto. Cuando cambies el registro, baja antes su TTL para poder revertir rápido un error; consulta TTL de DNS explicado. Para ver el panorama general, lee SPF, DKIM y DMARC explicados.

Fuentes y lecturas complementarias

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Kitterman, 2014)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Kucherawy and Zwicky, 2015)