SPF listo para producción: de la sintaxis válida a la preparación para auditorías

Si tu configuración SPF supera un comprobador genérico en línea, pero tus correos de marketing siguen acabando en Spam, o tus reportes DMARC muestran fallos de autenticación, es probable que estés ante una brecha de configuración invisible.

La entrada SPF parece válida. La sintaxis está limpia. Y aun así, en algún punto entre tu zona DNS y el servidor receptor, la autenticación está fallando silenciosamente.

Esa brecha, entre una entrada SPF técnicamente correcta y un registro SPF listo para producción, es donde fallan la mayoría de las implementaciones empresariales. Esta entrada desglosa esa brecha, repasando los modos de fallo específicos que separan una entrada SPF que funciona de una lista para auditorías.

Por qué la precisión técnica no es suficiente

Una entrada SPF que supera una comprobación de sintaxis te dice una sola cosa: el registro se puede analizar. No te dice nada sobre si todos los remitentes autorizados están incluidos, si el registro se mantendrá dentro del límite de 10 consultas o si existe evidencia documentada de que una IP concreta o un mecanismo include se añadió de forma intencionada.

Responder a esas preguntas con evidencia documentada, no con suposiciones, es lo que constituye una configuración SPF lista para producción.

Para un CISO o un responsable de riesgos que presenta ante un consejo o un comité de auditoría, esa distinción importa. Los fallos de entregabilidad causados por una configuración incorrecta de SPF pueden manifestarse como quejas de clientes o pérdida de ingresos por correos transaccionales bloqueados. Un riesgo distinto proviene de una política demasiado permisiva: eventos de suplantación de dominio que pasan desapercibidos porque la política no es lo bastante estricta.

Ambos se remontan a la misma causa raíz: un registro creado para superar un comprobador, no una configuración SPF lista para producción.

Qué compone un SPF listo para producción

Un SPF listo para producción no es solo una cadena de include con un mecanismo -all al final. Refleja decisiones, deliberadas, documentadas y revisables, sobre cada fuente autorizada para enviar en nombre de un dominio.

Aquí tienes un ejemplo más cercano a lo que realmente parecen las configuraciones SPF listas para producción:

Cómo leer este registro:

• ip4:203.0.113.10: una única IP explícita para un relé local. Debería corresponder a un servidor conocido y con nombre.
• ip4:198.51.100.25/28: una notación CIDR para una infraestructura alojada en la nube. Documenta el rango, la fecha de aprovisionamiento y el ciclo de revisión.
• include:mail.crm.example.com: delegación de SPF a un proveedor de CRM. Se trata de un include de terceros; no lo controlas. Si ese proveedor añade o actualiza infraestructura sin avisar, tu configuración SPF cambia sin que lo sepas.
• include:send.marketingplatform.example.com: la delegación a terceros significa que tu cobertura SPF depende de un registro que no te pertenece.
• include:thirdparty-transactional.example.com: un proveedor de correo electrónico transaccional. Puede conllevar una profundidad de consultas significativa si el propio registro SPF del proveedor utiliza includes.
• ~all: softfail. Los mensajes no autenticados se marcan, pero no se rechazan. Es algo intencionado en algunas implementaciones por fases, pero si lleva ahí 18 meses sin un plan de avance, es una brecha de control.

El registro supera una comprobación de sintaxis. Pero sin documentación sobre cada mecanismo, sin un recuento de consultas y sin un ciclo de revisión definido, no es un SPF listo para producción.

Los fallos silenciosos que los validadores en línea no detectan

Los comprobadores de SPF en línea validan la sintaxis y realizan una consulta DNS básica. No replican el comportamiento del servidor receptor, no tienen en cuenta la profundidad de consultas y no pueden evaluar la gobernanza. Aquí tienes ocho problemas que separan un SPF listo para producción de un registro que simplemente supera la sintaxis:

1. Agotamiento del límite de consultas DNS

