Artículo de blog
- 8 minutos leídos
- Sendmarc
Creación SPF : una guía práctica para equipos empresariales
Resumen de la creación de SPF :
- La creación SPF es una tarea que solo hay que realizar una vez, pero mantener la exactitud del registro es una labor continua.
- En
-allEl calificador es el valor predeterminado correcto para los dominios de producción;~allpertenece a las fases de pruebas o de puesta en marcha. - Las pilas de remitentes de las empresas suelen alcanzar el límite de 10 consultas con un número de remitentes inferior al esperado.
- La simplificación de direcciones IP elimina la sobrecarga que supone la búsqueda, pero requiere una supervisión automatizada para mantener la precisión a medida que cambian las direcciones IP de los proveedores.
- Los subdominios no heredan el SPF del dominio principal, por lo que cada uno necesita una política explícita.
SPF configurado incorrectamente puede bloquear correos electrónicos legítimos o dejarte expuesto a la suplantación de identidad. Detectar la diferencia antes de que te afecte requiere algo más que una simple comprobación sintáctica.
En las grandes organizaciones, SPF suelen manifestarse de forma discreta: los correos electrónicos transaccionales de un proveedor empiezan a ser devueltos, o la campaña de una unidad de negocio regional acaba en la carpeta de spam.
El error de configuración se produjo semanas antes, oculto en un cambio que, en aquel momento, parecía rutinario. Implementar un registro correctamente es solo primer solo . Lo que viene después —mantener su exactitud a medida que cambian los proveedores y la infraestructura— es el verdadero reto.
En esta entrada se aborda la creación SPF , las restricciones reales del DNS, la política de subdominios y la estructura de gobernanza necesaria para mantener SPF a lo largo del tiempo.
DMARC de Sendmarc ofrece a los equipos distribuidos una visión global de todos SPF , subdominios y remitentes de la empresa, de modo que las deficiencias no salgan a la luz solo los mensajes no se entreguen.
Conceptos básicos sobre la creación SPF : sintaxis y estructura
Un SPF es un registro TXT de DNS publicado en tu dominio raíz (o subdominio). Indica a los servidores receptores qué direcciones IP y servicios de envío están autorizados a enviar mensajes en nombre de tu dominio.
La sintaxis básica:
| Host | Tipo | Valor |
|---|---|---|
| @ | TXT | v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net -all |
Analicémoslo:
v=spf1– Etiqueta de versión obligatoria, siempre en primer lugarip4:203.0.113.10– Autoriza explícitamente una única dirección IPv4include:spf.protection.outlook.com– Apunta al SPF de Microsoftinclude:sendgrid.net– Se delega a un remitente externo-all– Fallo grave: bloquea cualquier fuente que no figure en la lista
En -all El calificador es el valor predeterminado adecuado para los dominios de producción. La alternativa, ~all (softfail), sigue permitiendo la entrega y es solo durante las fases iniciales de implementación o de pruebas. El uso de ?all (neutral) o +all (pass) no ofrece ninguna protección y no debería aparecer en los registros de producción.
Dónde falla la creación SPF a gran escala: el límite de 10 consultas
La RFC 7208 establece un límite máximo de 10 consultas DNS por SPF . Cada include, a, mxy exists Este mecanismo cuenta para ese límite, al igual que las búsquedas anidadas. ip4 y ip6 Estos mecanismos no activan búsquedas, por lo que es preferible la autorización directa por IP.
En la práctica, SPF de las empresas superan el límite de 10 consultas con más frecuencia de lo que la mayoría de los equipos cree. Una pila de remitentes típica de una empresa podría incluir:
- Microsoft 365 o Google Workspace (1-2 búsquedas)
- Una plataforma de automatización de marketing (1 resultado)
- Un CRM (1 búsqueda)
- Un proveedor de correo electrónico transaccional (1 resultado)
- Una plataforma de recursos humanos (1 búsqueda)
- Un servidor local (1 búsqueda)
- Una plataforma de gestión de incidencias o de asistencia (1 búsqueda)
- Un sistema financiero (1 resultado)
Eso ya son ocho consultas, sin contar las anidadas includes. En cuanto añadas una nueva herramienta SaaS durante un ciclo de adquisición, es probable que superes el límite. Los servidores receptores devolverán un PermError, lo que suele provocar que el mensaje sea rechazado de inmediato.
La medida de mitigación más fiable es la simplificación de direcciones IP: resolver todas las include las vincula a sus direcciones IP. Esto elimina la sobrecarga que supone la búsqueda.
La contrapartida es la carga que supone el mantenimiento. Cuando un proveedor cambia sus direcciones IP de envío —algo que suele hacer sin previo aviso—, tu registro queda desactualizado. Las herramientas SPF automatizada SPF supervisan estos cambios y actualizan tu registro en consecuencia, lo que elimina el costo operativo costo la actualización manual.
Creación de SPF para subdominios
Los subdominios no heredan el SPF del dominio principal. Un registro en tudominio.com no proporciona SPF para correo.tudominio.com ni regional.tudominio.com. Para crear SPF eficaz, hay que tratar cada subdominio como una decisión de política independiente.
Los entornos empresariales suelen contar con:
- Subdominios regionales o de productos utilizados por los sistemas de marketing o transaccionales
- Dominios adquiridos que operan bajo un subdominio de una filial
Los subdominios que no tengan una finalidad legítima de envío deben publicar un registro de error grave:
v=spf1 -all
Se trata de una señal deliberada dirigida a los servidores receptores para indicar que no está autorizado el envío de nada desde ese subdominio. De este modo, se elimina un vector de ataque habitual en el que los atacantes utilizan subdominios desprotegidos para suplantar la identidad.
En el caso de los subdominios que sí envían correo electrónico, publica registros explícitos que incluyan solo sistemas que realmente los utilizan.
Lista de comprobación de gobernanza para la creación y el mantenimiento SPF
La creación SPF es una tarea que solo hay que realizar una vez, pero mantener la exactitud de dicho registro no es así, y afecta a más personas además del equipo de DNS. Abarca las operaciones de TI, la seguridad y el cumplimiento normativo. La lista de comprobación que figura a continuación define quién es responsable de qué, cuándo hay que escalar el problema y qué registros hay que mantener.
Titularidad
- El equipo de DNS se encarga de la publicación de registros y de la ejecución de los cambios.
- El departamento de operaciones de TI gestiona el inventario de remitentes y coordina la incorporación de proveedores.
- El departamento de seguridad o de cumplimiento normativo es el responsable del registro de auditoría y del ciclo de revisión periódica.
- El departamento se encarga de aprobar por su cuenta a los remitentes externos de su equipo
Frecuencia de revisión
- Trimestral: revisión completa del inventario de remitentes en comparación con el SPF publicado
- Bajo demanda: cualquier nuevo proveedor, herramienta SaaS o cambio en la infraestructura que afecte al correo electrónico saliente
- Tras el incidente: cualquier SPF que haya provocado una interrupción del servicio de correo electrónico de producción
Se debe informar al CISO cuando:
- Un remitente que no figura en el inventario está enviando correos electrónicos desde tu dominio de forma activa.
- SPF se encuentra en
~allo con menos experiencia en un ámbito dedicado a las comunicaciones financieras o de recursos humanos - Un departamento está incorporando un servicio de envío externo que no puede proporcionar SPF
includedetalles o un rango de direcciones IP fijas - El dominio de una filial adquirida está enviando mensajes sin SPF .
- Se supera constantemente el límite de 10 consultas y no se ha implantado ninguna solución de simplificación.
Documentación de cumplimiento que debe conservarse:
- Registro de cambios del DNS con marcas de tiempo, responsable de la aprobación y estado de los registros antes y después
- Inventario de remitentes con el propietario y la fecha de la última revisión
- Registro de incidencias relacionadas con SPF , incluyendo la causa principal y la resolución
Cómo ayuda Sendmarc
La gestión manual SPF en múltiples dominios y para decenas de remitentes supone un gran esfuerzo operativo. La mayoría de los equipos de TI y seguridad, que ya están al límite de su capacidad, no pueden hacer frente a esta tarea sin aumentar la plantilla.
Sendmarc automatiza los procesos de creación y mantenimiento SPF que entrañan mayor riesgo. La plataforma identifica las fuentes autorizadas y no autorizadas que envían mensajes desde tu dominio, mantiene el número de consultas dentro de los límites establecidos por el RFC a medida que cambia la infraestructura de los proveedores y genera el registro de auditoría que requieren los equipos de cumplimiento normativo, los comités de auditoría y los consejos de administración.
Para las organizaciones que gestionan SPF filiales, dominios adquiridos o entornos complejos, Sendmarc ofrece visibilidad y control centralizados sin que sea necesario que todas las unidades de negocio tengan que coordinarse a través de un único equipo de DNS.