An email is an essential tool for businesses, and most of us rely on it daily for communication. However, as the number of email users has grown, so has the problem of spam, email spoofing, phishing, whaling, and email fraud. These types of attacks can cause significant harm, including loss of reputation, financial loss, and data breaches. To prevent such attacks, businesses must take proactive steps to secure their email systems. One of the ways to do that is by configuring an SPF setup.

Major email providers like Yahoo Mail and Google Workspace recommend email authentication protocols like Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) to protect email recipients from potential fraud.

Key Takeaways

Email authentication protocols like SPF are essential tools for preventing email spoofing, phishing, and fraud.
Setting up a valid SPF record involves specifying all authorized email servers (including third parties) via a single DNS TXT record per domain.
Regularly updating SPF records and adhering to the 10 DNS lookup limit (avoiding discouraged mechanisms like ‘ptr’) are crucial for maintenance and deliverability.
Testing your SPF record helps verify correct configuration and functionality.
SPF provides foundational protection but works best with DKIM and DMARC for comprehensive email security and compliance.

SPF in Email Security – Explained

What is SPF? SPF stands for Sender Policy Framework. An email authentication protocol allows you to specify which servers are authorized to send emails to your domain. SPF works by adding a DNS TXT record to your domain’s DNS zone file, which lists the IP addresses or hostnames permitted to send emails from that specific domain name. This record is looked up by receiving mail servers to verify the authenticity of an email; it tells other email servers that any emails sent from your domain that do not come from authorized IP addresses should be handled according to your specified policy (e.g., rejected or marked as suspicious).

Setting up a valid SPF record is essential to prevent unauthorized users from sending emails using your domain name. For example, spammers or attackers may use your domain name to send spam or phishing emails, launch whaling campaigns, or commit other fraud, which can damage your brand’s reputation, lead to your legitimate emails being blocked or rejected by other servers, and compromise the security of your customers and employees.

Simplify SPF Setup with PowerDMARC!

Start 15-day trial Book a demo

SPF Components

The main components of an SPF record in DNS are as follows:

Version (v=spf1):
Specifies the SPF version, always starting with v=spf1.
IP4 and IP6 (ip4: / ip6:):
Lists authorized IPv4 and IPv6 addresses allowed to send emails for the domain.
A and MX Mechanisms (a: / mx:):
- a: allows emails from servers whose IPs match the A record of the domain (or a specific hostname if provided, e.g., `a:mail.example.com`).
- mx: allows emails from servers listed in the domain’s MX (Mail Exchange) records. This should specify the domain (`mx:example.com`), not a specific mail server hostname.
Include Mechanism (include:):
Permits other domains’ SPF records to authorize senders, useful when third-party services send emails on behalf of your domain. Consult the third-party organization to confirm the correct domain value for the include statement.
PTR Mechanism (ptr:):
Performs a reverse DNS lookup. However, RFC7208 discourages the use of the ‘ptr’ mechanism due to reliability issues and performance burdens. It’s generally recommended to use ‘a’, ‘mx’, or ‘ip4’/’ip6’ mechanisms instead.
All Mechanism (all):
Sets a default rule for senders not matched by previous mechanisms. It should always be placed at the very end of the SPF record. The options are:
- -all: Hard fail (reject non-authorized IPs). Recommended for enforcement.
- ~all: Soft fail (mark non-authorized IPs as suspicious). Often used during initial setup or testing.
- ?all: Neutral (no specific action taken on non-authorized IPs). Offers little protection.
- +all: Pass (allows all IPs, strongly discouraged as it negates SPF’s purpose).
Redirect (redirect=):
Points to another domain’s SPF record if you want to use its policy instead of defining mechanisms in the current record. Replaces the need for an ‘all’ mechanism.
Modifiers:
Optional rules for fine-tuning, like `exp=` for explanations on failures, though less common.

SPF Example

v=spf1 ip4:192.168.1.1 include:_spf.thirdparty.com -all

This example allows emails from 192.168.1.1 and includes a third-party SPF record, rejecting emails from other IPs with -all.

Mastering SPF Settings

