SPF records are a surprisingly blunt instrument for authorizing senders, and they’re often misunderstood as a "set it and forget it" DNS entry.
Let’s see SPF in action. Imagine a mail server at mail.example.com sending an email on behalf of sender.example.com. Before this email even hits the recipient’s inbox, the receiving server will perform a DNS lookup for sender.example.com. It’ll fetch the SPF record, which might look something like this:
sender.example.com. 3600 IN TXT "v=spf1 mx a ip4:192.168.1.100 -all"
The receiving server then checks:
mx: Does the sending mail server’s IP address match any of the IP addresses listed insender.example.com’s MX records?a: Does the sending mail server’s IP address match the IP address associated with the A record forsender.example.com?ip4:192.168.1.100: Is the sending mail server’s IP address192.168.1.100?-all: If none of the above match, the email should be considered unauthorized (a "fail").
If any of these conditions are met, the email passes the SPF check. The -all is crucial; it’s the "fail" mechanism. Other common mechanisms include ~all (soft fail, often treated as a fail), +all (allow all, rarely used and insecure), and ?all (neutral, no explicit policy).
This system solves the problem of email spoofing – where a sender pretends to be from your domain. By publishing an SPF record, you tell the world which mail servers are authorized to send email for your domain. When a receiving server sees an email claiming to be from sender.example.com but originating from an IP address not listed in the SPF record, it can reject it or mark it as spam.
The core components you control are the mechanisms within the TXT record. These specify how to check the sending IP. Common mechanisms include:
a: Authorizes the IP address of the domain’s A record.mx: Authorizes the IP addresses of the domain’s MX (Mail Exchanger) records.ip4: Authorizes specific IPv4 addresses.ip6: Authorizes specific IPv6 addresses.include: Authorizes IP addresses specified by another domain’s SPF record. This is how you delegate sending for services like SendGrid, Mailchimp, or Google Workspace.exists: Checks if a given hostname resolves to an IP address.
The qualifiers determine the action taken:
+: Pass (explicitly allowed).-: Fail (explicitly denied).~: SoftFail (likely unauthorized, but receiver discretion).?: Neutral (no policy, usually treated as neutral or softfail).
A typical SPF record for a domain that sends mail from its own servers and uses a third-party service might look like:
example.com. 3600 IN TXT "v=spf1 mx a include:_spf.google.com ~all"
Here, the domain example.com authorizes mail from its MX records, its A record, and any IPs authorized by Google Workspace’s SPF record. The ~all suggests that if an email comes from an IP not covered by these, it’s likely unauthorized but the receiver has some leeway.
The most surprising thing about SPF is its limited scope: it only authorizes the sending IP address. It doesn’t verify the actual sender’s email address (the MAIL FROM or Return-Path), nor does it prevent modifications to the email content. This is why SPF is often used in conjunction with DKIM and DMARC for more robust email authentication.
The primary constraint on an SPF record is the DNS lookup limit. An SPF record can only contain a maximum of 10 DNS lookups. Each mx, a, ptr, exists, and include mechanism or redirect modifier counts as one lookup. This means you can’t just include dozens of services without hitting this limit, forcing you to consolidate or use IP addresses directly where possible.