The Simple Mail Transfer Protocol was designed in the early 1980s without any mechanism for verifying that the sender of an email is who they claim to be. Any mail server on the internet can transmit a message with any value in the envelope sender address, the From header, or the HELO greeting. This fundamental design limitation — a product of the trusted academic network environment of the era — enables phishing, business email compromise, and brand impersonation attacks that cost organizations billions of dollars annually, and it remains the root cause of the email authentication problem that SPF was created to address.
Sender Policy Framework addresses this vulnerability at the SMTP envelope level. An SPF record is a DNS TXT record published in your domain's zone that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving mail server accepts an incoming message, it queries the sending domain's SPF record and checks whether the connecting server's IP address appears as authorized. If the IP is not listed, the receiving server can reject or flag the message, protecting recipients from spoofed email that falsely claims to originate from your domain.
- SMTP has no built-in authentication for the envelope sender address — any server can claim any identity
- SPF validates the envelope sender domain against the IP address of the connecting mail server
- SPF records are published as DNS TXT records and queried in real time by receiving mail servers
- Without SPF, phishers and spammers can send convincing impersonation emails from your exact domain
- SPF is a foundational layer of the modern email authentication stack alongside DKIM and DMARC
An SPF record begins with the version tag v=spf1, which identifies the record as Sender Policy Framework version 1. Following this version tag are one or more mechanisms that specify which sources are authorized to send mail for the domain. The include: mechanism delegates authorization to a third-party SPF record, used for cloud providers like Google Workspace using include:_spf.google.com. The ip4: and ip6: mechanisms authorize specific IPv4 and IPv6 addresses or CIDR ranges directly. The a mechanism authorizes the IP addresses in the domain's own A records, and mx authorizes the servers listed in the domain's MX records.
Each mechanism is preceded by a qualifier that determines the action taken when the mechanism matches. A plus sign (+) means pass and is the default when no qualifier is specified. A tilde (~) produces a softfail, meaning the message should be accepted but marked as suspicious. A minus sign (-) means hardfail — the message is not authorized and should be rejected. A question mark (?) means neutral — no policy statement is made. The all mechanism at the end serves as a catch-all for any IP not matched by earlier mechanisms. A record ending in -all rejects all unlisted senders; ~all softfails them.
v=spf1— required version tag that opens every valid SPF recordinclude:_spf.google.com— delegate authorization to Google's published IP listip4:203.0.113.10— authorize a specific IPv4 address explicitlyip4:198.51.100.0/24— authorize an entire IPv4 subnet using CIDR notation-all— hardfail all senders not matched by earlier mechanisms (strongly recommended)
A domain using only Google Workspace for email publishes the minimal SPF record: v=spf1 include:_spf.google.com -all. This delegates the list of authorized sending IPs entirely to Google's published SPF record, which Google updates automatically as their infrastructure changes. A domain using only Microsoft 365 publishes: v=spf1 include:spf.protection.outlook.com -all. Organizations using both Google Workspace and Microsoft 365 simultaneously — during a migration, for example — combine the include directives in a single record.
Organizations with on-premises mail servers or dedicated sending IPs add explicit IP addresses alongside cloud provider includes. A complete record for a company with a dedicated outbound mail server at 203.0.113.25, Google Workspace, and Mailchimp for marketing email would be: v=spf1 ip4:203.0.113.25 include:_spf.google.com include:servers.mcsv.net -all. Every service that sends email on behalf of your domain must be explicitly included, or messages from that service will fail SPF checks at receiving servers and may be rejected or routed to spam folders.
- Google Workspace only:
v=spf1 include:_spf.google.com -all - Microsoft 365 only:
v=spf1 include:spf.protection.outlook.com -all - Both providers:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all - Custom IP plus Google:
v=spf1 ip4:203.0.113.25 include:_spf.google.com -all - Always end with
-allrather than~allto enforce a definitive reject policy
The most dangerous mistake is publishing multiple SPF TXT records for the same domain. DNS allows multiple TXT records on the same name, but the SPF specification requires exactly one SPF record per domain. When receiving servers encounter multiple SPF records, the result is a PermError — a permanent error that causes SPF to fail entirely, as if no SPF record existed at all. This mistake commonly occurs when a new DNS administrator adds a second SPF record instead of editing the existing one. Always update the existing record in place rather than creating a new one alongside it.
The SPF DNS lookup limit is another frequent source of failures. The SPF specification permits a maximum of ten DNS lookups when evaluating an SPF record. Each include:, a, mx, and redirect mechanism counts toward this limit, including nested lookups within included records. Exceeding ten lookups produces a PermError. Organizations that use many third-party email services — a marketing platform, a CRM, a transactional email service, a support ticketing system — can easily exceed this limit. Use the MXToolbox SPF Surveyor to count your lookups before publishing any SPF record changes.
- Never publish more than one SPF TXT record for the same domain — it produces a PermError
- Count DNS lookups: the limit is 10, including nested lookups within all included records
- Forgetting third-party senders like Mailchimp, Salesforce, or HubSpot causes SPF failures for their messages
- Using
~allinstead of-allallows spoofed messages to pass at many receiving servers - Including entire IP ranges that belong to shared hosting means neighbors on that range are also authorized
SPF alone is insufficient as an email authentication mechanism because it validates only the envelope sender — the technical MAIL FROM address used in the SMTP transaction — not the From header that email clients display to users. An attacker can craft a message with a spoofed visible From header while using a different, SPF-passing envelope sender address. This technique, called header spoofing, bypasses SPF entirely. DMARC closes this gap by requiring that the domain in the From header align with the domain that passed either SPF or DKIM authentication, making both the technical and visible sender consistent.
DKIM (DomainKeys Identified Mail) complements SPF by adding a cryptographic signature to the message tied to the signing domain regardless of the path the message traveled. Where SPF verifies the sending server's IP address at connection time, DKIM verifies the message content and headers have not been modified in transit. DMARC ties both mechanisms together and adds a policy that tells receiving servers what to do with messages that fail alignment — monitor only, quarantine to spam, or reject at the SMTP level. The full authentication stack of SPF, DKIM, and DMARC alignment is the current standard for serious email security.
- SPF validates the envelope sender IP address but not the visible From header shown to email users
- Header spoofing exploits SPF's limitation — DMARC alignment enforcement closes this gap
- DKIM adds a cryptographic signature that survives forwarding and validates message integrity
- DMARC requires the From domain to align with the domain that passed SPF or DKIM
- The complete email authentication stack is: valid SPF + valid DKIM + DMARC alignment enforcement
MXToolbox provides a comprehensive SPF lookup tool at mxtoolbox.com that parses your SPF record, counts DNS lookups, expands all include directives to display the full list of authorized IP addresses, and flags configuration errors including multiple records and exceeded lookup limits. This tool is the best starting point for verifying a new SPF record or diagnosing delivery problems suspected to be related to SPF configuration. It also identifies which specific mechanisms are contributing to your lookup count, making it straightforward to optimize records that approach the limit.
Mail-tester.com provides an end-to-end email authentication test by giving you a unique test email address. You send a real test message from your mail system to that address, and the tool evaluates the actual SPF, DKIM, and DMARC results for the message as received, along with a spam content score. Google's Admin Toolbox at toolbox.googleapps.com includes a Check MX tool that verifies DNS mail configuration including SPF, DKIM selectors, and MX records, providing diagnostic output that reflects how Google's own servers evaluate messages from your domain.
- MXToolbox SPF Lookup: parses record, expands all includes, counts lookups, flags all errors
- mail-tester.com: end-to-end test using a real sent message — evaluates SPF, DKIM, and DMARC
- Google Admin Toolbox Check MX: mirrors Google's own evaluation of your DNS mail configuration
dig TXT example.com +short— view your raw published SPF record directly from DNS- Test after every SPF record change to confirm no errors were introduced during the update