An SPF setup refers to the SPF email authentication protocol configuration in the DNS of a domain owner. An SPF setup allows you to authorize your legitimate sending sources, making sure receiving servers can easily demarcate between a genuine email sender and one who is merely impersonating a legitimate domain name. It’s a necessary step in email validation, to aid in protection against email-based cyberattacks.

How to Setup and Add SPF Records

An SPF setup is not only essential for your active sources but also for all domains you own, including non-sending or “parked” domains, to guarantee they are safe against malicious usage. Setting up an SPF record is a straightforward process, and it involves the following steps:

Step 1: Determine Your Email Servers and Sending Sources

The first step is to compile a comprehensive list of all servers and services authorized to send emails for your domain. These sources can include your own mail servers (e.g., Microsoft Exchange, web-based like Gmail), any third-party email service providers (ESPs) you use for marketing or transactional emails, and other services like payment processors, e-commerce platforms, CRMs, helpdesks, or support/ticketing systems that send emails on your behalf.

Step 2: Create an SPF Record

Once you have identified all your authorized sending sources, you can create an SPF record using an SPF record generator tool or by manually crafting the syntax. An SPF record is a TXT (text) record in your domain’s DNS configuration. Ensure you create only one SPF record per domain. A simple syntax might look like:

v=spf1 ip4:<IP address> include:<third-party domain> -all

In this example, “v=spf1” indicates the SPF version, “ip4:<IP address>” lists an authorized IP, “include:<third-party domain>” incorporates a third-party sender’s policy, and “-all” at the end indicates that emails from sources not listed should be rejected. Double-check for typos, as even small errors like ‘inlcude’ instead of ‘include’ can invalidate the record.

Step 3: Publish Your SPF Record

After creating your SPF record, you need to publish it in your domain’s DNS. Domain administrators can make the required DNS updates easily. You can do this by logging in to your DNS provider’s website and adding a new TXT record with your SPF record content. The actual content should start with `v=spf1` and should not be enclosed in double quotes within the DNS entry itself (though some DNS interfaces may display it with quotes). Alternatively, you can ask your IT team or hosting provider to do this for you. Keep in mind that DNS changes can take some time (up to 72 hours, though often much faster) to propagate across the internet.

Step 4: Test Your SPF Record

Once you have published your SPF record and allowed time for propagation, it is essential to test it to make sure that it is working correctly and doesn’t exceed the 10 DNS lookup limit (mechanisms like `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` count towards this limit, including any lookups within nested `include` statements). You can use online SPF record checkers, such as the one provided by PowerDMARC or MXToolbox, to test your SPF record. These tools will tell you whether your SPF record is valid, correctly formatted, within the lookup limit, and functioning as intended.

5 Misconceptions About SPF Records

There are certain SPF record myths doing rounds on the internet that may lead to people making incorrect decisions. Let’s bust them one by one:

1. SPF Alone Can Prevent Spoofing

This is untrue. Setting up SPF alone cannot prevent all types of spoofing or impersonation, especially involving the ‘From’ header that users see. In order to provide stronger protection and instruct receivers on how to handle failures, SPF needs to be combined with DKIM and DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC allows domain owners to specify a policy (like reject or quarantine) for emails that fail SPF or DKIM checks.

2. You Can Use +all in Your SPF Record

Using +all effectively allows any server on the internet to send emails on behalf of your domain. This completely negates the security purpose served by the SPF protocol. Instead, ~all (soft fail) or preferably -all (hard fail) are recommended mechanisms to use at the end of your record to deploy SPF effectively.

3. SPF Works for Forwarded Emails

We all wish that was true. Unfortunately, in many mail forwarding scenarios, SPF breaks. This happens because the forwarding server’s IP address often doesn’t match the authorized IPs listed in the original sender’s SPF record, and the header information may change. In such cases, protocols like DKIM (which usually survives forwarding) or preferably ARC (Authenticated Received Chain) can help maintain authentication results across forwarding hops.

4. SPF Records Have Unlimited DNS Lookups

