The Sender Policy Framework (SPF) is an email authentication standard that lets a domain owner publish a DNS record listing the servers allowed to send email for the domain. Receiving servers compare the server that delivered a message against that list. SPF is defined in RFC 7208.
Why it matters in 2026: Gmail and Yahoo require authentication from everyone who sends to their users, and bulk senders need SPF together with DKIM and DMARC. A correct SPF setup is one of the first items in our 8 actionable steps to improve email deliverability.
Imagine the following scenario:
You receive an email from john@example.com. The email was sent from a server named mail.spammer.com.
When receiving the email, your provider looks up the SPF record published at example.com. The SPF record is optional. If example.com publishes no SPF record, there is no SPF result at all, and the receiver decides based on other signals, such as DKIM, DMARC and its own filters.
If a record is published, the receiver checks whether the sending server mail.spammer.com is authorized to send emails for example.com.
Let's assume the record doesn't authorize mail.spammer.com. The result is then usually a fail or a softfail, depending on the record's policy (see below). A fail doesn't always mean the email is rejected: the receiver may also deliver it to spam or flag it, and the domain's DMARC policy plays a large part in that decision.
SPF records are published as DNS TXT records on your domain. (A dedicated SPF record type once existed, but its use is discontinued.) Let's look at examples of SPF records to understand how they work:
An SPF record starts with the prefix v=spf1. This lets the parsers know that the current record is an SPF record.
The prefix is followed by zero or more mechanisms. Mechanisms describe the hosts that are used to send emails and rules on how the recipient system should act. The most used mechanisms are:
A record can also end with the redirect= modifier, which hands the whole check over to another domain's SPF record.
All mechanisms can be prefixed with a qualifier. It sets the result when that mechanism matches:
| Qualifier | Result | Meaning |
|---|---|---|
| + | Pass | The host is authorized (default if no qualifier is given) |
| - | Fail | The host is not authorized |
| ~ | SoftFail | The host is probably not authorized; a weaker statement than fail, often accepted but marked as suspicious |
| ? | Neutral | The domain makes no statement about this host |
If no mechanism matches and there is no redirect, the result is neutral. That's why most records end with an all mechanism.
~all or -all? Choosing your SPF policyThe qualifier on the final all is your SPF policy for every server you haven't listed:
-all says unlisted servers are not authorized to send for your domain.~all is a weaker statement (softfail): unlisted servers are probably not authorized.+all authorizes every server on the internet. Don't use it.A common practice is to use ~all while you take stock of every service that sends email for you, or while you roll out DMARC, and to switch to -all once every sender is listed. This is advice, not a rule, and both choices are widely used.
Keep in mind that SPF alone doesn't decide what happens to failing mail. Receivers weigh the SPF result with other signals, and your DMARC policy is how you tell them what to do with mail that fails authentication.
Your ESP (Email Service Provider) is asking you to add an SPF record to your domain. You log in to your DNS provider and you see that you have an existing SPF record. Something like this:
v=spf1 include:_spf.google.com -all
This SPF record allows Google Workspace to send emails for your domain. Emails from other hosts should be rejected.
Your ESP asks for the following SPF record:
v=spf1 include:mailgun.org ~all
Should you just overwrite your SPF record with the required content? - No. The record from the ESP only allows emails sent by them. Your emails from Google Workspace would be marked as potential spam (because of ~all).
What you want to do is add the include mechanism to your existing record:
v=spf1 include:_spf.google.com include:mailgun.org -all
This way, your domain allows emails sent by Google Workspace and by your ESP (here Mailgun). The values above are examples: use the exact include your provider gives you.
Don't publish the ESP's record as a second SPF record next to the first one. A domain must have exactly one SPF record. With two, the check returns a permanent error (permerror) and SPF fails for your domain.
Since February 2024, Gmail and Yahoo require authentication from senders. Google counts you as a bulk sender if you send more than 5,000 messages a day to Gmail accounts. As of October 2026, Google's sender guidelines look like this:
| Requirement | All senders | Bulk senders (5,000+ messages/day to Gmail) |
|---|---|---|
| SPF and DKIM | SPF or DKIM | SPF and DKIM |
| DMARC | – | A DMARC record is required; p=none is enough |
| Alignment | – | The From domain must align with the SPF or the DKIM domain |
| One-click unsubscribe | – | Required for marketing and subscribed messages |
| Spam rate | Keep it below 0.30% (aim for under 0.10%) | Keep it below 0.30% (aim for under 0.10%) |
Yahoo's rules for bulk senders follow the same pattern: SPF and DKIM, a DMARC record of at least p=none that passes, alignment (relaxed alignment is fine), one-click unsubscribe and a spam rate under 0.3%.
Meeting these requirements is necessary, but it doesn't guarantee inbox placement. Both providers change their rules from time to time, so check the Google sender guidelines and Yahoo sender best practices for the current version. For background on the 2024 change, read Gmail's new email delivery standards.
If you are a bulk sender, yes: Google and Yahoo require both. Even below that volume, it's worth publishing both. SPF breaks when an email is forwarded, while DKIM usually survives forwarding, so the two cover each other's weak spots.
include, a, mx, ptr, exists and redirect. More than 10 gives a permerror. all, ip4 and ip6 don't count. There is a second limit for "void" lookups, which return no answer: more than two of them can also cause a permerror. Our BIMI guide covers ways to stay under the 10-lookup limit.After changing the record, check your SPF, DKIM and DMARC records free with our domain health checker. Enter your domain to see whether your SPF record is in place, along with your DKIM and DMARC records.
Did you know that you can verify the validity of email addresses without sending an email? Try our Email Validation Service to clean your email lists. You can sign up for free and get 200 free validations.
Start with 200 free validations. Upgrade only when you're ready.
No credit card required • Cancel anytime