Sender Policy Framework (SPF) Explained

The Sender Policy Framework (SPF) is a procedure to prevent the forgery of email addresses. In other words, it allows email receivers to verify if the sender is allowed to send emails from your domain. To protect a domain, the domain owner publishes a list of authorized email systems via his DNS system.

To understand the benefit of SPF, imagine the following scenario:

Email rejection caused by SPF mismatch

You receive an email from The email was sent from a server named

When receiving the email, your provider looks up the SPF record published at The SPF record is optional. If there is no SPF record it will accept the email.

In case an SPF record is published, it verifies if the sending server is authorized to send emails for the domain

Let's assume there is such a record that doesn't authorize Depending on the SPF settings, the email will be rejected or marked as possible spam.

The recipient gets a warning, that the email might be spam and is not from the sender it claims to be.

Having a correct SPF setup is important to get your emails to your recipient's inbox. You can read more about this in our article 8 Actionable Steps to Improve Email Deliverability, which contains more insights about email deliverability.

Anatomy of an SPF record

Let's look at examples of SPF records to understand how they work:

  • "v=spf1 mx -all" - Allow domain's MXes to send mail from the domain, prohibit all others
  • "v=spf1 a ~all" - Allow all A records of the domain to send emails, mark all others as possible spam
  • "v=spf1 ~all" - Include rules from (to allow sending emails from Google Workplace) and mark all others as possible spam

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:

  • "all" - This always matches. It is usually used at the end of the SPF record to handle the rest.
  • "ip4" and "ip6" - Specify an IPv4 or IPv6 network range.
  • "a" - Allow all hosts specified as A records of the current domain to send emails. You can also use another domain by using ""
  • "mx" - Allow all hosts specified as MX records of the current domain to send emails. Use a different domain by using ""
  • "include" - The specified domain is searched for a match.

All mechanisms can be prefixed with a qualifier to designate

Qualifier Result Explanation
+ Pass accept, allowed host (default if not specified)
- Fail reject, host not allowed
~ SoftFail accept email but mark as possible spam
? Neutral accept, nothing can be said about the validity

Add a new mechanism to an existing SPF record

Your ESP (Email Service Provider) is asking you to add an SPF record to your domain. You log in to your Nameservice provider and you see that you have an existing SPF record. Something like this:

v=spf1 -all

This SPF allows Google Workplace to send emails for your domain. Emails from other hosts should be rejected.

Your ESP asks for the following SPF record:

v=spf1 ~all

Should you just overwrite your SPF record with the required content? - No. The record from the ESP allows emails send by them. Your emails from Google Workplace 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 -all

This way, your domain allows emails sent by Gmail and from your ESP (here Mailgun).

Did you know, that you can verify the validity of email addresses without sending an email? - Try out our Email Validation Service to clean your email lists. You can Sign Up for free and get 100 credits.

Additional Resources

Ready to dive in?Start your free trial today.