In a corporate infrastructure, emails can originate from multiple systems: in-house servers, cloud platforms, business applications, or external notification services. Maintaining control over these sending sources is essential to avoid inconsistent configurations and reduce the risk of domain spoofing.

The Sender Policy Framework (SPF) standard allows you to specify—via DNS records—which servers are authorized to send messages on behalf of a given domain. It works by comparing the IP address of the sending server against the policy published by the domain used in the corresponding SMTP identity.

Although this is a widely known mechanism, its effectiveness depends on precise configuration and its ability to adapt to changes in the email infrastructure.

An SPF policy can include authorized IP addresses as well as mechanisms such as include, a, or mx, which allow for the inclusion of various sending sources.

Example of an SPF record in DNS

An illustrative example using addresses and domains reserved for documentation purposes.

In this example, the record authorizes sending from the IP address 192.0.2.10, as well as from the servers specified in the external provider's SPF policy. The -all mechanism indicates that any other sources are not authorized.

However, the accumulation of external services can make maintenance more complex.

Exceeding this limit results in a permanent validation error (permerror), which can negatively impact the handling of legitimate messages.

Therefore, SPF configuration should be based on an up-to-date inventory of sending sources, including any applications or providers that utilize corporate domains. It is also advisable to review existing authorizations and remove any that are no longer necessary.

Another important consideration is the policy defined for unauthorized servers. While ~all results in a softfail, -all indicates an explicit fail. The choice should be guided by a thorough understanding of your organization's actual sending sources and its overall authentication strategy.

Limitations that must be taken into account

SPF has some particularities that determine its effectiveness in certain scenarios.

One of them appears in email forwardings. When a message traverses an intermediary server, the IP from which it is ultimately delivered may not be included in the SPF record of the original domain. This can cause an authentication failure, even when the message is legitimate.

It is also important to distinguish between the domain used for SPF validation and the one that appears in the visible From field. The protocol primarily checks the authorization associated with the SMTP envelope sender's domain (MAIL FROM), which may be different from the domain shown to the recipient.

Therefore, a pass result does not guarantee that the sender's visible identity is authenticated or that the content of the message is secure.

This limitation makes it necessary to complement SPF with other standards, such as DKIM and DMARC, which incorporate additional domain alignment and authentication mechanisms.

From DNS Record to Operational Control

Managing SPF should not be limited to its initial configuration. Onboarding new providers, migrating services, and making changes to messaging systems require periodic reviews of published policies.

For teams responsible for email security, this entails keeping track of sending sources, verifying authentication results, and identifying configurations that could lead to errors or unnecessary authorizations.

While an up-to-date SPF record does not, on its own, eliminate the risk of impersonation, it does provide verifiable control over the servers authorized to use an organization’s domains. Its value lies as much in the technical configuration itself as in the ability to keep that configuration aligned with the actual infrastructure.