What is SPF (Sender Policy Framework)? | NOC.org

Understanding Sender Policy Framework

Sender Policy Framework (SPF) is an email authentication protocol that allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. SPF works by publishing a DNS TXT record that lists approved sending IP addresses and hostnames. When a receiving mail server gets a message, it checks the SPF record for the sender's domain and compares it against the IP address of the server that delivered the email. If the IP is not listed, the message fails SPF authentication.

SPF was designed to combat email spoofing, a technique where attackers forge the "From" address to make a message appear to come from a trusted domain. Without SPF, any mail server on the internet can claim to send email for any domain. SPF gives domain owners a way to publish an explicit list of authorized senders, making it significantly harder for attackers to impersonate legitimate organizations.

How SPF Works

The SPF authentication process follows a specific sequence:

1. Email is sent: A mail server sends a message with an envelope sender (the MAIL FROM address used during the SMTP transaction).
2. Receiving server extracts the domain: The receiving mail server extracts the domain from the envelope sender address.
3. DNS lookup: The receiving server queries DNS for a TXT record at that domain containing an SPF policy.
4. Policy evaluation: The server evaluates the SPF record's mechanisms against the connecting IP address.
5. Result: The check returns a result: pass, fail, softfail, neutral, temperror, permerror, or none.

It is important to note that SPF checks the envelope sender (Return-Path), not the header "From" address that users see in their email client. This distinction matters for DMARC alignment, which ties SPF results to the visible sender address.

SPF Record Syntax

An SPF record is a DNS TXT record that begins with v=spf1 followed by one or more mechanisms and a default qualifier. Here is a typical example:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

This record authorizes the 203.0.113.0/24 subnet, Google Workspace servers, and SendGrid servers to send email for the domain. All other sources are rejected (-all).

Mechanisms

SPF provides several mechanisms to define authorized senders:

• ip4: Matches a specific IPv4 address or CIDR range. Example: ip4:192.0.2.1 or ip4:192.0.2.0/24.
• ip6: Matches a specific IPv6 address or prefix. Example: ip6:2001:db8::/32.
• a: Matches if the sending IP is one of the A or AAAA records for the specified domain. Example: a:mail.example.com.
• mx: Matches if the sending IP is one of the MX hosts for the specified domain. Example: mx (uses the current domain).
• include: References the SPF record of another domain. If the included domain's SPF record returns a pass, this mechanism matches. Example: include:_spf.google.com.
• exists: Matches if a DNS A record lookup for the specified domain returns a result. Used for advanced macro-based policies.
• all: Matches everything. Always placed at the end of the record as a catch-all default.

Qualifiers

Each mechanism can have a qualifier prefix that determines what happens when it matches:

• + (Pass): The sender is authorized. This is the default if no qualifier is specified.
• - (Fail): The sender is explicitly not authorized. Messages should be rejected.
• ~ (SoftFail): The sender is probably not authorized. Messages are accepted but marked.
• ? (Neutral): No assertion is made about the sender.

The most common ending is -all (hard fail), which tells receivers to reject any email not matching a listed mechanism. During initial deployment, many administrators use ~all (soft fail) to avoid accidentally blocking legitimate email while they identify all authorized senders.

The 10-Lookup Limit

SPF has a critical limitation: the total number of DNS lookups during SPF evaluation must not exceed 10. Each use of include, a, mx, exists, and redirect counts as one lookup. The ip4 and ip6 mechanisms do not require DNS lookups and therefore do not count toward the limit.

When a record exceeds 10 lookups, the SPF check returns a permerror, which most receiving servers treat as an SPF failure. This is a common problem for organizations that use many third-party email services (marketing platforms, CRM systems, ticketing tools), each requiring its own include statement.

Strategies to stay within the limit include:

• Replacing include mechanisms with flattened ip4 and ip6 entries where possible.
• Using SPF flattening services that resolve includes to IP addresses and keep the record updated.
• Consolidating third-party sends through fewer providers.
• Moving some senders to subdomains with their own SPF records.

SPF Alignment

SPF alignment refers to the relationship between the domain in the envelope sender (Return-Path) and the domain in the header "From" address. DMARC requires that these two domains align for the SPF result to count toward DMARC authentication. Alignment can be strict (exact domain match) or relaxed (organizational domain match, allowing subdomains).

For example, if the header "From" is user@example.com and the Return-Path is bounce@mail.example.com, relaxed alignment passes because both share the organizational domain example.com. Strict alignment would fail because the domains are not identical.

Common SPF Mistakes

Several errors frequently cause SPF problems:

• Multiple SPF records: A domain must have exactly one SPF TXT record. Having two or more causes a permerror. If you need to add a new service, edit the existing record rather than creating a second one.
• Exceeding the lookup limit: As described above, going over 10 DNS lookups invalidates the entire SPF check.
• Using +all: Ending a record with +all authorizes every IP address on the internet, effectively disabling SPF. Always use -all or at minimum ~all.
• Forgetting third-party senders: SaaS platforms that send email on your behalf (transactional email services, marketing tools, helpdesk software) must be included in your SPF record.
• Not updating after migration: Moving to a new email provider without updating the SPF record causes legitimate email to fail authentication.
• Using the ptr mechanism: The ptr mechanism is deprecated because it is slow, unreliable, and causes excessive DNS queries. Avoid it entirely.

SPF and DNS Configuration

SPF records are managed through your domain's DNS configuration. When adding or modifying an SPF record, keep these best practices in mind:

• Set a reasonable TTL (300-3600 seconds) so changes propagate quickly when needed.
• Keep the record under 255 characters per string in the TXT record, using multiple strings if necessary (though most modern DNS providers handle this automatically).
• Test your record using SPF validation tools before deploying to production.
• Monitor SPF results through DMARC aggregate reports to identify unauthorized senders and configuration errors.

SPF as Part of Email Authentication

SPF is one piece of a three-part email authentication framework. It works alongside DKIM (DomainKeys Identified Mail), which uses cryptographic signatures to verify message integrity, and DMARC, which ties SPF and DKIM results together with a domain-level policy. Deploying all three protocols provides the strongest protection against email spoofing and phishing attacks.

On its own, SPF verifies that the sending server is authorized but does not protect against message tampering or guarantee that the visible "From" address is legitimate. DKIM addresses message integrity, and DMARC ensures that SPF or DKIM results align with the domain the recipient sees. Together, they form a comprehensive defense that major mailbox providers like Google, Microsoft, and Yahoo require for reliable email delivery.

Summary

SPF is a foundational email authentication protocol that helps prevent spoofing by allowing domain owners to publish authorized sending IPs in DNS. A well-maintained SPF record, combined with DKIM and DMARC, significantly reduces the risk of your domain being used in phishing attacks and improves email deliverability. Pay close attention to the 10-lookup limit, avoid common configuration mistakes, and monitor your results through DMARC reporting to maintain a healthy email authentication posture.

Need help securing your infrastructure? Explore NOC.org plans to get started.