SPF protects the integrity of your emails
Spoofed e-mails, i.e. forging the sender address to the exact character, leave the recipient no possibility of detecting the forgery. The sender policy framework (SPF) allows you to define which servers are authorized to send emails from your domain. The aim is to reduce the risk of spam and phishing e-mails.
One of the most important internet services is the DNS (Domain Name System). It answers requests for name resolution: if a user sends the domain it-seal.de as a request to the Internet, the DNS converts it into the corresponding IP address. In this way, the user can be guided to the right server and retrieve the desired content. The Domain Name System was designed in 1983 and is now a directory service distributed on thousands of servers worldwide.
The Sender Policy Framework (SPF) is a project founded in 2003 by a group of volunteers. It describes a procedure to prevent the sender address of an email from being falsified. Without this precaution, the sender address of an email can be forged as easily as that of a letter. By setting an SPF record, the domain holder defines which servers are authorized to send emails for this domain. The incoming mail server checks all incoming emails. Emails that come from a specific sender domain but were sent by a server that is not authorized to do so are then sorted out.
What SPF can and cannot do
The effectiveness of SPF as protection against phishing is controversially discussed: SPF gives the recipient the certainty that the e-mail actually originates from the displayed sender. Thus, SPF only offers protection against e-mail spoofing, i.e. forgery of the sender address to the exact character ("@it-seal.de"). If an attacker uses a similar sender domain ("@it-sea1.de"), SPF cannot help either. Often, email programs only display the name of the sender (e.g. "Max Mustermann"), and the email address (e.g. "email@example.com") is revealed only after a further click. Therefore, despite all technical protection mechanisms, it is important that the recipient manually checks whether the email address is actually genuine - speaking fo phishing awareness.
What does an SPF entry look like?
You can set your own SPF settings in your domain provider's customer menu. One possibility to check your SPF entry is the website https://mxtoolbox.com/spf.aspx:
Configurating your SPF record:
An SPF entry consists of various components, as we can see from the example of it-seal.de:
v=spf1 include: mx.ovh.com include: dnsexit.com –all
The first part, v=spf1, sets the SPF record and defines which version is to be used. The domains listed behind include and the IP addresses associated with them are authorized to send emails. The entry can be configured with +all, ~all or –all: While +all allows all emails to pass, i.e. equals no SPF record, the incoming mail server for –all strictly rejects all emails with the sender address @it-seal.de, if the sending server is not listed in include.
To get started, ~all is recommended, which corresponds to a softfail: All emails are put through, but are marked as not SPF-compliant if they come from an unregistered server. This facilitates marking e-mails as spam, depending on the recipient's filter settings.
Since certain configurations can cause technical difficulties, e.g. when forwarding emails, ~all offers the possibility to test SPF for your own system and later switch to –all. Domains that are not intended for sending emails can be completely blocked by using an SPF record with -all.
Enhancing the safety concept: DMARC
For an extended security concept it is worth taking a look at DMARC: Based on the SPF record, further security settings can be defined here, e.g. how to deal with SPF-unauthorized emails (reporting, quarantine or rejection). DMARC also offers the sender the possibility to be informed if their domain is abused for spam or phishing.