SPF Record Optimization Tips: Fix Failures, Stay Under the 10-Lookup Limit

Un registro SPF publicado no es lo mismo que un registro SPF que funciona correctamente. Muchas organizaciones configuran SPF una sola vez, añaden algunos proveedores de servicios de correo electrónico y nunca vuelven a revisarlo. Con el tiempo, el registro acumula entradas obsoletas, se acerca al límite de consultas DNS o desarrolla desajustes de alineación que provocan fallos silenciosos en DMARC. Optimizar su registro SPF no es una tarea puntual; es un mantenimiento continuo que afecta directamente a la entregabilidad de su correo electrónico y a su capacidad para aplicar DMARC.

Por qué es importante la optimización del SPF

Cada vez que su dominio envía un correo electrónico, el servidor de correo receptor consulta su registro SPF y evalúa si la IP de envío está autorizada. Si esa evaluación devuelve algo distinto de pass con un dominio correctamente alineado, el SPF de DMARC falla. Un registro SPF defectuoso se traduce inmediatamente en tasas de aprobación DMARC más bajas, lo que a su vez afecta a su capacidad de pasar su política DMARC de none a quarantine o reject.

Las causas más comunes de fallos DMARC debidos a SPF incluyen superar el límite de consultas DNS (permerror), enviar desde una IP que no está incluida en su registro, o usar un proveedor de servicios de correo electrónico que establece su propio dominio en el campo MAIL FROM en lugar del suyo. Cada uno de estos problemas tiene una solución específica, pero primero necesita visibilidad para encontrarlos.

Manténgase por debajo del límite de 10 consultas DNS

RFC 7208 define un límite estricto: evaluar un único registro SPF no debe desencadenar más de 10 consultas DNS. Los mecanismos que consumen consultas son include, a, mx, ptr y exists. Los mecanismos ip4 e ip6 no requieren resolución DNS y, por lo tanto, no cuentan para el límite.

La parte complicada es que el límite es recursivo. Cada include cuenta como una consulta, pero cualquier mecanismo include dentro del dominio referenciado también cuenta. Un simple include:_spf.google.com puede resolverse en dos o tres consultas adicionales internas. Añada Mailchimp, HubSpot, Salesforce y un proveedor de correo transaccional y puede superar las 10 consultas sin darse cuenta.

Cuando se supera el límite, el resultado es permerror: un error permanente que cuenta como un fallo SPF para DMARC. Para contar sus consultas actuales, audite cada mecanismo en su registro y cuente recursivamente las consultas que desencadena. A continuación se muestra un ejemplo de un registro que está cerca del límite:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com ~all

Este registro ya usa cinco mecanismos include en el nivel superior. Cada uno de ellos puede referenciar consultas anidadas adicionales, lo que hace muy probable que el total supere 10. Cualquier nuevo ESP que añada corre el riesgo de llevarlo al territorio de permerror.

Aplane su registro SPF

El aplanamiento de SPF reemplaza las referencias include con las direcciones IP reales o rangos CIDR a los que se resuelven. En lugar de include:_spf.google.com (que a su vez se resuelve en varios rangos de IP a través de consultas anidadas), se listan directamente los bloques de IP sin procesar:

v=spf1 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.233.160.0/19 ~all

Dado que los mecanismos ip4 e ip6 no requieren resolución DNS, un registro completamente aplanado puede listar docenas de IPs de envío consumiendo cero consultas. Esto elimina por completo el riesgo de alcanzar el límite de 10 consultas.

La contrapartida es el mantenimiento. Los proveedores de servicios de correo electrónico cambian periódicamente sus rangos de IP. Si tiene un registro aplanado estático y un ESP añade una nueva IP de envío, los correos electrónicos de esa IP fallarán en SPF hasta que actualice su registro. Necesita un proceso fiable para hacer seguimiento de los cambios en los rangos de IP de los ESP, o bien usar un servicio de SPF gestionado que mantenga automáticamente actualizado su registro aplanado. Los servicios de SPF gestionados suelen utilizar un único include que apunta a un subdominio administrado por el proveedor, que este actualiza en su nombre cada vez que cambian los rangos de IP originales.

Elimine los includes que no utiliza

Los registros SPF se acumulan con el tiempo. Cada nueva herramienta de correo electrónico, integración de CRM o plataforma de marketing se añade, pero los proveedores antiguos rara vez se eliminan. Un antiguo proveedor de correo transaccional que dejó de usar hace dos años puede seguir en su registro SPF, consumiendo una o más de sus preciadas 10 consultas y potencialmente autorizando un rango de IP que ya no controla.

Para auditar sus includes:

1. Liste cada include en su registro SPF actual.
2. Para cada include, identifique el servicio de correo electrónico al que corresponde.
3. Confirme si su organización envía activamente correo electrónico a través de ese servicio en la actualidad.
4. Si un servicio ya no está en uso, elimine su include de su registro.
5. Revise sus informes agregados DMARC para ver qué IPs de envío están apareciendo realmente; cualquier IP que no esté en su stack de herramientas actual es candidata a eliminación.

Las entradas obsoletas más comunes incluyen antiguas plataformas de automatización de marketing (Marketo, Pardot, versiones antiguas de Mailchimp), proveedores transaccionales que fueron reemplazados (SendGrid, Mandrill, SparkPost) y herramientas de CRM con capacidades de correo saliente que ya no están configuradas. Incluso un único include no utilizado que contenga dos o tres consultas anidadas puede liberar suficiente margen para añadir un nuevo remitente legítimo sin alcanzar permerror.

Corrija los problemas de alineación

