Email authentication is a vital component of a secure email infrastructure, and the Sender Policy Framework (SPF) is a key tool in achieving this. SPF records help prevent email spoofing by verifying that emails are sent from servers authorized by the domain's owner. In this article, we'll explore SPF record syntax, review examples, and discuss best practices for enhancing email protection. Find more information here.
An SPF record is a type of DNS entry that indicates which mail servers have permission to send emails for a particular domain. When an email is received, the server verifies the sender's SPF record to confirm that the email comes from an approved source. If this verification does not pass, the email could be marked as potentially harmful, denied, or directed to the spam folder.
SPF records are structured as a single text string that starts with a version identifier and includes mechanisms, qualifiers, and modifiers. Here’s a breakdown of these elements:
Each SPF record starts with a version identifier, usually noted as v=spf1. This indicates that the record adheres to the syntax of SPF version 1. Although there is an SPF version 2, it is infrequently utilized and pertains mainly to email protocols other than Simple Mail Transfer Protocol.
Mechanisms specify the IP addresses, domain names, or Classless Inter-Domain Routing ranges authorized to send emails on behalf of the domain. These include:
Qualifiers are optional parameters that follow each mechanism and indicate the action to be taken if the mechanism matches:
In an SPF record, modifiers like redirect and exp offer extra guidance. The redirect modifier directs the SPF lookup to a different domain if none of the specified mechanisms are applicable, whereas the exp modifier delivers a personalized error message when a match is not found.
Constructing SPF records requires precision, as an error in syntax can lead to unexpected results. Let’s review a few examples that demonstrate different configurations of SPF records.
A straightforward SPF record might authorize a single IP address to send emails on behalf of the domain. For example:
v=spf1 ip4:192.168.1.1 -all
This record specifies that only the IP address 192.168.1.1 is allowed to send email for the domain. Any email originating from a different IP address will fail the SPF check due to the -all mechanism.
A more complex SPF record might include multiple mechanisms. Here’s an example:
v=spf1 ip4:192.168.1.1 ip4:10.0.0.1 mx -all
This entry permits the sending of emails from the IP addresses 192.168.1.1 and 10.0.0.1, along with those linked to the domain's MX records. Emails originating from any other sources will not pass SPF validation.
In some cases, an organization might rely on a third-party email provider. The include mechanism can integrate the provider’s SPF records into your domain's SPF record:
v=spf1 include:_spf.provider.com -all
This setup permits any IP address listed in the SPF record of spf.provider.com to send emails for the domain. Such a configuration is frequently utilized with services such as Google Workspace or Microsoft 365.
Let’s consider a more advanced SPF record with both mechanisms and qualifiers:
v=spf1 ip4:192.168.1.1 a mx ~all
In this record, emails sent from 192.168.1.1, the domain’s A record IP, or any of its MX records are allowed, while emails from other IPs are subject to a “soft fail” due to the ~all qualifier.