Error de SPF: qué significa y cómo solucionarlo

Un fallo del SPF puede parecer un pequeño problema de enrutamiento del correo hasta que empieza a afectar a la entrega en la bandeja de entrada, a la confianza en el remitente y a la protección contra la suplantación de identidad. En esta guía se explica qué es el SPF, qué significan los distintos mensajes de error relacionados con el SPF, por qué se producen y cómo solucionarlos sin generar nuevos problemas de autenticación.

¿Qué es el SPF en la autenticación del correo electrónico?

El SPF (Sender Policy Framework) es un método de autenticación del correo electrónico que permite verificar si un servidor de correo está autorizado a enviar mensajes en nombre de un dominio. Funciona mediante la publicación de un registro DNS en el que se enumeran las fuentes de envío autorizadas, lo que proporciona a la parte receptora una política con la que contrastar la dirección IP del remitente.

Esto es importante para la seguridad del correo electrónico, ya que el SPF contribuye a reducir la suplantación de dominios. Cuando un dominio publica normas de autorización claras, resulta más difícil para los remitentes no autorizados suplantar la identidad de dicho dominio en mensajes de phishing, spam u otros mensajes fraudulentos.

¿En qué consiste el fallo del SPF?

Un error de SPF significa que el servidor receptor no ha podido confirmar que el remitente estuviera autorizado según la política SPF publicada del dominio. En la práctica, el SPF comprueba si el servidor remitente está autorizado a enviar correo en nombre del dominio «envelope-from». Se produce un error de SPF cuando dicha fuente no se ajusta a la política, mientras que pueden aparecer otros estados de error de SPF cuando la comprobación no puede evaluarse correctamente debido a problemas de sintaxis o de DNS.

Esto tiene importancia más allá de la mera autenticación. Los fallos en el SPF pueden reducir la entrega en la bandeja de entrada, activar los filtros o contribuir a un rechazo directo, en función de las políticas del destinatario y de cómo estén configurados DKIM y DMARC junto con el SPF. Los fallos repetidos en el SPF también pueden minar la confianza en el remitente y, con el tiempo, complicar las comunicaciones comerciales legítimas.

Tipos de fallos del SPF

Los distintos resultados del SPF indican distintos tipos de problemas. Algunos indican un fallo real en la autorización, mientras que otros apuntan a la ausencia de políticas, a políticas deficientes, a problemas temporales con el DNS o a problemas permanentes con los registros.

FPS: Ninguno

Un resultado «SPF none» significa que el servidor receptor no ha encontrado ninguna política de autorización publicada con la que realizar la comprobación. No existe ningún registro SPF para ese dominio o nombre de host, por lo que la autenticación SPF no puede evaluar de forma válida los remitentes autorizados.

SPF neutro

«SPF neutro» significa que el dominio cuenta con un registro SPF, pero que la política no especifica claramente si la fuente remitente debe ser aceptada o rechazada. Se trata más bien de una señal débil que de una decisión firme de autorización.

SPF Softfail

Un «softfail» de SPF significa que es probable que la fuente remitente no esté autorizada, pero que la política no es lo suficientemente estricta como para exigir un rechazo rotundo. En la práctica, esto suele ir acompañado de «~all», lo que indica a los destinatarios que consideren el mensaje como sospechoso, en lugar de definitivamente inválido.

SPF Hardfail

Un «hardfail» de SPF significa que la fuente remitente no está autorizada y que la política SPF indica explícitamente que el mensaje debe ser rechazado. Esto suele asociarse con la opción «-all», que expresa una política más estricta que el «soft fail».

SPF Temperror

El código de error «SPF temperror» indica un problema temporal durante la evaluación, como un tiempo de espera de DNS agotado o un error en la consulta. Es posible que la fuente de envío sea legítima, pero el destinatario no puede realizar la comprobación SPF de forma fiable en ese momento.

SPF Permerror

El error «SPF permerror» indica que existe un problema permanente con el registro SPF o con su ruta de evaluación. Entre las causas más habituales se encuentran una sintaxis incorrecta del SPF, la existencia de varios registros SPF para un mismo dominio o un número excesivo de consultas DNS.