The SPF specification (RFC) enforces a maximum limit of 10 DNS lookups per SPF check. Mechanisms like `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` perform DNS lookups. Exceeding this limit results in an SPF PermError (Permanent Error), which can cause legitimate emails to fail authentication. It is essential to keep your record concise and potentially use SPF optimization methods like flattening or dynamic SPF Macros to stay within the limit, especially if you use many third-party senders.

5. With SPF You Can “Setup and Forget!”

Don’t make this SPF mistake! Your email sending infrastructure can change over time – you might add new third-party services, change ESPs, or decommission old servers. You need to update your SPF records regularly to reflect these changes. Failing to update means new legitimate sending sources might not be authorized, potentially causing their emails to be blocked or marked as spam by receiving servers.

How Does SPF Record Work?

The domain owner creates an SPF record (a TXT record in DNS) manually or using an online tool that specifies sending sources (IP addresses, domains via includes, etc.) that are permitted to send emails on behalf of the domain.
When an email is received, the receiver’s mail server extracts the domain from the email’s Return-Path (also known as envelope sender or Mail From) address.
The receiving server performs a DNS query to look up the SPF TXT record for that sender domain.
The receiving server checks if the IP address of the connecting server that sent the email matches any of the authorized sources listed in the SPF record.
If there is a match (Pass), the email passes the SPF check. If there isn’t a match, the result depends on the ‘all’ mechanism defined in the record (e.g., -all for Fail, ~all for SoftFail, ?all for Neutral). This result can influence whether the email lands in the inbox, spam folder, or gets rejected, especially when combined with DMARC.

Tips for an Accurate SPF Setup

Here are some tips for creating a strong and effective SPF record setup:

Include all authorized sending sources: Make sure to meticulously list every server and third-party service authorized to send emails for your domain. Missing a source can lead to deliverability issues for legitimate mail.
Apply SPF to all your domains: Protect even non-sending (parked) domains by publishing an SPF record like `v=spf1 -all` to explicitly state that no emails should originate from them.
Use the correct ‘all’ mechanism: Use `~all` (SoftFail) during initial testing or transition phases. Once confident, use `-all` (Fail) for stricter enforcement, which clearly tells receiving servers to reject unauthorized emails. Avoid `?all` (Neutral) and never use `+all` (Pass).
Position ‘all’ correctly: The `all` mechanism should always be the very last component in your SPF record string.
Use the “include” mechanism correctly: The “include” mechanism is essential for authorizing third-party senders. Ensure you use the correct domain provided by the third party for their SPF policy.
Use ‘mx’ and ‘a’ mechanisms carefully: Use `mx` to authorize servers listed in your domain’s MX records (`mx:yourdomain.com`). Use `a` to authorize the IP address(es) associated with your domain’s A record (`a`) or a specific hostname (`a:mail.yourdomain.com`). Do not use `mx` with a specific mail server hostname.
Avoid discouraged mechanisms: Do not use the `ptr` mechanism as it is deprecated and unreliable.
Stay within the 10 DNS lookup limit: Be mindful of mechanisms (`include`, `a`, `mx`, `exists`, `redirect`) that require DNS lookups. Nested lookups count. Exceeding the limit leads to PermError.
Check for typos: Carefully review your SPF record for syntax errors or typos before publishing.
Publish correctly in DNS: Ensure the record is published as a TXT type and the content starts with `v=spf1` without being enclosed in quotes in the actual DNS data field.
Keep your SPF record up to date: As your email infrastructure or list of third-party senders changes, make sure to update your SPF record promptly to reflect these changes. Regularly review and maintain your record.

Benefits of Optimizing Your SPF Settings with PowerDMARC

The DNS lookup limit is a significant restriction imposed by the SPF standard. It limits the number of DNS lookups that can be performed when a receiving server verifies an email’s SPF record. This limit is set at 10 DNS lookups. If evaluating the SPF record requires more than 10 lookups (including nested lookups from `include` mechanisms), it results in an SPF PermError, potentially causing legitimate emails to fail authentication and face deliverability issues.

