Sender Policy Framework (SPF) is an essential email authentication protocol used by domain owners to specify the authorized email servers for sending emails. By implementing SPF, you can significantly reduce the risk of fraudsters spoofing your sender information and protect yourself, your brand, and your customers from phishing attacks.
The Importance of Email Authentication:
Email serves as the starting point for over 90% of cyber attacks. With the evolving email landscape, the dangers of phishing attempts and domain spoofing attacks have increased by 220%. Even experienced marketing teams can fall victim to these sophisticated phishing attacks. Therefore, authenticating your emails becomes crucial to enhance your email security.
How SPF (Sender Policy Framework) Works:
SPF works by adding an SPF record to your Domain Name System (DNS). This record acts as a public list of authorized senders for your domain. When receiving servers receive an email from your domain, they can cross-check if the email originated from a server with permission to send on your domain’s behalf. This verification process helps in identifying and rejecting unauthorized emails.
Example SPF Record:
To illustrate, let’s consider an example. If you use an email API like Postmark for transactional emails and email software like Campaign Monitor for marketing emails, your SPF record may look like this:
v=spf1 a mx include:spf.mtasv.net include:_spf.createsend.com ~all
In this example:
- spf.mtasv.net is Postmark’s record
- spf.createsend.com is Campaign Monitor’s record
By including these authorized senders in your SPF record, receiving servers can verify the legitimacy of emails sent from your domain.
If they aren’t, the receiving server can consider it fake and act accordingly.
Another Example:
Bluehost keeps a list of approved servers and IP addresses in an SPF record which is then included in the default SPF record for each domain in private or shared cloud hosting plans. The default record looks like this:
v=spf1 a mx ptr include:bluehost.com ?all
Similarly, if you use separate IP addresses and subdomains to send promotional and transactional emails (as we recommend), both IPs will be listed as approved sending sources.
Why do I need to add the record to my domain?
Having an SPF system policy gives an extra signal of trust to ISPs so you can increase the likelihood that emails will reach the recipient’s inbox.
Sender Policy Framework won’t solve all delivery issues, but when combined with standards like DKIM and DMARC, it acts as an additional layer that improves delivery rates and prevents abuse.
The Limitations of SPF (Sender Policy Framework):
It’s important to note that SPF alone does not protect the “From” field in an email. As long as an email address is valid, SPF does not provide further validation. This means that anyone can impersonate the business owner or any other person. Additionally, even if a message fails SPF, the final decision on delivery lies with the receiving Internet Service Provider (ISP).
So yeah, the (SPF) Sender Policy Framework system is a neat and simple solution in that it uses existing defensive bits to make it more difficult to impersonate your domain. Furthermore, we are fortunate to have more authenticators at our disposal to protect our brands and recipients from impostors out there.
Enhancing Email Authentication:
In addition to SPF, it is recommended to implement other email authentication measures like DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to strengthen your email security.
- DKIM: DKIM is a security standard designed to ensure that email messages are not altered while in transit between servers. It adds a digital signature to emails, providing a way to verify their integrity.
- DMARC: DMARC builds upon DKIM and SPF to prevent spammers from using your domain to send unauthorized emails. It allows you to specify policies for handling emails that fail authentication checks.
Now that you understand the big picture of SPF, let us look at an Sender Policy Framework policy in action and see how the process works:
Here is a high-level overview of how a mail server checks SPF:
- 1-The server with the IP address 1.2.3.4 sends an email by this domain@example.com as the Return-Path.
- 2- Receiving mail server grabs the Return-Path domain and searches the DNS records for domain example.com for the SPF record
- 3-For example, the receiving server discovered a Sender Policy Framework record. It then checks to see if any of the IP addresses listed as valid senders for the domain match the one it used to send the email.
- 4-The sending IP 1.2.3.4 is the list as an approved sender, so SPF passes. If the IP addresses do not match, that is caused Sender Policy Framework to fail. That may lead to mail rejection.
Evaluation of a Sender Policy Framework (SPF) record (open-spf.org/SPF_Record_Syntax/) can return any of these results you can see in the table below:
| Result | Explanation | Intended action |
| Pass | The SPF record designates the host to be allowed to send | Accept |
| Fail | The SPF record has designated the host as NOT being allowed to send | Reject |
| SoftFail | The SPF record has designated the host as NOT being allowed to send but is in transition | Accept but mark |
| Neutral | The SPF record specifies explicitly that nothing can be said about validity | Accept |
| None | The domain does not have an SPF record or the SPF record does not evaluate to a result | Accept |
| PermError | A permanent error has occured (eg. badly formatted SPF record) | Unspecified |
| TempError | A transient error has occured | Accept or reject |
How does the SPF record syntax work?
Sender Policy Framework records syntax into two parts:
- Syntax – Qualifiers
- Mechanisms – Syntax
To clarify: If you are using Outlook for your email provider, then your SPF records look like this:
v=spf1 include:spf.protection.outlook.com -all
Formatted and illustrated as shown in the figure below:
v=spf1 include:spf.protection.outlook.com-all
v={spf version}{ mechanism}{directive}{qualifier}all
SPF Syntax – Qualifiers
Qualifiers Sender Policy Framework means: are the actions applied when a mechanism matched.
If no qualifier is listed, the default is +.
There are four different types of qualifiers shown in the table below:
v={spf version}{ mechanism}{ directive}{qualifier}all
| Qualifier | Result | Description |
| + | Pass | Default if no qualifier specified accept the message. |
| – | Fail | Recommended option: Server matching IP address id NOT authorized. |
| ~ | Soft Fail | Accept the message but mark it as suspicious |
| ? | Neutral | Neither pass nor fail SPF, Accept. |
Mechanisms and Directives Syntax
Mechanism SPF means: An Sender Policy Framework record is a line of plain text that includes a list of tags and values. The tags are called mechanisms. According to Google Support, the values in an SPF record are typically IP addresses and domain names.
There are five tag mechanisms, or let us say five different ways you can use the domain name as shown in the table:
| Mechanism | Directive Applies When |
| a | Authorize mail severs by domain name |
| mx | Authorize by another domain MX record |
| IP4 | Authorize by IPv4 address or range |
| IP6 | Authorize by IPv6 address or range |
| Include | Authorize 3rd party email senders by domain |
v={spf version}{ mechanism}{ directive}{qualifier}-all
| 1. v=spf1 a: (Authorize mail severs by domain name) -all 2. v=spf1 mx: (Authorize by another domain MX record) -all 3. v=spf1 ip4: (Authorize by IPv4 address) -all 4. v=spf1 ip6: (Authorize by IPv6 address) -all 5. v=spf1 include: (Authorize 3rd party email senderds domain) -all Here the example for authorized third-party email senders such as example Outlook vspf1 include:spf.protection.outlook.com -all |
How to build your SPF (Sender Policy Framework)
However, Simply can to build your SPF record? Follow these five steps:
- Step 1: Collect IP addresses used to send email
Many groups send mail from a variety of places.
One: To implement SPF, you need to check which mail servers you use to send emails from your domain.
Two: Create a list of all your mail servers with their IP addresses, and be sure to consider whether any of the following used to send an email on behalf of your brand:
- Webserver
- Mail server of your email service provider (ESP)
- Office a mail server (Like Microsoft Exchange)
- The mail server of your end users’ mailbox provider
- Any other third-party mail server used to send an email on your brand’s behalf
If you are unsure of your IP addresses, reach your ESP to obtain a list of the addresses associated with your account or your IT System Administrator to compile a list of IP addresses used by your company.
- Step2: build a list of your sending domains.
Your company most likely owns several domain names. Some of these domains worked to send an email. Others aren’t.
On the whole, it’s critical to set up SPF records for all domains you own, even if you’re not mailing from them. Why? After you’ve protected your sending domains with Sender Policy Framework, the first thing a criminal will do is try to spoof your non-sending domains.
- Step3: Build your SPF record.
Sender Policy Framework (SPF) verifies a sender’s identity by comparing the IP address of the sending mail server to the list of authorized IP addresses published by the sender in the DNS record.
Conclusion: About (SPF) Sender Policy Framework
In today’s email landscape, protecting your brand and customers from phishing attacks is paramount. Using SPF, DKIM, and DMARC can greatly improve your email security. By adding an SPF record to your DNS, you can establish a list of authorized senders, making it more difficult for fraudsters to impersonate your domain. Combined with DKIM and DMARC, these authentication protocols provide a robust defense against email-based threats.
It’s important to regularly check and update your email security settings to stay safe from changing dangers. By making email security a priority, you can protect your brand’s reputation and keep your customers’ trust.