No se ha encontrado ningún registro de « SPF »: qué significa y cómo solucionarlo de forma segura

Qué significa realmente que no se haya encontrado ningún registro « SPF »

Cuando no se encuentra ningún registro «no SPF », suele significar que un dominio no estaba incluido en el ámbito de aplicación cuando se implantó « SPF » en otros lugares. Nadie decidió no protegerlo; a nadie se le asignó esa tarea.

El patrón suele ser el siguiente: existe un dominio en el DNS, el correo electrónico pasa por él a través de uno o dos remitentes conocidos y, como nadie ha notificado ningún problema de entrega, nunca se ha añadido un registro « SPF ».

Esto es habitual en organizaciones con múltiples entidades, en las que los departamentos gestionan sus propias herramientas SaaS y sus sistemas heredados, a menudo sin coordinarse con un departamento central de TI o de seguridad. Los ataques están diseñados para aprovechar precisamente este tipo de brecha en la autenticación del correo electrónico.

Si un registro «no SPF » aparece en un dominio, suele indicar que existe el mismo problema en otros dominios de la cartera, ya que estos suelen compartir el mismo proceso de incorporación.

Tanto las directrices de la CISA como las del NCSC recomiendan SPF, DKIM y DMARC como conjunto de controles de referencia para el correo electrónico de infraestructuras críticas y de empresas. La ausencia de un registro «no SPF » en cualquier dominio activo supone un incumplimiento de esa referencia, y se trata de una deficiencia que los auditores y los comités de riesgos señalarán.

No se ha encontrado ningún registro « SPF » debido a una configuración incorrecta de « SPF »

El hecho de que no se encuentre ningún registro «no SPF » y una configuración incorrecta de «SPF » dan lugar a un resultado similar, pero no se trata del mismo problema y no requieren la misma solución.

La ausencia de un registro « SPF » significa que no hay nada publicado en absoluto. No existe ningún registro « SPF » con el que los servidores receptores puedan contrastar la IP del remitente, por lo que cualquier remitente que afirme pertenecer a ese dominio, esté autorizado o no, se salta por defecto la autenticación « SPF ».

Una configuración incorrecta de « SPF » significa que existe un registro, pero que no supera la evaluación. Entre las causas más comunes se encuentran los registros TXT duplicados o un número de consultas que supera el límite de 10 consultas.

La diferencia práctica radica en la solución. Cuando no se encuentra ningún registro en SPF , es necesario crear un registro desde cero, basándose en un inventario completo de remitentes. Una configuración incorrecta en SPF suele requerir una corrección más específica: fusionar registros duplicados o reducir las búsquedas.

Evalúa el riesgo real antes de actuar

No todos los dominios que carecen de un registro « SPF » o que presentan una configuración errónea sin resolver de « SPF » conllevan el mismo riesgo. Un dominio aparcado que no envía correo electrónico es un caso distinto al de un dominio transaccional destinado a los clientes. La evaluación de riesgos debe ser estructurada, no reactiva.

Indicadores de alto riesgo:

• El dominio se utiliza para las comunicaciones con los clientes, la facturación o las transacciones.
• El dominio aparece en las cadenas de comunicación de proveedores o socios, lo que aumenta el riesgo de BEC
• El dominio goza de reconocimiento público de marca y, por lo tanto, tiene valor para la suplantación de identidad
• DMARC se encuentra en p=none o no existe, lo que significa que no hay una red de seguridad que garantice su cumplimiento

Indicadores de riesgo moderado:

• El dominio es de uso interno o se utiliza para las comunicaciones con los empleados solo
• No se observa ningún historial de intentos de suplantación de identidad en los informes de DMARC

Indicadores de menor riesgo:

• El dominio es un subdominio que se utiliza para un único sistema
• El dominio no envía correos electrónicos externos

Corregir el problema sin afectar al correo electrónico legítimo

Publicar un registro « SPF » sin conocer todos los sistemas que envían mensajes en nombre de tu dominio es la causa más habitual de fallos en la entrega tras la corrección, y es así como una situación en la que se ha resuelto el problema de «no se ha encontrado el registro SPF » se convierte en una nueva configuración errónea de « SPF ».

Antes de crear un registro, consulta los informes agregados deDMARC para el dominio. Si ya tienes DMARC configurado, aunque sea en p=none, los informes de la RUA muestran todas las direcciones IP y fuentes de envío que han intentado enviar correo electrónico desde tu dominio.