Un SPF pass no significa automáticamente un DMARC pass. DMARC requiere que el dominio autenticado por SPF —el dominio MAIL FROM, también llamado remitente del sobre o return-path— se alinee con el dominio de la dirección Header-From visible. Si su ESP usa su propio dominio como MAIL FROM, SPF pasa para su dominio, no para el suyo, y la alineación SPF de DMARC falla.

Esta es una de las causas más comunes de fallos DMARC para las organizaciones que usan plataformas de correo electrónico de terceros. La solución es configurar un return-path personalizado en su ESP —un subdominio de su propio dominio que el ESP usa como dirección MAIL FROM. Por ejemplo, en lugar de bounce.sendgrid.net como MAIL FROM, configure em.yourdomain.com. Bajo la alineación relajada de DMARC (la predeterminada), em.yourdomain.com se alinea con yourdomain.com y la alineación SPF pasa.

La mayoría de los principales ESPs admiten dominios de return-path personalizados:

• Mailchimp — configure un dominio personalizado en la configuración de Audiencia; requiere un CNAME en su registrador.
• SendGrid — configure la autenticación de dominio con un return path personalizado en Configuración → Autenticación de remitente.
• HubSpot — configure un dominio de envío de correo electrónico conectado con un subdominio MAIL FROM personalizado.
• Amazon SES — use un dominio MAIL FROM personalizado en la configuración de su identidad verificada.
• Salesforce Marketing Cloud — configuración a través de un dominio privado y un dominio de rebote personalizado.

Después de configurar un return-path personalizado, también necesita añadir el registro SPF de ese subdominio (o incluirlo en el SPF de su dominio raíz) para que la verificación SPF del dominio MAIL FROM pase. Algunos ESPs gestionan esto automáticamente; otros requieren que añada un include específico para el subdominio.

Use -all en lugar de ~all

La mayoría de los registros SPF terminan con ~all (softfail), que significa: los correos electrónicos de IPs no listadas en el registro probablemente no están autorizados, pero los servidores receptores pueden seguir entregándolos. Esto es apropiado durante el despliegue inicial, cuando todavía está descubriendo toda su infraestructura de envío. Sin embargo, permanecer en ~all indefinidamente es una oportunidad perdida.

Cambiar a -all (fail) indica a los servidores de correo receptores que cualquier IP que no esté explícitamente listada en su registro SPF definitivamente no está autorizada para enviar correo de su dominio. Combinado con una política DMARC de reject, esto le proporciona la señal más sólida posible contra el correo electrónico suplantado.

¿Cuándo es seguro hacer el cambio? Una vez que esté seguro de que su registro SPF cubre todas las fuentes de envío legítimas: sus propios servidores de correo, todos los ESPs, proveedores transaccionales y cualquier sistema automatizado que envíe en su nombre. Si tiene monitorización DMARC en funcionamiento, compruebe que su tasa de aprobación SPF para fuentes legítimas sea consistentemente alta (idealmente por encima del 95 %) antes de hacer el cambio. Cualquier fallo restante debe diagnosticarse y resolverse primero.

Un matiz importante: -all frente a ~all no afecta directamente a la aplicación de DMARC. La política DMARC (p=none, p=quarantine, p=reject) es la que rige cómo los receptores gestionan los fallos de autenticación de su dominio. Pero usar -all elimina la ambigüedad y alinea su postura SPF con una posición de aplicación completa.

Cómo ayuda DMARCFlow

Optimizar un registro SPF de forma aislada es una cosa. Hacerlo correctamente en el contexto del tráfico de correo electrónico real a través de múltiples servicios de envío requiere visibilidad sobre lo que está ocurriendo realmente. DMARCFlow proporciona esa visibilidad directamente desde sus informes agregados DMARC.

• Detección de permerror. DMARCFlow señala cada resultado permerror en todos los registros de sus informes DMARC. Cuando el límite de 10 consultas es la causa raíz, se indica claramente para que sepa que debe aplanar su registro o eliminar includes no utilizados —no solo que SPF ha fallado.
• Información sobre la alineación SPF por registro. Cada registro de cada informe DMARC entrante se analiza individualmente según el modo de alineación de su política DMARC. DMARCFlow identifica no solo si SPF pasó o falló, sino si el dominio MAIL FROM autenticado se alinea con su Header-From. Puede ver de un vistazo qué remitentes están pasando con alineación, cuáles están pasando sin alineación (y por lo tanto fallando en DMARC) y cuáles están fallando directamente.
• Desglose de fuentes de envío. DMARCFlow agrupa los resultados por fuente de envío —dirección IP y dominio de origen informado— para que pueda identificar exactamente qué ESP o servidor está causando fallos de alineación. Esto facilita saber qué configuración de return-path corregir primero.
• Motor de recomendaciones. Basándose en sus datos reales, DMARCFlow genera recomendaciones priorizadas y procesables. Si un MAIL FROM no alineado en un ESP específico está causando fallos DMARC, la recomendación le indica qué configurar y en qué proveedor. Si su recuento de consultas se acerca al límite, lo señala antes de que alcance permerror.
• Seguimiento de madurez. La alineación SPF es una contribución directa al nivel de madurez DMARC de su dominio. DMARCFlow le muestra exactamente qué optimizaciones son necesarias para alcanzar niveles de madurez más altos y pasar de forma segura de none hacia la aplicación completa de reject.

Use el verificador SPF de DMARCFlow para inspeccionar inmediatamente su registro SPF actual, contar sus consultas DNS e identificar configuraciones incorrectas antes de que afecten a la entregabilidad.