Nunha infraestrutura corporativa, os correos electrónicos poden orixinarse en varios sistemas: servidores internos, plataformas na nube, aplicacións empresariais ou servizos de notificación externos. Manter o control sobre estas fontes de envío é esencial para evitar configuracións inconsistentes e reducir a posibilidade de suplantación de dominio.

O estándar Sender Policy Framework (SPF) permite definir, mediante rexistros DNS, que servidores están autorizados a enviar mensaxes mediante un dominio específico. O seu funcionamento baséase en comparar o enderezo IP do servidor emisor coa política publicada polo dominio utilizado na identidade SMTP correspondente.

Aínda que é un mecanismo amplamente coñecido, a súa eficacia depende dunha configuración precisa e da adaptación aos cambios na infraestrutura de correo electrónico.

Unha política SPF pode incorporar enderezos IP autorizados e mecanismos como include, ou mx, que permiten diferentes fontes de envío.

Exemplo dun rexistro SPF en DNS

Exemplo ilustrativo con enderezos e dominios reservados para documentación.

Neste exemplo, o rexistro autoriza o envío desde o enderezo IP 192.0.2.10 e desde os servidores incluídos na política SPF do provedor externo. O mecanismo -all indica que todas as demais fontes non están autorizadas.

Non obstante, a acumulación de servizos externos pode complicar o mantemento. Cada provedor engadido mediante include pode introducir consultas DNS adicionais, e SPF establece un límite de dez consultas para certos mecanismos e modificadores durante a avaliación.

Superar este límite resulta nun erro de validación permanente (permerror), que pode afectar ao manexo de mensaxes lexítimas.

Polo tanto, a configuración de SPF debe comezar cun inventario actualizado das fontes de envío, incluíndo aplicacións e provedores que usan dominios corporativos. Tamén é recomendable revisar as autorizacións existentes e eliminar as que xa non sexan necesarias.

Outro aspecto relevante é a política establecida para servidores non autorizados. Mentres que ~all xera un resultado softfail, -all indica un fail explícito. A elección debe basearse nun coñecemento real das fontes de envío e da estratexia de autenticación da organización.

Limitacións a ter en conta

SPF ten algunhas peculiaridades que afectan á súa eficacia en certos escenarios.

Unha destas xorde no reenvío de correo electrónico. Cando unha mensaxe pasa por un servidor intermediario, o enderezo IP desde o que se entrega finalmente pode non estar incluído no rexistro SPF do dominio orixinal. Isto pode provocar un fallo de autenticación, mesmo cando a mensaxe é lexítima.

Tamén é importante distinguir entre o dominio utilizado para a validación SPF e o que aparece no campo visible De. O protocolo verifica principalmente a autorización asociada ao dominio do remitente nas mensaxes SMTP (CORREO DE), que pode diferir do dominio mostrado ao destinatario.

Polo tanto, un resultado de aprobado non garante que a identidade visible do remitente estea autenticada nin que o contido da mensaxe sexa seguro.

Esta limitación require complementar SPF con outros estándares, como DKIM e DMARC, que incorporan mecanismos adicionais de autenticación e aliñamento de dominios.

Dos rexistros DNS ao control operativo

A xestión de SPF non debe limitarse á súa configuración inicial. A incorporación de novos provedores, a migración de servizos e o cambio de sistemas de mensaxería requiren revisións periódicas das políticas publicadas.

Para os equipos de seguridade do correo electrónico, isto significa manter as fontes de envío identificadas, verificar os resultados da autenticación e detectar configuracións que poidan xerar erros ou autorizacións innecesarias.

Un rexistro SPF actualizado non elimina, por si só, os riscos de suplantación de identidade, pero permite un control verificable sobre os servidores autorizados para usar os dominios da organización. O seu valor reside tanto na configuración técnica como na capacidade de mantelo aliñado coa infraestrutura real.