What Is an SPF Record in DNS?
Spammers continue to find new ways to send harmful message to others via email. However, one way to avoid spammers is to set up an SPF record, which is a standard for defining whether a domain is authorized to send emails on your behalf. In this article, we’ll explain what DNS SPF records are and why you should implement these records for email security.
What is SPF?
SPF stands for Sender Policy Framework. It refers to an email authentication method used to detect email spoofing. SPF relies on domain name system (DNS) records. A domain owner can publish an SPF record specifying authorized mail servers permitted to send emails on their behalf.
When an email arrives, the receiving server checks the sender's domain for an SPF record. It then compares the IP address of the sending mail server with the authorized servers listed in the SPF record.
If the sending IP address doesn't match any authorized server in the SPF record, it raises a red flag. This could indicate a spoofed email attempting to impersonate a legitimate sender. SPF shields recipients from potential phishing attacks and protects the domain owner's reputation.
However, SPF alone doesn't guarantee legitimate emails. It only verifies the sending server's authorization, not the email content itself. Malicious content can still slip through.
What is an SPF record?
An SPF record is a type of DNS record that specifies a list of authorized mail servers permitted to send email on behalf of your domain. This record can include the domain owner's mail servers, IP addresses, and even subdomains for sending emails.
On its own, the standard protocol used for email - Simple Mail Transfer Protocol - doesn't inherently verify the "From" address in an email. Because of this, anyone can impersonate senders. SPF records, among other authentication protocols, were created specifically to address this security flaw in SMTP. Adding one of these records helps prevent email spoofing, a technique phishers use to send emails with forged “From” addresses on your domain.

