What is SPF (Sender Policy Framework)?

SPF, or Sender Policy Framework, is an essential email authentication method designed to detect and prevent email spoofing. Email spoofing is a common tactic used in phishing and spam campaigns, where the sender forges the email header to make it appear as though the email originated from a legitimate source.

How SPF Works: Authorizing Email Senders

SPF operates by allowing domain owners to explicitly list which mail servers are authorized to send email on their behalf.

At its core, SPF allows a domain owner to publish a list of mail servers that are authorized to send email on behalf of their domain. This list is stored in a special type of DNS TXT record within the domain's DNS settings.

When an email server receives an incoming email, it performs an SPF check:

1. It extracts the sending domain from the email's MAIL FROM address (also known as the envelope sender).
2. It then queries the DNS for that domain's SPF record.
3. The receiving server compares the IP address of the mail server that sent the email with the list of authorized IP addresses in the SPF record.

Based on this comparison, the SPF check will result in one of several outcomes (e.g., Pass, Fail, SoftFail, Neutral, None). If the sending IP address is not on the authorized list, the email is likely spoofed and can be flagged as spam or rejected.

The Importance of SPF for Email Security

Implementing an SPF record is a critical step in enhancing your domain's email security and overall deliverability.

• Prevents Spoofing: It significantly reduces the ability of malicious actors to send emails pretending to be from your domain, protecting your recipients from phishing attacks.
• Improves Deliverability: Email providers are more likely to deliver emails from domains with valid SPF records to the inbox, as it signals legitimacy and trustworthiness.
• Builds Trust: Protects your brand's reputation by preventing your domain from being associated with spam or phishing activities.

SPF Record Syntax: Building Your Policy

An SPF record is published as a TXT record in your domain's DNS. Here's a basic SPF record example:

v=spf1 include:_spf.google.com ~all

SPF Mechanisms

SPF records use several mechanisms to specify authorized senders. These mechanisms are evaluated in order from left to right.

v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.example.com a mx ~all

• v=spf1: Indicates the SPF version being used (always required and must be the first term).
• ip4: Authorizes a specific IPv4 address or range (e.g., ip4:192.0.2.0/24).
• ip6: Authorizes a specific IPv6 address or range (e.g., ip6:2001:db8::/32).
• include: Includes the SPF record of another domain (e.g., include:_spf.example.com). This is common for third-party email services.
• a: Authorizes the IP addresses found in the domain's A records.
• mx: Authorizes the IP addresses found in the domain's MX records.
• all: Matches all IP addresses not covered by previous mechanisms (typically used at the end of the record).

SPF Qualifiers

Each mechanism can have a qualifier that specifies how to handle matches. If no qualifier is specified, + (Pass) is assumed.

• + (Pass): Explicitly allows the sender. Emails from this source will pass SPF. (Default if no qualifier).
• - (Fail): Explicitly rejects the sender. Emails from this source will hard fail SPF.
• ~ (SoftFail): Marks the sender as suspicious but accepts the email. Often used during testing or for less strict policies.
• ? (Neutral): No policy statement is made about the sender. The email will neither pass nor fail SPF based on this mechanism.

Common SPF Examples for Popular Services

Google Workspace / Gmail

If you send emails through Google Workspace, your SPF record will typically look like this:

v=spf1 include:_spf.google.com ~all

Microsoft 365 / Outlook

For domains using Microsoft 365 for email, the SPF record often includes:

v=spf1 include:spf.protection.outlook.com ~all

Multiple Email Providers

If you use more than one service to send emails (e.g., Google Workspace for primary email and a marketing platform), you can combine include mechanisms:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Custom Mail Server + Third-Party Service

If you have your own mail server and also use a third-party service, you might combine ip4 with include:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Best Practices for SPF Implementation

Important considerations when implementing SPF to ensure effectiveness and avoid issues:

• Don't exceed 10 DNS lookups: SPF has a lookup limit of 10 to prevent Denial of Service (DoS) attacks. Exceeding this limit will cause your SPF record to fail.
• Use -all for strict policy: Once thoroughly tested and confirmed that all legitimate senders are authorized, change ~all (SoftFail) to -all (HardFail) for stronger protection against spoofing.
• Include all legitimate sending sources: Make sure to authorize all mail servers and services that send email on behalf of your domain (e.g., transactional email services, marketing platforms).
• Test before deploying: Use email testing tools to verify your SPF record works correctly and doesn't inadvertently block legitimate emails.

Warning: An incorrect SPF record can cause legitimate emails to be rejected or sent to spam folders. Always test thoroughly before setting a strict policy with -all.

Checking Your SPF Record

You can check your domain's SPF record using our DNS lookup tool or via command line utilities.

Using dig

dig TXT example.com +short | grep "v=spf1"

Using nslookup

nslookup -type=TXT example.com

SPF Validation Results: What They Mean

When an email is received, the SPF check performed by the recipient's mail server produces one of these results:

• Pass: The sending IP is authorized by the SPF record.
• Fail: The sending IP is not authorized. This typically leads to rejection or marking as spam.
• SoftFail: The sending IP is probably not authorized. The email is usually accepted but marked as suspicious.
• Neutral: The SPF record makes no policy statement about the sender.
• None: No SPF record found for the sending domain.
• TempError: A temporary DNS error occurred during the SPF check.
• PermError: A permanent error was found in the SPF record's syntax or structure.

Limitations of SPF

While powerful, SPF has some limitations that necessitate combining it with other email authentication methods.

• Doesn't protect against display name spoofing: SPF only checks the MAIL FROM address (envelope sender), not the visible "From" address that users see in their email client.
• Breaks with email forwarding: When an email is forwarded, the original sending IP changes, which can cause forwarded emails to fail SPF checks.
• No protection for DMARC alignment: SPF alone doesn't ensure that the visible "From" address aligns with the authenticated domain. This is where DMARC comes in.

Tip: For comprehensive email security, SPF should be combined with DKIM and DMARC to create a complete authentication framework that addresses these limitations.