Estos resultados resultan útiles porque permiten determinar si el problema radica en la autorización, en una política deficiente o en un problema relacionado con el DNS o la sintaxis. Esto facilita la resolución de problemas en la parte correcta de la configuración.

¿A qué se debe el fallo del SPF?

No todos los fallos del SPF se deben al mismo tipo de problema. Las causas más habituales que se indican a continuación muestran en qué casos suele fallar el SPF y por qué el resultado no siempre se debe simplemente a un problema de autorización del remitente.

Fuentes de envío no autorizadas

La causa más habitual es una discrepancia en la autorización. El mensaje procede de una dirección IP o de una plataforma de envío que no figura en el registro SPF del dominio. Esto suele ocurrir tras cambios en la infraestructura, migraciones a la nube o la incorporación de nuevas plataformas SaaS sin que se haya actualizado el registro.

Registros SPF defectuosos u obsoletos

La higiene de los registros es otro problema habitual. Una sintaxis SPF incorrecta, mecanismos obsoletos y la existencia de varios registros SPF pueden provocar problemas de evaluación. Dado que un dominio solo debe publicar un registro TXT de SPF por nombre de host, los registros duplicados pueden provocar que las comprobaciones de SPF fallen, incluso cuando haya remitentes legítimos.

Límites de consulta de DNS e inclusiones anidadas

Los entornos empresariales suelen enfrentarse a problemas de evaluación más complejos. Las cadenas de inclusiones anidadas, los remitentes SaaS de terceros y el exceso de datos heredados del DNS pueden hacer que el registro se acerque al límite de consultas del DNS. Cuando la evaluación del SPF supera las 10 consultas DNS, puede devolver un «permerror» en lugar de un resultado de autorización correcto.

Reenvío de correo electrónico

El reenvío de correos electrónicos es otra fuente habitual de confusión. Un mensaje reenviado puede seguir siendo legítimo, pero la verificación SPF puede fallar porque el servidor de reenvío no suele estar autorizado en el registro SPF del dominio original. Esto significa que el destinatario detecta una dirección IP de origen diferente a la prevista en la política SPF.

Estas causas son importantes porque influyen tanto en la rapidez de la resolución de problemas como en la calidad de la solución. Algunos apuntan a remitentes no autorizados, mientras que otros se refieren a la limpieza de los registros, a los límites del DNS o al comportamiento del flujo de correo, que requiere una respuesta diferente.

Cómo diagnosticar un fallo del SPF

Empiece por localizar la política SPF activa del dominio. En la mayoría de los casos, el registro comienza con «v=spf1», lo que lo identifica como la política SPF del dominio. Puede comprobarlo mediante herramientas de búsqueda de DNS, comprobaciones desde la línea de comandos o el portal de gestión de DNS antes de realizar cualquier cambio.

A continuación, pase al mensaje en sí. Compruebe los encabezados completos del correo electrónico y los resultados de la autenticación para confirmar el resultado exacto de la verificación SPF, en lugar de dar por sentado que cada problema supone un fallo grave. A continuación, compare el dominio del remitente del sobre, la dirección IP de envío y el registro TXT del DNS publicado.

Para la resolución de problemas, resulta útil responder a algunas preguntas concretas:

• ¿Publica el dominio un registro TXT SPF válido?
• ¿Incluye el registro el servicio concreto o la dirección IP desde la que se envió el mensaje?
• ¿Hay demasiadas llamadas a archivos anidadas o consultas de DNS?
• ¿Se debe el fallo del mensaje al reenvío y no a un problema real del remitente?

Un diagnóstico más preciso hace que la solución sea más fiable. Una vez que sepa si el problema se debe a la autorización del remitente, a la estructura del registro o al comportamiento del flujo de correo, resultará mucho más sencillo corregir el aspecto concreto de la configuración.

Cómo solucionar un error de SPF

Para solucionar un error de SPF, lo habitual es garantizar una autorización precisa del remitente y una gestión rigurosa de los registros. Los pasos que se indican a continuación se centran en los cambios que resuelven los problemas habituales relacionados con el SPF y reducen la probabilidad de que se produzcan fallos en el futuro.

Limpie el registro SPF