Spammers spoof by creating malicious emails with falsified sender addresses since most email servers don’t perform authentication. They then edit the address in email headers to make it appear genuine and as if it originated from a legitimate source, like your domain.
The intention is to phish your private information or otherwise cause reputational damage. Therefore, the receiving mail server must check the domain name in the "From" address and query the DNS for the domain's SPF record to mitigate these spams.
If the email passes this check, it will more likely be delivered successfully. If not, other servers may flag it as spam before it reaches your target.
Why use SPF records?
Spoofed emails can lead to a higher volume of replies and bouncebacks directed to the spoofed address, often at your domain. This creates extra work for the legitimate account owner, who has to deal with messages they never sent.
Implementing DNS records is necessary to improve email deliverability. It ensures that only the right emails arrive in the recipient's inbox.
In as much as creating an SPF record decreases spoofing attacks on your domain, it’s not a foolproof guarantee against all spam. The DNS SPF records combine with other technologies like DKIM and DMARC to form a robust defense against email-based threats.
As defined in the IETF RFC-7208, an SPF record must be a single string of text in a single DNS TXT record. Multiple SPF records for the same domain name are not allowed. Having multiple SPF records for a single domain could lead to conflicting information, making it difficult for receiving mail servers to determine the authorized senders. You can also use an SPF record check to assess the records for a domain.
How a mail server checks an SPF record
SPF records allow outside email servers to check whether an email is from the listed sender. While the SPF record doesn't directly verify the sender's name you see in an email, it validates a hidden email header field called Return-Path.
SPF validates the domain address and originating server indicated in the Return-Path value. Receiving email servers use this information to check if the domain name in the return-path matches the list of approved hosts for the particular sender.
The return-path email domain specifies where bounce messages should be sent. You can configure a return-path address to manage these messages efficiently. Configuring a return-path address may not be necessary for small-scale email operations with only a few recipients.
However, it becomes pivotal when a sender submits bulk emails, such as in e-commerce or email marketing campaigns. Analyzing bounce messages helps organizations further sift and analyze.
Any organization sending email from its own domain can benefit from creating an SPF record. This record helps receiving servers verify the legitimacy of incoming emails.
The process for creating an SPF record depends on how you send emails. If you use a hosting company, for example, to handle your email, they might already have instructions to help you set up an SPF record within their platform.
Managing your own email servers requires you to access the DNS zone file and manually create the SPF record. The complexity of creating a record also varies depending on the domain owner’s email infrastructure.
SPF syntax components
An SPF record consists of several core components that define authorized senders for a domain. They include the version number, mechanisms, qualifiers, and modifiers.
Version
Every record starts with a version declaration specifying the SPF syntax version in use. The current standard version is "v=spf1". The version number is usually authorized by mechanisms defining valid senders and therefore should match all messages.
Mechanisms
Mechanisms are the core instructions for the rules for identifying authorized senders. These mechanisms specify how receiving mail servers should handle emails that claim to originate from the domain. Some of the mechanisms include:
- IP4/IP6: Specifies specific IPv4 or IPv6 addresses authorized to send emails for the domain.
- A or address: Allows the IP address of the domain's A record (main domain) to send emails.
- MX: Identifies the IP addresses of the domain's MX records (mail exchange servers) to send emails.
- INCLUDE: Includes the Sender Policy Framework records of another domain. This is useful for delegating email sending authorization to third-party services.
- ALL: This selects all inbound messages. It defines the default policy for email servers not explicitly covered by the preceding mechanisms. It can be set to "allow" or "deny."
- PTR: This verifies if the reverse DNS record of the sending server matches the authorized domain name.
- EXISTS: This is the mechanism for specifying a domain, and the receiving mail server queries DNS for address records for that domain. With any result - if one or more address records are found - this mechanism matches, no matter the address.
Qualifiers
Qualifiers are prefixes that are optionally added to mechanisms to instruct the interpreting server on how to read and interpret the SPF check results. Some common qualifiers include:
- +, or Pass. This indicates a successful match with an authorized sender, meaning the email came from an authorized server.
- -, or Hard fail. This indicates a failed match, potentially marking the email as spam. The email is, therefore, rejected.
- ~, or Soft fail. This indicates a neutral outcome, often resulting in additional checks by the receiving server. The email may be subjected to further scrutiny.
- Neutral. The email server could not determine the legitimacy of the sending server.
For example, the mechanism -ALL in an SPF record means that all mail from the domain should be rejected. The qualifier associated with -all is "hard fail." - means that if an email doesn't match any of the allowed mechanisms, the receiving mail server should consider the email unauthorized.
Modifiers
Modifiers are optional elements and provide additional instructions to the SPF record. However, they don't change the message authentication process. The two most widely used modifiers are redirect and exp.
The redirect modifier sends a query to other domains. It indicates that the SPF check should redirect to another domain's SPF record. The email-receiving server needs to perform a DNS lookup for that domain to fetch the SPF record.
The exp modifier, on the other hand, specifies an external domain that can explain why an email server rejected a message.
SPF records, typically text-only, use spaces to separate components. The default qualifier is "pass," allowing concise records. Elements, like IP addresses or domains, follow the mechanism name and a colon.
For instance, "ip4:" precedes an IPv4 address range. An example SPF record might authorize email from specific IP addresses with "v=spf1 ip4:192.0.2.0/24 -all."
What does an SPF record look like?
SPF records appear as a single line of text within a DNS TXT record. It consists of the SPF protocol version prefix and one or more mechanisms. Here's an example of how an SPF record might look:
v=spf1 include:_spf.example.com ~all
In this example:
- v=spf1 indicates the SPF version used.
- include:_spf.example.com specifies that the SPF policy includes the SPF records of the domain "_spf.example.com".
- ~all designates a soft fail policy, meaning that if the SPF check fails, the server should treat the message with suspicion but not necessarily reject it.
SPF records can include various mechanisms, such as IP addresses, domain names, and modifiers, depending on the specific requirements of the domain's email authentication policy.
How to set an SPF record
Adding an SPF record involves modifying your domain's DNS zone file. The steps can vary depending on your domain registrar or hosting provider's control panel interface. Here’s a general guideline.
- Access your DNS zone management. Log into your hosting provider's account and locate the section for managing DNS records. Then, find your domain name and select it to access its specific DNS records.
- Create a new TXT record. Look for the option to create a new record. Choose TXT record type, as SPF records stay in TXT format.
- Enter your SPF record details. In the "Host" or "Name" field, you can typically leave it blank or enter "@" (at symbol) to signify the record applies to your entire domain. Then, enter your SPF record text string in the "Value" or "TXT data" field. This is where you define authorized email senders for your domain using mechanisms and qualifiers.
- Save your changes. Once you've entered the desired record in the value field, click the button to save or create a new record.
Why you need SPF records
Implementing SPF is a proactive step towards preserving the trustworthiness of email as a means of communication. It does the following:
- Combats email abuse. SPF records act as a first line of defense, specifying authorized email senders for a domain. They can also lower the overall volume of spam.
- Ensures email delivery. Domains lacking these records risk having their emails bounced or marked as spam. Therefore, these TXT records help improve email deliverability by verifying email legitimacy.
- Supports DMARC compliance. DMARC builds upon SPF and DKIM for email authentication. SPF records provide the foundation for DMARC to determine if an email is authorized. DMARC policies then dictate how to handle emails that fail authentication checks.
Frequently asked questions
How often should I update my SPF record?
You should update your SPF record whenever there are changes in your email sending infrastructure, such as adding or removing email servers or changing email service providers.
What should I do if my SPF record is causing delivery issues?
Review it for syntax errors and ensure it doesn't exceed DNS lookup limits.
How can I ensure my emails are delivered to my recipients' inboxes?
Use a verified domain and a reputable email service provider, maintain a clean email list, and ensure you correctly set up your SPF, DKIM, and DMARC records.
What are SPF authentication results?
An SPF authentication result is the outcome of an SPF check performed by the receiving email server. The results fall into several categories, including 'Pass,' 'Hardfail,' 'Softfail,' 'Neutral,' and 'None.'