SPF permite un máximo de 10 consultas DNS por evaluación. include, a, mx y exists cuentan cada uno. Los includes anidados lo agravan. Una entrada SPF que se resuelve en 6 consultas en un entorno de pruebas puede superar las 10 en producción si el registro SPF de un proveedor ha cambiado desde la última vez que lo comprobaste.

Siguiente paso: Cuenta las consultas desde la perspectiva del servidor receptor. Utiliza una herramienta que siga la cadena completa de include, incluidos todos los registros de terceros en el momento de la comprobación. Mantenerse dentro del límite de consultas requiere una gestión activa, no solo un recuento único durante la configuración.

2. Desviación de los include de terceros

Los proveedores rotan su infraestructura de envío. Cuando un proveedor añade un nuevo rango de IP a su registro SPF, tu registro SPF efectivo se amplía sin tu conocimiento ni consentimiento. Una auditoría SPF podría detectarlo: has autorizado envíos desde IPs que nunca has revisado.

Siguiente paso: Comprueba periódicamente cada mecanismo include y compara las IPs resultantes con tu lista de proveedores aprobados. Documenta cualquier cambio y atribúyelo a un proveedor concreto.

3. Softfail sin un plan de aplicación

~all es una postura legítima durante una implementación por fases. No es una postura permanente. Un dominio que permanece en ~all durante un periodo prolongado sin un calendario documentado para pasar a -all es una brecha que saldrá a la luz en una revisión de riesgos.

Siguiente paso: Documenta por qué ~all está en vigor, quién lo aprobó y cuándo pasará a -all. Si esa decisión no está documentada, debe estarlo.

4. Direcciones IP autorizadas pero sin documentar

Una IP o notación CIDR en un registro SPF de producción sin su correspondiente registro de activos es un hallazgo de auditoría SPF. Si tu registro incluye ip4:203.0.113.10 y nadie puede identificar qué sistema posee esa dirección sin una investigación considerable, se trata de un activo sin documentar.

Siguiente paso: Asigna cada IP explícita y notación CIDR de tu entrada SPF a un sistema con nombre, un responsable y una fecha de configuración. Todo lo que no puedas asignar, trátalo como candidato a eliminación hasta que se demuestre lo contrario.

5. SPF superado sin alineación DKIM

DMARC requiere la alineación SPF o la alineación DKIM. La alineación SPF requiere que el dominio del Return-Path coincida con el dominio «De». En escenarios de reenvío, la alineación SPF se rompe. Si DKIM también falta o está mal configurado, DMARC falla.

Siguiente paso: Revisa los reportes agregados de DMARC en busca de cualquier fuente que muestre un SPF superado junto a un fallo de DMARC. Casi siempre se trata de un problema de alineación: alinea el dominio del Return-Path con el dominio «De».

6. Brechas de SPF en los subdominios

Un registro SPF en un dominio principal no se extiende a sus subdominios. Un registro SPF en example.com no ofrece ninguna cobertura para mail.example.com, hr.example.com ni notifications.example.com. Cada subdominio utilizado para enviar correo necesita su propia entrada SPF.

Siguiente paso: Enumera todos los subdominios y verifica si cada uno tiene una entrada SPF. Añádela donde falte.

7. Duplicación del registro SPF

Un dominio debe tener exactamente un registro TXT de SPF. Dos registros SPF en el mismo dominio provocan un PermError, que la mayoría de los servidores receptores interpretan como un fallo. Esto ocurre sobre todo tras migraciones en las que no se eliminó el registro antiguo.

Siguiente paso: Consulta los registros TXT de cada dominio de envío y confirma que solo existe un registro.

8. Falta de cobertura para los dominios que no envían correo

Los dominios y subdominios que no envían correo electrónico siguen siendo objetivo de suplantación. Un dominio sin registro SPF permite que cualquiera envíe mensajes en su nombre. El enfoque correcto es v=spf1 -all: un rechazo explícito de todos los remitentes.

