SPF: the first line of defense against spoofing
The Sender Policy Framework (SPF) is an email authentication mechanism that allows a domain owner to specify which servers are authorized to send email on their behalf. Without SPF, anyone can send emails making your domain appear as the sender — a technique called spoofing that is the basis of most phishing attacks. SPF was standardized in RFC 7208 and represents the first of the three pillars of modern email authentication, alongside DKIM and DMARC.
When a server receives an email, it checks the SPF record of the sending domain. If the IP of the server that sent the email is in the list of IPs authorized by the SPF record, the check passes. Otherwise, the email is flagged as potentially fraudulent. The final decision (accept, reject, or flag) depends on the policy specified in the record and the domain's DMARC configuration.
Anatomy of an SPF record
An SPF record is a TXT record in the domain's DNS that starts with v=spf1 followed by a series of mechanisms and qualifiers. The mechanisms define who is authorized to send, while the final qualifier (typically ~all or -all) defines what to do with emails that do not match any authorized mechanism.
The 10 DNS lookup limit
One of the most critical and least understood aspects of SPF is the 10 DNS lookup limit. Every time the SPF record uses a mechanism that requires an additional DNS query (include, a, mx, redirect, exists), it counts as a lookup. Exceeding the limit of 10 causes a permerror: the SPF record is considered invalid and authentication fails for all emails.
This limit becomes problematic when using many third-party services for email sending. A single include can in turn contain other nested includes, and each one counts toward the limit. For example, include:_spf.google.com alone already consumes 3-4 lookups. Add Mailchimp, SendGrid, HubSpot, and the limit is quickly exhausted. Our SPF Lookup analyzes your SPF record and automatically counts DNS lookups, warning you if you are close to the limit.
How to solve the most common SPF problems
The most frequent problem is exceeding the 10 lookup limit. Solutions include: replacing include mechanisms with direct ip4/ip6 entries (which do not count as lookups), using SPF flattening services that resolve includes into static IPs, or consolidating email services to reduce the number of includes needed. Another strategy is to use dedicated subdomains for different services: marketing@news.example.com can have its own independent SPF record.
Another common error is having multiple SPF records for the same domain. The RFCs clearly state that a domain must have only one TXT record starting with v=spf1. Multiple records cause a permerror. If you need to authorize multiple sources, combine everything into a single record. Check for duplicate records with the TXT Lookup, which lists all TXT records for the domain.
SPF alone is not enough: the SPF + DKIM + DMARC trio
SPF has an important limitation: it only verifies the IP of the sending server, not the content of the From header that the user sees. An attacker could use a server authorized by their own SPF to send emails with your domain in the From header. This is why SPF must be paired with DKIM and DMARC. DKIM cryptographically signs the email, while DMARC verifies that the domain in the From header is aligned with the domain authenticated by SPF or DKIM.
Use the DMARC Lookup to verify that your domain has an active DMARC policy. Without DMARC, even a perfect SPF does not prevent spoofed emails from being delivered. The combination of all three protocols creates a layered defense that makes spoofing your domain extremely difficult, protecting your reputation and your recipients.
The ideal configuration includes: SPF with ~all or -all to authorize only legitimate servers, DKIM with a 2048-bit key to sign all outgoing emails, and DMARC with a progressive policy (from p=none for monitoring to p=reject for total blocking). This trio is now considered the minimum requirement for any domain that sends email.