Sender Policy Framework (SPF) is a core part of modern email authentication. It helps receiving mail servers verify that messages sent from your domain are authorized and not spoofed. If SPF is missing or misconfigured, your emails may be rejected, flagged as spam, or fail to deliver entirely.
This is especially important when sending to major providers such as Google, Outlook, Yahoo, AOL, and iCloud. These providers now enforce stricter authentication requirements, and SPF is considered a baseline standard.
When to Check SPF
If you are experiencing sending or receiving issues, SPF should be one of the first things you review.
Common indicators include:
- Bounce-back messages referencing SPF or DKIM
- Emails being rejected by major providers
- Messages consistently landing in spam
If you are using a custom domain or a personalized email setup, the likelihood of SPF being involved increases.
What SPF Does
SPF defines which servers are allowed to send email on behalf of your domain. It works by publishing a record in your domain’s DNS. When a receiving server gets your message, it checks that record to confirm whether the sending source is authorized.
In simple terms, SPF acts like a permission list. If the sending server is not on that list, the message may be rejected or flagged.
While SPF has existed for years, enforcement has become much stricter recently. Most major providers now expect it to be properly configured.
Why SPF Is Often Missed
SPF is not always set up automatically, especially in more complex environments.
This commonly happens when services are split across multiple providers, for example:
- Your domain is registered with one company
- Your email is hosted with another
- Your website is hosted elsewhere
Because these systems are managed separately, SPF can be overlooked or only partially configured.
Most providers offer default SPF records, but it is still your responsibility to ensure they are correctly implemented and combined.
How SPF Is Configured
SPF is added as a TXT record in your DNS settings. You will need to access your DNS through your domain registrar, hosting provider, or a service like Cloudflare.
In most cases:
- The host is set to
@for the root domain - If sending from a subdomain, the host should match that subdomain
After adding or updating an SPF record, changes typically take a few hours to propagate, though it can take up to 24 hours in some cases.
Default SPF Records from Major Providers
Many providers supply a standard SPF configuration that you can include in your record.
Google Workspace
v=spf1 include:_spf.google.com ~all
Microsoft 365 (Outlook)
v=spf1 include:spf.protection.outlook.com ~all
Yahoo Mail
v=spf1 include:_spf.mail.yahoo.com ~all
(May vary depending on configuration.)
iCloud Mail (Apple)
v=spf1 include:icloud.com ~all
These include statements authorize those providers to send email on behalf of your domain.
How to Build an SPF Record
Every SPF record begins with:
v=spf1
From there, you define authorized senders using mechanisms such as:
ip4orip6for specific IP addressesincludefor third-party servicesaormxfor your domain’s servers
The record ends with a policy that defines how to handle unauthorized senders:
~all(soft fail)-all(hard fail)
Example: Single Server
If you send email from one server:
v=spf1 ip4:192.168.1.1 -all
This allows only that IP address to send mail.
Example: Multiple Services
If you use Google Workspace, SendGrid, and a server IP:
v=spf1 ip4:192.168.1.1 include:_spf.google.com include:sendgrid.net ~all
This authorizes all listed sources.
Important SPF Rules
- Only one SPF record is allowed per domain
- Multiple records must be merged into one
- SPF has a DNS lookup limit, too many includes can break validation
- Syntax must be exact, small errors can invalidate the record
Bulk Senders and SPF
If you send email through platforms like SendGrid, Mailchimp, or Constant Contact, they must be included in your SPF record.
Even though these services are not your primary mailbox provider, they send email on behalf of your domain. If they are not authorized, your messages may fail or be flagged.
Common SPF Errors
Frequent issues include:
- Missing SPF record
- Incorrect IP addresses
- Not including all sending services
- DNS misconfiguration
- Syntax errors
At a basic level, if a sending source is not listed in SPF, it is not authorized to send.
Common Bounce-Back Messages
SPF-related failures are often clearly identified in rejection messages.
Google (Gmail)
550-5.7.26 This mail is unauthenticatedSPF check failed
Microsoft (Outlook)
550 5.7.1 SPF validation failedAccess denied, SPF fail
Yahoo / AOL
554 Message not allowed - SPF failedSPF fail - not authorized
iCloud
550 5.7.1 Message rejected due to SPF failure
If you see phrases like “SPF fail,” “unauthenticated sender,” or “not authorized,” SPF should be reviewed immediately.
Deliverability and Scoring
SPF does not guarantee delivery on its own, but it plays an important role in email trust.
Email providers evaluate messages based on multiple factors. SPF is one of the positive signals that contributes to your overall acceptance score. Having a valid SPF record improves your chances of successful delivery and does not negatively impact your domain.
Real-World Scenarios
Missing SPF Record
A domain sends email without SPF configured. Messages to Gmail and Outlook are rejected or sent to spam. After adding the correct SPF record, delivery improves.
Bulk Sender Not Included
A company uses SendGrid for campaigns but does not include it in SPF. Emails fail authentication. Adding SendGrid resolves the issue.
Split Infrastructure
The domain, email hosting, and website are managed by different providers. SPF is incomplete. After combining all required sources into a single record, delivery stabilizes.
Invalid SPF Syntax
A formatting error causes the SPF record to fail validation. Correcting the syntax resolves bounce-back errors.