How to Set Up SPF Records Correctly

Setting up SPF records correctly is a foundational task in securing your domain against email spoofing and improving deliverability. Sender Policy Framework, or SPF, is a DNS-based email authentication mechanism that allows domain owners to specify which mail servers are permitted to send email on behalf of their domain. When a receiving mail server gets an incoming message, it can query the domain’s DNS for the SPF record and validate whether the sending IP address is authorized. If the SPF check fails, the message may be rejected or marked as suspicious, depending on the recipient’s mail handling policies. A well-structured SPF record not only helps protect your domain’s reputation but also improves your chances of reaching recipients’ inboxes rather than being filtered into spam.

To begin the process of setting up SPF, it’s important to understand the role of DNS in this framework. The SPF record is published as a TXT record in your domain’s DNS zone. Unlike MX or A records, which direct traffic or resolve hostnames, the SPF TXT record contains a specific syntax that outlines which servers are allowed to send mail. The record must be placed at the root of your domain—e.g., for the domain example.com, the SPF record is associated with example.com, not a subdomain. A basic SPF record might look like this: v=spf1 ip4:192.0.2.0/24 include:_spf.examplemail.com -all. This string includes the SPF version (v=spf1), the allowed sending IP range (ip4:192.0.2.0/24), an external service authorization via the include mechanism, and a policy modifier (-all) that instructs how to handle unauthorized senders.

The correct formulation of an SPF record depends on an accurate inventory of all sources that send mail for your domain. This includes your primary mail server, any third-party providers such as marketing platforms, CRM tools, help desk services, or cloud-based email services like Google Workspace or Microsoft 365. Each service provider typically documents the SPF include values or IP ranges that should be added to your record. It’s crucial that all legitimate sending services are accounted for; if a service is omitted, its mail will fail SPF checks, leading to delivery issues. Conversely, care must be taken not to include overly broad or unnecessary IP ranges, as this can dilute the effectiveness of SPF and potentially authorize malicious senders.

When referencing third-party domains using the include: mechanism, ensure that those domains maintain valid SPF records of their own. The include: directive performs a recursive check into the referenced domain’s SPF policy. If that domain’s SPF record is missing, invalid, or exceeds lookup limits, it could cause your SPF evaluation to fail. This brings attention to one of the more subtle complexities in SPF: the ten-DNS-lookup limit. SPF processing must not require more than ten DNS queries to evaluate a policy fully. Each include, a, mx, or ptr mechanism that causes a DNS query counts toward this limit. If exceeded, the SPF check automatically fails. To prevent this, minimize unnecessary includes and avoid mechanisms that introduce excessive recursion.

The policy modifier at the end of the SPF record is another key consideration. The most common values are -all, ~all, and +all. The -all value is a hard fail, indicating that any server not explicitly listed in the record should be rejected. This is the most secure option and should be used when the sending infrastructure is well defined and tightly controlled. The ~all is a soft fail, meaning messages from unauthorized servers should be accepted but flagged, which is useful during initial deployment or troubleshooting. The +all value, which allows any server to send email, is almost never appropriate as it renders SPF protection ineffective and should be avoided entirely. During implementation, organizations often start with ~all while monitoring email flow and then switch to -all once confident in their configuration.

Testing and validation are essential before and after publishing your SPF record. Online tools such as MXToolbox, Kitterman, and Google Admin Toolbox allow you to input your domain and receive a parsed interpretation of your SPF record, along with warnings about syntax errors, lookup counts, or overlapping mechanisms. Additionally, review mail headers from sent messages to confirm that the Received-SPF header shows a pass result. Monitoring DMARC aggregate reports can also help validate that legitimate email sources are passing SPF checks and highlight sources that may be failing or attempting unauthorized use.

Maintenance of SPF records is an ongoing responsibility. Any time you add or remove a service that sends email on your behalf, your SPF record must be updated accordingly. Neglecting to remove deprecated services can lead to unnecessary exposure, while forgetting to add new services can impair deliverability. It’s advisable to maintain a configuration document or inventory list that outlines all current email-sending services, their SPF mechanisms, and their operational roles. Periodic audits of DNS records can catch outdated or unused configurations and reduce complexity in the SPF policy.

For domains that do not send email at all, it is considered best practice to publish an SPF record that explicitly disallows all email. This is done with the record v=spf1 -all, which indicates that no IP address is authorized to send mail from the domain. This helps prevent spammers from forging mail from unused domains and improves overall domain reputation. Paired with a strict DMARC policy, this configuration signals to the internet that the domain is locked down and not to be trusted for any email communication.

In summary, setting up SPF records correctly involves understanding the SPF syntax, identifying all legitimate email sources, maintaining efficient DNS usage, and enforcing a clear policy on how to treat unauthorized senders. By publishing accurate and concise SPF records in DNS, organizations can significantly reduce the risk of email spoofing, protect their brand identity, and enhance email deliverability. Careful planning, ongoing management, and periodic validation ensure that SPF continues to be a reliable component of a secure and trustworthy email infrastructure.

Setting up SPF records correctly is a foundational task in securing your domain against email spoofing and improving deliverability. Sender Policy Framework, or SPF, is a DNS-based email authentication mechanism that allows domain owners to specify which mail servers are permitted to send email on behalf of their domain. When a receiving mail server gets…