La secuencia que figura a continuación se centra en la implementación de un registro de forma segura.

1. Publica primero con un calificador «softfail». Publica el registro inicialmente con ~all en lugar de -all. Esto indica a los servidores receptores que marquen como sospechosos los correos electrónicos procedentes de fuentes que no figuran en la lista, pero que, aun así, los entreguen, lo que te ofrece un margen de tiempo para supervisarlos antes de que la aplicación estricta de la norma provoque un fallo en la entrega.
2. Comprueba la publicación y la sintaxis. Comprueba que el registro se resuelva correctamente. Comprueba que contenga v=spf1, incluye los mecanismos que cabría esperar y no supera el límite de 10 consultas DNS.
3. Supervisa los informes de DMARC durante un periodo de entre dos y cuatro semanas. Revisa diariamente los informes agregados de DMARC durante este periodo. Busca direcciones IP que generen resultados de «softfail» en SPF y que correspondan a sistemas de envío legítimos que se hayan pasado por alto en la fase de inventario. Añade esas fuentes al registro antes de pasar a la aplicación completa de las medidas.
4. Ir a -all una vez que el registro esté completo. Una vez que los informes de DMARC no muestren patrones de «softfail» inesperados procedentes de fuentes legítimas, actualiza el calificador a -all. Ya está activa la aplicación íntegra de la política « SPF », y los remitentes que no figuren en la lista no superarán la autenticación.

Evita que vuelva a abrirse la brecha en la autenticación del correo electrónico

Un registro de « SPF » no es un control que se pueda configurar y olvidar. Los entornos empresariales cambian: se incorporan nuevas herramientas SaaS y los proveedores actualizan su infraestructura. Establecer una periodicidad definida para las revisiones evita que vuelva a producirse una brecha en la autenticación del correo electrónico.

• Semanalmente: Revisa los informes agregados de DMARC para detectar nuevas fuentes de envío que aparezcan con errores de SPF . Las nuevas direcciones IP sin explicación pueden indicar un remitente no autorizado o una herramienta implementada sin la coordinación del departamento de TI, y ambos casos requieren una investigación.
• Mensualmente: Comprueba que el recuento de consultas de «SPF » no se haya acercado al límite tras cambios de proveedor o actualizaciones de registros. Un cambio en la IP del proveedor que no se refleje en tu registro es una de las causas más habituales de una configuración incorrecta de « SPF ».
• Trimestralmente: Conciliar la lista de remitentes con los contratos de proveedores activos. Dar de baja las fuentes que ya no se utilicen y confirmar que los nuevos proveedores incorporados durante el trimestre se añaden al registro antes de que comiencen a enviar mensajes.
• En cada ciclo de auditoría: Elaborar un registro documentado de la configuración actual de « SPF », la lista de remitentes en la que se basa y cualquier cambio realizado desde la última revisión. Esto sirve como prueba de que el control se gestiona de forma activa, y no de que simplemente esté presente « solo ».

Cómo puede ayudarte Sendmarc

Resolver el problema de que no se encuentre el registro «no SPF » es sencillo cuando se trata de un único dominio. Sin embargo, la tarea se complica cuando se trata de una cartera de dominios, sobre todo en entornos con múltiples entidades o de fusiones y adquisiciones, donde las comprobaciones manuales del DNS no ofrecen visibilidad a gran escala.

Sendmarc extrae los datos de los remitentes directamente de los informes agregados de DMARC , señala las fuentes de envío nuevas o no autorizadas a medida que aparecen y mantiene la precisión de los registros de SPF a medida que cambia la infraestructura de envío.

Esto aborda directamente los retos a los que se enfrentan a diario los equipos de seguridad y de TI de las empresas: reducir la investigación manual de los errores de configuración, proporcionar a los equipos, que ya están desbordados, una protección continua sin aumentar su carga de trabajo, y sustituir la visibilidad fragmentada por una única fuente de información fiable.

Para los equipos de riesgo y cumplimiento normativo que se enfrentan a un ciclo de auditoría, la solución « reporte » de Sendmarc proporciona pruebas documentadas del estado de autenticación en todos los dominios, sin necesidad de realizar comprobaciones cruzadas manuales entre los registros DNS y los datos de DMARC .

Descubre nuestra SPF solución de gestión para descubrir cómo Sendmarc resuelve los problemas de autenticación de correo electrónico en todos los dominios de tu cartera.