What is SPF protection and how does it work?

We assume that you already have a hosting with a cPanel management panel

If you are faced with choosing a proven hosting, compare our packages. All descriptions in this guide are based on Smarthost.au hosting

Due to the wave of spam that is flooding us, currently virtually all servers on the Internet use mechanisms that authorize e-mails. This consists in proving that the e-mail sent from the address contact@client-domain.au is actually sent from the server servicing the domain: client-domain.au and not from any other server. Thanks to this, we are sure that the e-mail does not have a forged sender.

Of course, the whole thing goes unnoticed by an ordinary mail user, at the level of a properly configured mail server.

A mechanism that can be used (and increasingly common) is SPF (Sender Policy Framework). This mechanism, in the simplest terms, consists in adding an Internet domain in the configuration file (dns zone) list of IP addresses that are authorized to send mail from a specific domain. When we send mail (e.g. from the address: contact@client-domain.au), the server receiving the message checks which IP addresses are authorized to send mail for the domain @domain-client.au and if the sender’s address matches the sending address IP – accepts mail, and if the IP address is different – the mail is rejected or marked as suspicious (e.g. it receives the so-called negative points on the basis of which the mail is classified as spam).

The SPF mechanism itself is simple and effective. It is implemented on many servers (including, of course, our servers for all smarthost.au customers). This mechanism is so popular that some portals offering free e-mail accounts have decided to reject e-mail with incorrect SFP records.

Why is there a problem with the SPF record for forwards?

Sometimes it happens that apart from sending mail from server A to server B, we want it to be forwarded from the target server, e.g. to server C. For this purpose, we create forward, i.e. the service of “forwarding mail“. It can be clicked very easily in virtually every hosting panel.

There were no problems with forwards until SPF protection was introduced.

Why?

The answer is relatively simple:

• By sending an email from server A (e.g. from contact@client-domain.au to server A, that has SPF settings correctly configured for that domain) it arrives at server B.
• Server B checks if server A is authorized to send mail from the domain @client-domain.au
• Since SPF on server A is configured correctly, server B receives confirmation that it can accept mail.
• However server B is set to redirect to server C, so server B forwards the mail.
• Server C receiving mail from the address contact@client-domain.au, checks whether the SPF on server B is configured for this domain: @customer-domain.au. And here comes the problem, because server B is not authorized to send mail from this domain. Server A is authorized, but server C only contacts server B, from which it receives mail. And then server C treats server B as impersonating serwer A (so-called spoofing) and … rejects the mail.

Of course, this behavior of the server C is technically correct (it checks the SPF settings of the server from which it receives mail), but it is incorrect from the point of view of the user who wants to receive this e-mail (because he set the forwarding himself).

SPF solution for forwards: SRS

The creators of the SPF did not initially provide for SPF authorization for forwards. It did not appear until about two years after the initial outlines of the SPF specification were created. The mechanism securing the correct receipt of e-mails that are forwarded is called SRS (Sender Rewriting Scheme). This mechanism is currently available for most mail servers, but not every mail server is configured to use this mechanism.

How does it work?

The SRS mechanism works relatively simply: server B (the one that forwards) modifies the sender’s header (sender envelope), adding to it information that the address of the original sender, i.e. server A, has been checked by him in terms of SPF and is a legal sender for the domain @client-domain.au.

So server C  instead of sender: sent by server B, will see sender: contact@domain-client.au with additions . They mean:

SRS0 – that it is the first server that forwards the e-mail (in the case of subsequent sends, it would be SRS1, SRS2, etc.)

nLCQK – a unique string (different each time), known as a hash, to prevent spammers from spoofing forwarded emails.

RA – unique timestamp (different each time), i.e. a timestamp that makes the forwarded address valid only for a certain period of time.

Thanks to the use of the SRS mechanism, e-mail forwards do not break the SPF authorization for domains. Of course, the whole thing happens automatically, in the background, without the need to perform any special actions when sending e-mails by the user.

SRS for SPF is enabled on all smarthost.au servers – to check how it works, the easiest way is to set up a free hosting account and set up mail redirection to another server.

smarthost.au

Create a free test account on the Smarthost.au server and check how a correctly configured SRS mechanism for SPF for e-mail forwards works: create a test account, gold-ssd package