How SPF Works
SPF (Sender Policy Framework) is a DNS record that declares which mail servers are allowed to send email on behalf of your domain. Receiving servers check it before accepting a message.
What SPF does
When a mail server receives an incoming message claiming to be from @yourcompany.com, it looks up your domain's SPF record in DNS. That record lists every IP address or mail service authorized to send as your domain. If the sending server isn't on the list, SPF fails.
SPF checks the envelope sender — the address used during the SMTP handshake, sometimes called the Return-Path or bounce address. This is different from the From: address visible in the email client. That distinction matters for DMARC alignment.
Reading an SPF record
An SPF record is a DNS TXT record on your root domain:
yourdomain.com TXT "v=spf1 include:_spf.google.com -all"
Breaking it down:
| Part | Meaning |
|---|---|
v=spf1 | This is an SPF record |
include:_spf.google.com | Google Workspace is authorized to send |
-all | Everything else is not authorized (hard fail) |
Common mechanisms
include: — Pulls in another domain's SPF record. Used for third-party senders like Google, SendGrid, Mailchimp.
ip4: / ip6: — Authorizes a specific IP address or CIDR range directly.
a: — Authorizes the IP address of a specific hostname's A record.
mx: — Authorizes the mail servers in your MX records.
-all — Hard fail. Anyone not listed is rejected. Preferred once your record is complete.
~all — Soft fail. Anyone not listed is marked suspicious but not rejected. Common during setup.
+all — Authorizes everyone. Never use this.
Multiple senders
If you use Google Workspace, SendGrid, and a helpdesk tool that sends as your domain, your SPF record needs to include all of them:
yourdomain.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.helpdesk.example.com -all"
You must have exactly one SPF record per domain. If you have two v=spf1 TXT records, SPF will fail with a PermError.
The DNS lookup limit
SPF is limited to 10 DNS lookups per evaluation. Each include:, a:, mx:, and similar mechanism counts toward that limit. Exceeding it causes a PermError, which counts as a failure.
If you have many senders, this limit can be a real problem. SPF flattening — replacing includes with their resolved IP ranges — is a common fix, but flattened records need to stay updated as vendors change their infrastructure. dmarcdemon monitors your SPF record and alerts you when it breaks the lookup limit or when IPs go stale.
SPF and forwarding
SPF breaks on email forwarding. When a message is forwarded, the envelope sender changes to the forwarder's domain. The original domain's SPF record no longer applies, and SPF fails.
This is why DKIM is equally important. DKIM signs the message itself and typically survives forwarding. DMARC can pass on DKIM alignment alone, even when SPF fails due to forwarding.
SPF alone isn't enough for DMARC
SPF passing does not guarantee DMARC passing. DMARC requires alignment: the SPF-authenticated domain must match the visible From: address. A marketing platform that passes SPF under its own domain — not yours — will still fail DMARC alignment.
See DMARC Alignment Explained for how this works.