28 jul 20268 minutos leídos
Waseem OsmanDMARC EnthusiastCreación de registros SPF: una guía práctica para equipos empresariales
Descripción general de la creación de registros SPF:
- La creación de un registro SPF es una tarea puntual, pero mantener el registro preciso es una labor continua.
- El calificador
-alles el valor predeterminado correcto para los dominios de producción;~allcorresponde a las fases de prueba o de despliegue. - Los conjuntos de remitentes empresariales suelen alcanzar el límite de 10 consultas con menos remitentes de lo esperado.
- El aplanamiento de IP elimina la carga de consultas, pero requiere una supervisión automatizada para mantenerse preciso a medida que cambian las IP de los proveedores.
- Los subdominios no heredan el registro SPF del dominio principal, por lo que cada uno necesita una política explícita.
Un registro SPF mal implementado puede bloquear correos legítimos o dejarlo expuesto a la suplantación de identidad. Detectar la diferencia antes de que le afecte requiere algo más que una comprobación de sintaxis.
En las grandes organizaciones, los fallos de SPF suelen surgir de forma silenciosa: los correos transaccionales de un proveedor empiezan a rebotar, o la campaña de una unidad de negocio regional acaba en Spam.
La configuración incorrecta ocurrió semanas antes, escondida en un cambio que en su momento parecía rutinario. Implementar un registro correctamente es solo el primer paso. Lo que viene después, mantenerlo preciso a medida que cambian los proveedores y la infraestructura, es el verdadero reto.
Esta entrada cubre la creación de registros SPF, las restricciones reales de DNS, la política de subdominios y la estructura de gobernanza necesaria para mantener el SPF funcional a lo largo del tiempo.
El DMARC Management de Sendmarc ofrece a los equipos distribuidos una única vista de cada registro SPF, subdominio y remitente de toda la empresa, de modo que las brechas no aparezcan solo después de que los mensajes no se entreguen.
Fundamentos de la creación de registros SPF: sintaxis y estructura
Un registro SPF es un registro TXT de DNS publicado en su dominio raíz (o subdominio). Indica a los servidores receptores qué direcciones IP y servicios de envío están autorizados a enviar en nombre de su 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 |
Desglosado:
v=spf1– Etiqueta de versión obligatoria, siempre la primeraip4:203.0.113.10– Autoriza explícitamente una única dirección IPv4include:spf.protection.outlook.com– Apunta al registro SPF de Microsoftinclude:sendgrid.net– Delega en un remitente de terceros-all– Hard fail: bloquea cualquier fuente no incluida
El calificador -all es el valor predeterminado adecuado para los dominios de producción. La alternativa, ~all (softfail), sigue permitiendo la entrega y solo es apropiada durante las fases iniciales de implementación o de prueba. Usar ?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 de registros SPF a escala: el límite de 10 consultas
El RFC 7208 impone un límite estricto de 10 consultas DNS por evaluación de SPF. Cada mecanismo include, a, mx y exists cuenta para ese límite, al igual que las consultas anidadas. Los mecanismos ip4 e ip6 no generan consultas, por lo que la autorización directa por IP es preferible.
En la práctica, los registros SPF empresariales superan el límite de 10 consultas con más frecuencia de la que la mayoría de los equipos cree. Un conjunto de remitentes empresarial típico podría incluir:
- Microsoft 365 o Google Workspace (1-2 consultas)
- Una plataforma de automatización de marketing (1 consulta)
- Un CRM (1 consulta)
- Un proveedor de correo transaccional (1 consulta)
- Una plataforma de RR. HH. (1 consulta)
- Un servidor local (1 consulta)
- Una plataforma de tickets o soporte (1 consulta)
- Un sistema financiero (1 consulta)
Eso ya son ocho consultas antes de tener en cuenta los includes anidados. En cuanto añade una nueva herramienta SaaS durante un ciclo de compras, es probable que supere el límite. Los servidores receptores devolverán un PermError, lo que normalmente hace que el mensaje sea rechazado de plano.
La mitigación más fiable es el aplanamiento de IP: resolver todas las cadenas de include hasta sus direcciones IP. Esto elimina la carga de consultas.
La contrapartida es una carga de mantenimiento. Cuando un proveedor cambia sus IP de envío, lo cual hacen, a menudo sin previo aviso, su registro queda desactualizado. Las herramientas automatizadas de gestión de SPF supervisan estos cambios y actualizan su registro en consecuencia, lo que elimina el costo operativo del aplanamiento manual.
Creación de registros SPF para subdominios
Los subdominios no heredan el registro SPF del dominio principal. Un registro en yourdomain.com no ofrece ninguna cobertura SPF para mail.yourdomain.com ni regional.yourdomain.com. Una creación de registros SPF eficaz trata cada subdominio como una decisión de política independiente.
Los entornos empresariales suelen tener:
- Subdominios regionales o de producto utilizados por sistemas de marketing o transaccionales
- Dominios adquiridos que operan bajo un subdominio de una filial
Los subdominios sin un propósito de envío legítimo deben publicar un registro de hard fail:
v=spf1 -all
Esta es una señal deliberada a los servidores receptores de que nada está autorizado a enviar desde ese subdominio. Cierra un vector de ataque común en el que los adversarios utilizan subdominios desprotegidos para la suplantación de identidad.
Para los subdominios que sí envían correo, publique registros explícitos que incluyan únicamente los sistemas que realmente los utilizan.
Lista de comprobación de gobernanza para la creación y el mantenimiento de registros SPF
La creación de un registro SPF es una tarea puntual, pero mantener ese registro preciso no lo es, y afecta a más que al equipo de DNS. Abarca las operaciones de TI, la seguridad y el cumplimiento. La lista de comprobación siguiente define quién es responsable de qué, cuándo escalar y qué registros mantener.
Responsabilidad
- El equipo de DNS es responsable de la publicación del registro y de la ejecución de los cambios
- Operaciones de TI es responsable del inventario de remitentes y coordina la incorporación de proveedores
- Seguridad o cumplimiento es responsable de la pista de auditoría y del ciclo de revisión periódico
- Los responsables de departamento aprueban los remitentes de terceros de su equipo
Cadencia de revisión
- Trimestral: revisión completa del inventario de remitentes frente al registro SPF publicado
- Bajo demanda: cualquier nuevo proveedor, herramienta SaaS o cambio de infraestructura que afecte al correo saliente
- Posincidente: cualquier fallo de SPF que haya causado una interrupción del correo de producción
Escale a un CISO cuando:
- Un remitente que no está en el inventario está enviando correos activamente desde su dominio
- La aplicación de SPF está en
~allo más débil en un dominio que gestiona comunicaciones de finanzas o de RR. HH. - Un departamento está incorporando un remitente de terceros que no puede proporcionar los detalles del
includede SPF ni un rango de IP fijo - El dominio de una filial adquirida está enviando mensajes sin ningún registro SPF
- El límite de 10 consultas se supera de forma constante y no hay ninguna solución de aplanamiento implementada
Registros de cumplimiento que mantener:
- Registro de cambios de DNS con marcas de tiempo, aprobador y estado del registro antes y después
- Inventario de remitentes con responsable y fecha de la última revisión
- Registro de incidentes de fallos de SPF, incluida la causa raíz y la resolución
Cómo ayuda Sendmarc
Mantener los registros SPF manualmente en varios dominios y decenas de remitentes es costoso desde el punto de vista operativo. La mayoría de los equipos de TI y seguridad, ya sobrecargados, no pueden sostenerlo sin personal adicional.
Sendmarc automatiza las partes de la creación y el mantenimiento de registros SPF que generan mayor riesgo. La plataforma revela las fuentes autorizadas y no autorizadas que envían desde su dominio, mantiene los recuentos de consultas dentro de los límites del RFC a medida que cambia la infraestructura de los proveedores y produce la pista de auditoría que exigen los equipos de cumplimiento, los comités de auditoría y los consejos de administración.
Para las organizaciones que gestionan SPF en filiales, dominios adquiridos o entornos complejos, Sendmarc proporciona visibilidad y gobernanza centralizadas sin requerir que cada unidad de negocio se coordine a través de un único equipo de DNS.
