What is SPF? Configuration, verification and monitoring.

This article is primarily for those who want to know what is behind the three letters "SPF". In the world of deliverability, it is often talked about but unfortunately few people really know SPF. We will try to explain in a few lines what SPF is, what it is used for, how it works, how it is set up and how to check that it is properly set up on a domain (and allow you to become the new star of the company) !

Definition

SPF (or more commonly "Sender Policy Framework") is an email authentication standard. It allows you to define which servers are authorized to send emails for your domain name. The SPF is configured by adding a TXT record (text record that allows to relay information to third parties like SPF, Google code...) to your domain (or sub-domain) in your DNS server. SPF will allow you to protect your domain name against spam and phishing

Definition of SPF

Why implement SPF on ALL your domains!

There is only one good reason why you should protect all your domains and subdomains: they are ALL vulnerable! A domain (or sub-domain) unprotected can be used by anyone, anytime, anywhere. By adding SPF to each of your domains and sub-domains, you guarantee a minimum of security (even more if you add a high level of security behind it).

Don't think that you are safe because you are a freelancer, a startup, an SME... Spam and phishing don't spare anyone!

How does SPF work in practice?

Its operation is quite simple. When the ISP receives the e-mail, it will check the DNS servers of the sending domain (by checking the SPF record) if the sending IP is well declared in this famous TXT record.

• If this is the case, the e-mail will pass the validation (and will be confronted with other spam filter checks).
• If this is not the case, the ISP will apply the security rule defined by the domain administrator (this can range from refusal of the e-mail to no action and therefore it is the ISP that will decide where to place the e-mail).

Last point, the SPF record is only valid on the domain where it is implemented. So, don't hesitate to deploy it on all your domains (or sub-domains).

Go go go, let's go to the settings...

Let's try to keep it simple but concise! To implement SPF, you will need :

1. List all mechanisms used

This is the most important part since you will have to list all the mechanisms you use via your routings. Be careful not to forget a mechanism because if you switch SPF to "strict" mode - which I will invite you to do in a future article - the Anti-Spam filters will refuse your emails (so no joke).

Many mechanisms are available and to choose from the list below (obsolete or very rarely used mechanisms are not present) :

• IP4 : defines all used IPs in IPv4 format
  • Ex: 123.45.67.89
• IP6 : defines all IPs used in IPv6 format
  • Ex: 2001:0620:0000:0000:0211:24FF:FE80:C12C
• a defines the A record of the domain (see association of a domain with an IP).
• mx defines the MX record of the domain (this one can contain one or more domains).
• include defines SPF records from external sources (like e-mail routers).
  • Ex: google.com (contains all IPs used and owned by Google).
• all Defines the rule to be applied with the qualifier. It is an essential element.
  • Ex: -all (Strict mode) - if the IP does not match, the message will be refused.

2. Define a qualifier

The mechanism all must be associated with one and only one qualifier. This will define the rule to be applied when SPF is checked by the Anti-Spam filter.

• ~ : Slight failure (softFail) - if SPF fails, the email will be accepted but should be considered suspicious.
• - : Failure (Fail) - in case of SPF failure, the e-mail must be rejected.
• + Valid (Pass) - the email must be accepted
• ? : Neutral (Neutral - None) - no impact on the SPF audit.

3. Add the code on the domain and its subdomains

Once your code is ready, all you have to do - if you have the access rights to your hosting company managing your domain name - is to create a TXT record (since 2014, SPF is only reported via a TXT record) and copy/paste your code.

If you do not have access rights, you will have to go through your ISD.

What if we unpacked the SPF record of Badsender?

Here is what we have stated in our Badsender.com domain:

v=spf1 a mx include:spf.mailjet.com include:sendgrid.net include:spf.protection.outlook.com ~all

• v = here we define the version of SPF.
• a = we include the ip associated with the domain name badsender.com, which is 69.163.144.152
• mx = here we include all the mail servers associated with the domain badsender.com, here we have the domain badsender-com.mail.protection.outlook.com.
• Include:spf.mailjet.com = we include all IPs belonging to the Mailjet router.
• Include:sendgrid.net = we include all the IPs belonging to the Sendgrid router.
• Include:spf.protection.outlook.net = we include all IPs belonging to Microsoft.
• ~all = we use for the moment the qualifier "tilde". (SoftFail mode). Eventually, we will switch to "Strict" mode with the "minus" to secure our domain name as much as possible, but we have to make sure that all IPs are well declared.

How to check if SPF is correctly set up!

There are several well-designed online tools that can check in seconds if your domain has an SPF record and if it is properly configured. Personally, I use 2 tools: Dmarcanalyzer and Mxtoolbox. Let's take the example of Badsender.com at Dmarcanalyzer :

And here is the result:

Note that the SPF record is valid. Another example with the domain "boulanger.com" at Mxtoolbox :

On the other hand, there is an error in the declaration of SPF, Mxtoolbox gives you details on the error (they are cool) :

Don't hesitate to test with both tools with your domain name.

How to monitor SPF...

Unfortunately, you will not be able to monitor SPF directly (even via external tools) so there's no way to know if someone is trying to steal your domain name.

However, there is an indirect way via DMARC (Domain-based Message Authentication, Reporting and Conformance - please see the article I wrote in 2017). Thanks to the reports sent by ISPs/Webmails checking DMARC, you have the possibility to know which IPs have been used with your domain and potentially detect if you are (or have been) victim of phishing (or if you have forgotten any IPs in your SPF declaration).

Shall we conclude?

If you are reading these last lines, it is because this article has finally interested you and perhaps even served to bring to your management's attention certain problems or inconsistencies related to the management of your domain. The objective is not to have you take the place of the system administrator but to have you be able to analyze (and correct?) a problem related to a email authentication (which can degrade your reputation and campaign performance very quickly).

Feel free to comment the article if you have any questions or needs related to email authenticationwe can help you. You can also read our latest articles on email authentication:

• DMARC usage in CAC40 companies in July 2020
• BIMI is good, eat it!
• Deliverability: SPF, DKIM, DMARC... What you need to know about email authentication