11 ago 20266 minutos leídos
Waseem OsmanDMARC PractitionerNo hay registro SPF: qué significa y cómo corregirlo con seguridad
Descripción general de la falta de registro SPF:
- La falta de SPF normalmente significa que nadie era responsable de ese dominio, no que alguien decidiera dejarlo sin protección.
- La falta de un registro SPF y una configuración incorrecta de SPF producen el mismo resultado, pero requieren soluciones distintas.
- El riesgo depende del dominio: priorice primero los dominios orientados al cliente, de alto valor o con p=none.
- Impléntelo con un calificador softfail, supervise durante dos a cuatro semanas y luego pase a la aplicación total.
- El SPF necesita una revisión continua con una periodicidad definida, no una corrección puntual.
Usted ya implementó DMARC y DKIM, pero su dominio no muestra ningún registro SPF, y sus administradores de correo asumen que no es urgente porque el correo sigue fluyendo. Ese supuesto es un problema.
La falta de un registro SPF no interrumpe la entrega de correo por sí sola. Elimina una capa de autorización de remitente que los servidores receptores usan para verificar la identidad de su dominio. Sin ella, cualquier servidor de internet puede enviar correo alegando ser de su dominio, y los servidores receptores no tienen forma de confirmar si ese servidor estaba autorizado para hacerlo.
Se trata de una brecha de autenticación de correo electrónico, y en una auditoría de cumplimiento o una revisión posterior a un incidente, esa distinción importa.
Esta guía explica qué significa realmente no tener un registro SPF, cómo evaluar el riesgo real y cómo corregirlo con seguridad sin interrumpir el flujo legítimo de correo.
Antes de evaluar el riesgo o planificar la corrección, confirme qué está publicado realmente hoy para su dominio. Suponer si existe un registro, o si uno antiguo está fallando silenciosamente, conduce a la solución equivocada.
Verifique su registro SPF para conocer el estado actual de su dominio e identificar remitentes autorizados, errores de sintaxis y el número de consultas antes de continuar.
Qué significa realmente no tener un registro SPF
Un resultado de falta de registro SPF normalmente significa que un dominio no estaba dentro del alcance cuando se implementó SPF en otros lugares. Nadie decidió no protegerlo; simplemente nadie fue asignado a hacerlo.
El patrón suele ser el siguiente: un dominio existe en el DNS, el correo fluye a través de él mediante uno o dos remitentes conocidos, y como nadie reportó un problema de entrega, nunca se agregó un registro SPF.
Esto es común en organizaciones multientidad donde los departamentos gestionan sus propias herramientas SaaS y sistemas heredados, a menudo sin coordinarse con una función central de TI o seguridad. Los ataques están diseñados para explotar exactamente este tipo de brecha de autenticación de correo.
Un resultado de falta de registro SPF en un dominio suele indicar el mismo problema en otros dominios de la cartera, ya que estos suelen compartir el mismo proceso de incorporación.
Tanto la guía de CISA como la de NCSC recomiendan SPF, DKIM y DMARC como un conjunto de controles básicos para la infraestructura crítica y el correo empresarial. Un resultado de falta de registro SPF en cualquier dominio activo no cumple con esa base, y es una carencia que los auditores y los comités de riesgo señalarán.
Falta de registro SPF frente a una configuración incorrecta de SPF
Un resultado de falta de registro SPF y una configuración incorrecta de SPF producen un resultado similar, pero no son el mismo problema y no requieren la misma solución.
La falta de registro SPF significa que no hay absolutamente nada publicado. No existe ningún registro SPF con el cual los servidores receptores puedan verificar la IP de envío, por lo que todo remitente que alegue ese dominio, autorizado o no, omite la autenticación SPF por defecto.
Una configuración incorrecta de SPF significa que existe un registro, pero no se sostiene ante la evaluación. Las causas comunes incluyen registros TXT duplicados o un número de consultas que supera el límite de 10.
La diferencia práctica está en la solución. La falta de registro SPF requiere construir un registro desde cero, basado en un inventario completo de remitentes. Una configuración incorrecta de SPF suele requerir una corrección más puntual: consolidar registros duplicados o reducir las consultas.
Evalúe el riesgo real antes de actuar
No todos los dominios sin registro SPF, o con una configuración incorrecta de SPF sin resolver, presentan el mismo riesgo. Un dominio inactivo que no envía correo es un escenario distinto al de un dominio transaccional orientado al cliente. La evaluación de riesgos debe ser estructurada, no reactiva.
Indicadores de alto riesgo:
- El dominio se usa para comunicaciones orientadas al cliente, facturación o transacciones
- El dominio aparece en cadenas de comunicación con proveedores o socios, lo que aumenta el riesgo de BEC
- El dominio tiene reconocimiento público de marca y, por lo tanto, valor para la suplantación de identidad
- DMARC está en p=none o ausente, lo que significa que no hay red de seguridad de aplicación
Indicadores de riesgo moderado:
- El dominio es de uso interno o se utiliza solo para comunicaciones con empleados
- No hay historial visible de intentos de suplantación en los reportes DMARC
Indicadores de menor riesgo:
- El dominio es un subdominio utilizado para un solo sistema
- El dominio no envía correo externo
Corrija sin interrumpir el correo legítimo
Publicar un registro SPF sin conocer todos los sistemas que envían correo en nombre de su dominio es la causa más común de interrupciones en la entrega tras la corrección, y así es como una falta de registro SPF resuelta se convierte en una nueva configuración incorrecta de SPF.
Antes de redactar un registro, obtenga los reportes agregados de DMARC del dominio. Si DMARC ya está implementado, incluso en p=none, los reportes RUA muestran cada dirección IP y fuente de envío que ha intentado enviar correo desde su dominio.
La siguiente secuencia se centra en implementar un registro con seguridad.
- Publique primero con un calificador softfail. Publique el registro inicialmente con
~allen lugar de-all. Esto indica a los servidores receptores que marquen como sospechoso el correo de fuentes no incluidas, pero que lo entreguen igualmente, dándole una ventana de supervisión antes de que la aplicación total provoque fallos de entrega. - Valide la publicación y la sintaxis. Confirme que el registro se resuelve correctamente. Confirme que contiene
v=spf1, incluye los mecanismos esperados y se mantiene dentro del límite de 10 consultas DNS. - Supervise los reportes DMARC durante dos a cuatro semanas. Revise los reportes agregados de DMARC diariamente durante este periodo. Busque direcciones IP que generen resultados de softfail SPF y que correspondan a sistemas de envío legítimos que se omitieron en la fase de inventario. Agregue esas fuentes al registro antes de pasar a la aplicación total.
- Pase a
-alluna vez que el registro esté completo. Cuando los reportes DMARC no muestren patrones inesperados de softfail de fuentes legítimas, actualice el calificador a-all. La aplicación total de SPF queda activa, y los remitentes no incluidos fallarán la autenticación.
Evite que la brecha de autenticación de correo se vuelva a abrir
Un registro SPF no es un control que se configura una sola vez. Los entornos empresariales cambian: se incorporan nuevas herramientas SaaS y los proveedores actualizan su infraestructura. Una periodicidad de revisión definida evita que la brecha de autenticación de correo se vuelva a abrir.
- Semanalmente: Revise los reportes agregados de DMARC en busca de nuevas fuentes de envío que aparezcan con fallos de SPF. Las IP nuevas sin explicación pueden indicar un remitente no autorizado o una herramienta implementada sin coordinación de TI, y ambos casos requieren investigación.
- Mensualmente: Verifique que el número de consultas SPF no se haya acercado al límite tras cambios de proveedor o actualizaciones del registro. Un cambio de IP del proveedor que no se refleje en su registro es una de las formas más comunes en que aparece una configuración incorrecta de SPF.
- Trimestralmente: Reconcilie la lista de remitentes con los contratos de proveedores activos. Retire las fuentes que ya no se usan y confirme que los nuevos proveedores incorporados durante el trimestre se agreguen al registro antes de comenzar a enviar correo.
- En cada ciclo de auditoría: Elabore un registro documentado de la configuración SPF actual, la lista de remitentes en la que se basa y los cambios realizados desde la última revisión. Esto demuestra que el control se gestiona activamente y no que simplemente existe.
Cómo Sendmarc puede ayudarle
Resolver la falta de un registro SPF es sencillo en un solo dominio. Se vuelve más difícil en una cartera completa, especialmente en entornos multientidad o de fusiones y adquisiciones, donde las verificaciones manuales de DNS no ofrecen visibilidad a gran escala.
Sendmarc extrae datos de remitentes directamente de los reportes agregados de DMARC, marca las nuevas fuentes de envío no autorizadas en cuanto aparecen y mantiene los registros SPF precisos a medida que cambia la infraestructura de envío.
Esto aborda directamente los problemas que los equipos empresariales de seguridad y TI enfrentan a diario: reduce la investigación manual de configuraciones incorrectas, ofrece a los equipos con recursos limitados protección continua sin aumentar su carga de trabajo, y sustituye la visibilidad fragmentada por una única fuente de verdad.
Para los equipos de riesgo y cumplimiento que se acercan a un ciclo de auditoría, los reportes de Sendmarc ofrecen evidencia documentada del estado de autenticación en cada dominio, sin necesidad de cruzar manualmente registros DNS y datos DMARC.
Explore nuestra solución de gestión de SPF para ver cómo Sendmarc cierra la brecha de autenticación de correo en cada dominio de su cartera.