Siguiente paso: Incluye los dominios que no envían correo en tu auditoría SPF. Esto es especialmente importante para dominios heredados, entidades adquiridas y marcas aparcadas.

Lista de comprobación para auditorías SPF en entornos empresariales

Aplica esta lista de comprobación en la implementación inicial y en cada revisión periódica para confirmar una configuración SPF lista para producción.

Integridad del registro

• Existe exactamente un registro TXT de SPF por dominio
• El registro comienza con v=spf1 y termina con un mecanismo all
• Sin errores de sintaxis
• El registro ocupa menos de 450 bytes

Límites de consultas DNS

• La cadena completa de include requiere 10 consultas DNS o menos
• El recuento de consultas se revalida tras cualquier incorporación de proveedor o cambio en el registro SPF de un proveedor
• Se considera el aplanamiento de SPF para los registros que se acercan al límite

Cobertura de remitentes

• Cada IP y notación CIDR está asignada a un sistema y un responsable con nombre
• Cada mecanismo include corresponde a un proveedor identificado con un contrato vigente
• Los subdominios utilizados para el envío tienen cada uno su propia entrada SPF
• Los dominios y subdominios que no envían correo tienen v=spf1 -all

Postura de aplicación

• ~all tiene un responsable documentado, una fecha de aprobación y un calendario para pasar a -all
• Los reportes agregados de DMARC se revisan en busca de patrones de SPF superado/DMARC fallido
• DKIM está configurado en todos los dominios de envío activos, de modo que DMARC pueda seguir superándose cuando la alineación SPF se rompa

Gobernanza y pista de auditoría

• El historial de cambios del registro SPF se registra en un sistema de gestión de cambios
• Cada incorporación de un mecanismo tiene su correspondiente registro de aprobación
• El ciclo de revisión está definido y programado en el calendario (una periodicidad trimestral es adecuada para la mayoría de los entornos empresariales)
• La configuración SPF está incluida en las listas de comprobación de incorporación y baja de proveedores

SPF listo para producción en entornos regulados y multidominio

Para los sectores regulados, banca, sanidad y seguros, en particular, los registros de autenticación de correo electrónico se tratan cada vez más como evidencia técnica de control. Un registro SPF que se configuró hace tres años y no se ha revisado desde entonces no aporta ninguna evidencia de que siga siendo correcto. Demostrar que un registro se gestiona activamente y se revisa periódicamente proporciona esa evidencia.

Para los entornos que gestionan múltiples dominios entre filiales, unidades de negocio o entidades adquiridas, centralizar la visibilidad de SPF es la única forma práctica de mantener esa evidencia. La complejidad operativa de verificar manualmente SPF en una cartera de 50 o 100 dominios, a intervalos trimestrales, es insostenible sin herramientas.

Cómo Sendmarc puede ayudarte a lograr un SPF listo para producción

Los entornos empresariales rara vez tienen un único equipo gestionando SPF. Marketing, RR. HH., finanzas y producto añaden cada uno herramientas de envío, y los cambios de DNS suelen pasar por distintas cadenas de aprobación, si es que pasan por alguna.

La plataforma de Sendmarc centraliza la visibilidad en todos los dominios, de modo que las brechas de autenticación y los remitentes sin documentar afloran antes de convertirse en hallazgos de auditoría SPF o fallos de entrega.

Para los equipos de cumplimiento y gobernanza, Sendmarc respalda la evidencia que los comités de auditoría y riesgos esperan: historial de cambios, estado documentado de la política y datos de los reportes agregados de DMARC que vinculan los resultados de SPF con fuentes de envío concretas. Esa pista de evidencia sustituye a las revisiones manuales y puntuales de las que la mayoría de los equipos dependen actualmente.

Para los equipos de TI y seguridad ya sobrecargados en un entorno distribuido, la plataforma detecta desviaciones en la configuración SPF, remitentes no reconocidos en los reportes DMARC y brechas de cobertura en los subdominios.

Descubre cómo Sendmarc te ayuda a lograr un SPF listo para producción.