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:
You receive an email from [email protected]. 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 there is no SPF record it will accept the email.
In case an SPF record is published, it verifies if the sending server mail.spammer.com is authorized to send emails for the domain example.com.
Let's assume there is such a record that doesn't authorize mail.spammer.com. 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 include:_spf.google.com ~all" - Include rules from _spf.google.com (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 "a:otherdomain.com"
- "mx" - Allow all hosts specified as MX records of the current domain to send emails. Use a different domain by using "mx:otherdomain.com"
- "include" - The specified domain is searched for a match.
All mechanisms can be prefixed with a qualifier to designate
|+||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 include:_spf.google.com -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 include:mailgun.org ~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 include:_spf.google.com include:mailgun.org -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.