SPF flattening is a technique used to reduce the number of DNS lookups required to verify an email’s SPF record. It works by replacing mechanisms like `include` with the actual IP addresses resolved from those lookups, consolidating them directly into the main SPF record. This can significantly reduce the DNS query count needed to authenticate an email. PowerDMARC offers automated SPF flattening or dynamic macro-based solutions to manage complex SPF records and stay under the limit.

Here’s an example of how SPF flattening can help:

Let’s say your company uses several third-party services to send emails. This may include marketing automation software (e.g., `include:spf.marketing.com`), a helpdesk system (e.g., `include:spf.support.com`), and a CRM tool for small businesses (e.g., `include:spf.crm.com`). Each of these `include` statements requires a DNS lookup, and the included records might contain further lookups themselves. If the total count exceeds 10, your SPF record will break.

By using SPF flattening (or a macro solution), the IP addresses authorized by these third-party includes can be resolved and represented more efficiently, often reducing the total number of required lookups to stay within the limit. This ensures that when an email server performs a DNS lookup to verify your SPF record, it can successfully complete the evaluation without hitting the PermError threshold.

To Sum It Up

An SPF setup is a crucial step in securing your email system and preventing email fraud. By creating an accurate SPF record, publishing it correctly in your domain’s DNS configuration, and maintaining it over time, you can ensure that legitimate emails sent from your domain are authenticated and help prevent unauthorized users from abusing your domain name. Following the best practices and tips outlined above will help you create a strong SPF record and enhance your overall email security posture, especially when used in conjunction with DKIM and DMARC.

FAQs on Setting Up an SPF Record

Can I have multiple SPF records for one domain?

No. A domain must have exactly one SPF record. Publishing multiple SPF records for the same domain is a common mistake that will cause SPF validation to fail or return unpredictable results (often None or PermError). If you need to authorize multiple sending sources, they must all be included within a single SPF TXT record string.

Can I Split a Large SPF Record?

Splitting up a logically large SPF policy across multiple TXT records for the same domain is not allowed due to the one-record rule. Additionally, individual DNS TXT records have character string limits (though modern DNS systems often support multiple strings within a single record to overcome older 255-character limits). If your record becomes too complex or exceeds the 10 DNS lookup limit, you cannot simply split it. Instead, try these tactics:

Simplify your record: Remove redundant or unnecessary entries. Consolidate IP ranges using CIDR notation where possible.
Minimize lookup-generating mechanisms: Reduce the number of `include`, `a`, `mx`, `exists`, and `redirect` mechanisms.
Use SPF management solutions: Employ third-party services that offer SPF flattening or dynamic SPF (macro-based) solutions to manage complex records and stay within limits.

Why Is SPF Record Used?

An SPF record is used to prevent email spoofing by allowing domain owners to publicly declare which mail servers are authorized to send email on behalf of their domain. Receiving servers check this record to verify the sending server’s legitimacy, reducing the chances of phishing, spam, and other fraudulent emails sent using the domain’s name reaching recipients’ inboxes.

When Do You Need SPF?

You need SPF for any domain you own, especially those used to send email. It is a foundational email authentication protocol needed to improve email deliverability, protect your brand reputation, verify authenticity, and comply with receiving server policies and industry best practices, including recent mandates from major providers like Google and Yahoo. Learn more about the importance of SPF configuration. Even domains that do not send email should have a restrictive SPF record (e.g., `v=spf1 -all`) to prevent abuse.

How to Optimize SPF Record?

You can optimize your SPF record manually by carefully reviewing and consolidating authorized senders, removing unused sources, using efficient IP range notation (CIDR), and minimizing mechanisms that cause DNS lookups. However, for complex scenarios or to ensure you stay under the 10-lookup limit, a more hassle-free option is to use third-party SPF optimization services that offer automated flattening or dynamic SPF macro solutions for ongoing record management.

How Do I Know My SPF Record is Set Correctly?

You can check your SPF record using an online SPF record lookup tool. These tools validate the syntax, check if the record exists in your DNS, verify if you are within the 10 DNS lookup limit, and confirm whether it is generally configured correctly.

“`

About
Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

How to Set Up SPF Record? – SPF Setup Guide