SPF listo para producción: de la validez sintáctica a la preparación para la auditoría

Si tu SPF supera una comprobación genérica en línea, pero tus correos electrónicos de marketing siguen acabando en la carpeta de spam, o si tus DMARC muestran errores de autenticación, es probable que haya una deficiencia de configuración que pasa desapercibida.

SPF parece válida. La sintaxis es correcta. Y, sin embargo, en algún punto entre tu zona DNS y el servidor receptor, la autenticación está fallando de forma silenciosa.

Esa brecha, entre una SPF técnicamente correcta y un SPF listo para su uso en producción, es donde fallan la mayoría de las implementaciones empresariales. En esta entrada se analiza esa brecha, repasando los modos de fallo específicos que separan una SPF funcional de una lista para ser auditada.

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

Un SPF El hecho de que supere una comprobación sintáctica solo te indica una cosa: el registro se puede analizar. No te dice nada sobre si se incluyen todos los remitentes autorizados, si el registro se mantendrá dentro del límite de 10 consultas o si hay pruebas documentadas de que alguna IP específica o include ese mecanismo se añadió de forma intencionada.

Responder a esas preguntas con pruebas documentadas, y no con suposiciones, es lo que caracteriza a una SPF lista para producción.

Para un CISO o un responsable de riesgos que deba presentar un informe ante el consejo de administración o el comité de auditoría, esa distinción es importante. Los fallos en la entrega provocados por una SPF pueden traducirse en quejas de los clientes o en la pérdida de ingresos debido al bloqueo de correos electrónicos transaccionales. Existe otro riesgo derivado de una política excesivamente permisiva: los casos de suplantación de dominio que pasan desapercibidos porque la política no es lo suficientemente estricta.

Ambos se remontan a la misma causa principal: un registro creado para superar un verificador, no una SPF lista para producción.

Qué se necesita para crear SPF listo para su comercialización

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

He aquí un ejemplo que se acerca más al aspecto real de SPF listas para producción:

Cómo interpretar este registro:

• ip4:203.0.113.10: Una única dirección IP explícita para un relé local. Debe 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. Indica el rango, la fecha de aprovisionamiento y el ciclo de revisión.
• include:mail.crm.example.com: SPF a un proveedor de CRM. Se trata de un servicio de terceros include; tú no tienes control sobre ello. Si ese proveedor añade o actualiza la infraestructura sin previo aviso, tu SPF cambia sin que te des cuenta.
• include:send.marketingplatform.example.com: La delegación a terceros significa que tu SPF depende de un registro que no te pertenece.
• include:thirdparty-transactional.example.com: Un proveedor de correo electrónico transaccional. Esto puede implicar una profundidad de consulta considerable si el propio SPF del proveedor utiliza includes.
• ~all: Fallo leve. Los mensajes no autenticados se marcan, pero no se rechazan. Esto es intencionado en algunas implementaciones por fases, pero si lleva 18 meses así sin un plan de mejora, se trata de una deficiencia en los controles.

El registro supera la comprobación sintáctica. Sin embargo, al carecer de documentación sobre cada mecanismo, de un recuento de consultas y de un ciclo de revisión definido, no es SPF apto para su uso en producción.

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

SPF en línea validan la sintaxis y realizan una consulta DNS básica. No reproducen el comportamiento del servidor receptor, no tienen en cuenta la profundidad de la consulta y no pueden evaluar la gobernanza. A continuación se enumeran ocho aspectos que distinguen un registro SPF listo para producción SPF uno que simplemente cumple con la sintaxis:

1. Agotamiento del límite de consultas DNS

SPF un máximo de 10 consultas DNS por evaluación. include, a, mxy exists cada recuento. Anidado includes A esto hay que añadir lo siguiente: una SPF que requiere 6 consultas en un entorno de prueba puede superar las 10 en el entorno de producción si 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 todo el include cadena, incluidos todos los registros de terceros en el momento de la comprobación. Para no superar el límite de consultas es necesario llevar a cabo una gestión activa, no solo recuento único durante la configuración.

2. Terceros include Derrape

Los proveedores se turnan para gestionar la infraestructura de envío. Cuando un proveedor añade un nuevo rango de direcciones IP a su SPF , tu SPF efectivo se amplía sin que tú lo sepas ni hayas dado tu consentimiento. Una SPF podría señalar esto: has autorizado el envío desde direcciones IP que nunca has revisado.

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

3. Fallo leve sin un plan de aplicación

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

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

4. Direcciones IP autorizadas pero sin documentar

La presencia de una dirección IP o una notación CIDR en un SPF de producción sin el correspondiente registro de activos constituye un fallo detectado SPF . Si tu registro incluye ip4:203.0.113.10 y nadie puede determinar a qué sistema pertenece esa dirección sin llevar a cabo una investigación exhaustiva; eso se considera un activo no documentado.

Siguiente paso: asigna cada dirección IP explícita y cada notación CIDR de tu SPF a un sistema concreto, un propietario y una fecha de configuración. Todo aquello que no puedas asignar, considéralo candidato a ser eliminado hasta que se demuestre lo contrario.

5. SPF sin DKIM

