Virtual private server

SPF for mail protection

SPF(Sender Policy Framework) – A tool to determine which servers are authorized to send mail on behalf of our domain. That is, the entry for the example.com domain will specify what to do with messages from any @example.com person. It allows you to reject the message or just flag it and notify you of any attempt to impersonate that domain.

SPF check

A simple rule to check SPF is to query the DNS server for the domain txt record of the email address (e.g. info@roan24.pl is the domain roan24.pl). So „dig roan24.pl txt” will return us: „v=spf1 a mx ip4:178.33.3.224 -all” that is, the domain has a spf version 1 entry (v=spf1), and from the given domain it can send mail only from ip addresses that are in the A (a), MX (mx) entry, or has an ip version 4 178.33.3.224 (ip4:178.33.3.224). As for the a and mx entries how they work you can read in our DNS basics article.
Then all that remains is to check what to do with the message, i.e. the „all” entry, most often used is „~all” which means accept but mark for fraud, or „-all” if the sending server is not on the SPF list then reject the message without further checking.

How to introduce SPF

A detailed description of the entire syntax can be found on the openspf website, but in English. But I will describe here, I hope clearly, what syntax to use to enter SPF on our domain.
So yes we will always use v=spf1 at the beginning as I will describe version one of spf here (no version two yet). So we have an entry:
v=spf1
This entry doesn’t tell us anything yet, let’s add an all tag to it – it means how we should treat the message we are checking spf. And so we can prefix it with four characters „+” meaning it’s ok, „-” meaning it didn’t pass, „~” that it’s suspicious, „?” neutral.
And so if the entry looks „+all” and the sending host is not on the list then we are supposed to accept such a message.
If it is „~all” and the host is not on the list we are supposed to accept the message but mark it as a spf error, or suspected of being spam.
If we have „-all”, my recommended means that if the server is not in the list then the message from it should be rejected.
The „?all” entry means that basically nothing has happened whether it is there or not – in short, there might not have been an entry.
I recommend using either „~all” if your addresses change frequently and you may have trouble typing them all in, or „-all” if you know your server addresses exactly and they don’t change too often.
v=spf1 -all
With a start and end, we will now enter the ip addresses or entries (in the middle of the entry) into our list.
A – means that the server in entry a may send mail. ATTENTION If we use some proxy or cdn (e.g. cloudflare) we should not enter this because our mail server should not be authorized to send mail on our behalf.
MX – server from MX address can send mail, usually this is correctly entered, it should be noted here that if you change the server address in the MX entry you no longer need to change the SPF entry, which makes things easier, sometimes it may happen that we use a gateway to receive mail and this entry should not be used.
ip4 – that is, one ip address or ip/mask address (e.g. 192.168.0.0/24 is – 192.168.0.0 to 192.168.0.255) means the specific ip addresses of version four that are authorized to send mail.
ip6 – on the same principle as ip4 addresses, but it concerns only version 6 addresses.
There are also additional entries like „include” and „redirect”, include appends entries from the given domain (by searching the txt) and redirect redirects to another domain where we can find SPF guidelines in the txt entry.
Also creating a SPF entry is not difficult even for larger mail providers and is recommended, just remember that you need to update it when you change the mail server ip address and it is not added by MX. For small domains, we recommend using short entries with only the mx entry added, for example. for all our clients is enough:
v=spf1 mx ip4:178.33.3.224 -all

Summary

SPF isn’t ideal for securing our mail, but it’s easy enough to implement and, when formatted properly, can greatly reduce phishing related to impersonating our email domain.

Platforma zarządzania zgodami od Real Cookie Banner