Comience por fusionar los distintos registros SPF en uno solo, en caso de que existan varios. A continuación, elimine los mecanismos obsoletos que ya no se correspondan con remitentes activos, ya que las entradas sobrantes o desactualizadas pueden generar problemas de evaluación innecesarios.

Autorice únicamente a los remitentes legítimos

Añada únicamente servicios de envío, direcciones IP y plataformas legítimas que envíen mensajes de forma activa en nombre del dominio. Esto incluye plataformas de correo electrónico en la nube, como Google Workspace, la infraestructura interna de correo electrónico y los proveedores de SaaS autorizados. Evite conceder autorizaciones excesivas a rangos amplios o servicios desconocidos con el único fin de evitar que se produzcan fallos.

Validar los cambios tras las actualizaciones

Tras cualquier modificación, compruebe minuciosamente el registro. Compruebe la sintaxis del SPF, compruebe el número de consultas y verifique los resultados tras la propagación del DNS. La herramienta de comprobación de registros SPF de Mimecast resulta muy útil en este caso para confirmar que el registro actualizado funciona según lo previsto.

Fuentes de envío de documentos entre equipos

Además, resulta útil documentar las fuentes de envío en todas las unidades de negocio. Esto cobra especial importancia durante la incorporación de proveedores, los cambios de plataforma o las actualizaciones de la infraestructura, ya que los fallos en el SPF suelen deberse a que un equipo añade un remitente que nunca llegó a incluirse en el registro SPF central.

Un historial SPF más limpio es solo una parte de la solución. La estabilidad a largo plazo se consigue manteniendo la autorización de los remitentes actualizada, validando los cambios con cuidado y asegurándose de que las actualizaciones realizadas por los distintos equipos no incumplan la política de forma inadvertida más adelante.

Buenas prácticas para prevenir y evitar futuros fallos del SPF

Es más fácil mantener un historial de SPF limpio que uno reactivo. Los mejores resultados a largo plazo se obtienen gracias a los mecanismos de control operativos que reducen la repetición de errores antes de que estos lleguen al flujo de correo de producción.

Algunas de las mejores prácticas más útiles son:

• Pruebe los cambios en las políticas antes de su implementación para evitar introducir errores de sintaxis, inclusiones defectuosas o fallos de autorización inesperados.
• Utilice DMARC y DKIM junto con SPF, de modo que una validación positiva de DKIM pueda contribuir a garantizar una autenticación coherente incluso cuando SPF falle en casos excepcionales, como el reenvío.
• Publique el SPF como un registro TXT, y no como el tipo de registro RR de SPF, que ya está en desuso, para evitar problemas de compatibilidad y confusiones con políticas paralelas.
• Compruebe la configuración del reenvío de correo, ya que el reenvío es una causa frecuente de fallos legítimos en el SPF.
• Active los informes DMARC para poder detectar antes a los remitentes no autorizados, los problemas de alineación y las desviaciones recurrentes en la autenticación.
• Realice auditorías y pruebas periódicas de los registros DNS para garantizar que el inventario de remitentes, el recuento de consultas y los mecanismos SPF se ajusten a la infraestructura actual.

Estas prácticas contribuyen a reducir los problemas recurrentes relacionados con el SPF antes de que afecten al flujo de correo en producción. Cuanto más sistemáticamente se apliquen, más fácil resultará mantener una política de SPF estable y detectar los problemas en una fase más temprana.

Elabore una política de SPF más clara antes de que los fallos se conviertan en un riesgo

El fallo del SPF no es solo un problema de entregabilidad. También se trata de una señal de seguridad que puede indicar una autorización deficiente del remitente, registros DNS obsoletos, efectos secundarios del reenvío o deficiencias más generales en la gestión de la autenticación.

La solución más eficaz suele consistir en un diagnóstico preciso, un historial de SPF impecable y el uso coordinado de SPF, DKIM y DMARC, en lugar de abordar cada medida de control de forma aislada. Para aquellas organizaciones que necesiten una estrategia de autenticación de correo electrónico y lucha contra la suplantación de identidad más resistente, Mimecast puede ayudar a mejorar la visibilidad de los problemas relacionados con el SPF y facilitar una gestión más rigurosa de las políticas a lo largo del tiempo.