DMARC que DKIM SPF o DKIM SPF exige que el dominio de Return-Path coincida con el dominio «From». En los casos de reenvío, SPF deja de funcionar. Si además DKIM o DKIM mal configurado, DMARC .

Siguiente paso: revisa los informes DMARC para detectar cualquier origen que muestre una SPF junto con un DMARC . Casi siempre se trata de un problema de alineación: alinea el dominio de Return-Path con el dominio «From».

6. SPF de los subdominios

Un SPF en un dominio principal no se extiende a sus subdominios. Un SPF en example.com no cubre a mail.example.com, hr.example.com ni notifications.example.com. Cada subdominio que se utilice para enviar correo electrónico necesita su propia SPF .

Siguiente paso: Enumera todos los subdominios y, a continuación, comprueba si cada uno de ellos tiene una SPF . Añade una si falta.

7. Duplicación de SPF

Un dominio debe tener exactamente un registro SPF . La presencia de dos SPF en el mismo dominio provoca un «PermError», que la mayoría de los servidores receptores interpretan como un fallo. Esto suele ocurrir con mayor frecuencia tras las migraciones, cuando no se ha eliminado el registro antiguo.

Siguiente paso: consultar los registros TXT de cada dominio remitente y confirmar que solo haya solo registro.

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

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

Siguiente paso: incluye los dominios que no envían correos en tu SPF . Esto es especialmente importante en el caso de los dominios heredados, las entidades adquiridas y las marcas en suspenso.

Lista de comprobación para SPF en entornos empresariales

Utiliza esta lista de comprobación en la implementación inicial y en cada revisión periódica para confirmar que SPF está lista para producción.

Integridad de los registros

• Existe exactamente un registro SPF por dominio.
• El disco empieza con v=spf1 y termina con un all mecanismo
• No hay errores de sintaxis
• El registro tiene menos de 450 bytes.

Límites de consultas DNS

• El texto completo include La cadena requiere 10 consultas DNS o menos
• El recuento de consultas se vuelve a validar tras cada incorporación de un proveedor o cada modificación SPF de un proveedor.
• Se tiene en cuenta SPF para los registros que se acercan al límite

Cobertura del remitente

• Cada dirección IP y cada notación CIDR se asocia a un sistema con nombre y a un propietario
• Cada include El mecanismo se asigna a un proveedor concreto con un contrato vigente
• Cada uno de los subdominios utilizados para el envío cuenta con su propia SPF
• Los dominios y subdominios que no envían mensajes tienen v=spf1 -all

Postura en materia de aplicación de la ley

• ~all cuenta con un titular documentado, una fecha de aprobación y un calendario para la transición a -all
• Se están revisando los informes DMARC en busca de patrones deDMARC».
• DKIM configurado en todos los dominios de envío activos, por lo que DMARC aunque se produzca un fallo en SPF .

Gobernanza y registro de auditoría

• El historial de cambios SPF se registra en un sistema de gestión de cambios
• Cada incorporación de un mecanismo cuenta con un registro de aprobación correspondiente
• Se define y se programa el ciclo de revisión (trimestral es lo adecuado para la mayoría de los entornos empresariales)
• SPF se incluye en las listas de comprobación para la incorporación y la baja de proveedores.

SPF listo para producción SPF entornos regulados y con varios dominios

En los sectores regulados —en particular, la banca, la sanidad y los seguros—, los registros de autenticación del correo electrónico se consideran cada vez más como pruebas técnicas de control. Un SPF que se configuró hace tres años y no se ha revisado desde entonces no constituye prueba alguna de que siga siendo correcto. Demostrar que un registro se gestiona de forma activa y se revisa periódicamente sí aporta esa prueba.

En entornos en los que se gestionan múltiples dominios repartidos entre filiales, unidades de negocio o entidades adquiridas, centralizar SPF es la solo forma solo de mantener esa evidencia. La complejidad operativa que supone verificar manualmente SPF una cartera de 50 o 100 dominios, con periodicidad trimestral, resulta insostenible sin el uso de herramientas adecuadas.

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

En los entornos empresariales, es poco habitual que haya un único equipo encargado de gestionar SPF. Los departamentos de marketing, recursos humanos, finanzas y producto añaden cada uno sus propias herramientas de envío, y los cambios en el DNS suelen pasar por diferentes procesos de aprobación, si es que pasan por alguno.

La plataforma de Sendmarc centraliza la visibilidad en todos los dominios, de modo que las deficiencias en la autenticación y los remitentes no documentados salen a la luz antes de que se conviertan en incidencias detectadas en SPF o en fallos de entrega.

Para los equipos de cumplimiento normativo y gobernanza, Sendmarc proporciona las pruebas que esperan los comités de auditoría y de riesgos: historial de cambios, estado documentado de las políticas y reporte DMARC que vinculan SPF con fuentes de envío específicas. Este registro de pruebas sustituye a las revisiones manuales y puntuales en las que se basan actualmente la mayoría de los equipos.

Para los equipos de TI y seguridad que ya se enfrentan a un entorno distribuido, la plataforma detecta desviaciones SPF , remitentes no reconocidos en DMARC y lagunas en la cobertura de los subdominios.

Descubre cómo Sendmarc te ayuda a conseguir SPF listo para su implementación en producción.