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 forgery of the sender address of an e-mail. Without this precaution, the sender address of an e-mail can be forged as easily as that of a letter. By setting an SPF record, the owner of a domain enters in a DNS record which servers are authorized to send e-mails for this domain. During the automated check by the incoming mail server, e-mails are then sorted out that come from a specific sender domain but were sent by a server that has no authorization for this.
Where SPF protects integrity – and where it doesn’t
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 „m.mustermann@it-sea1.de“) 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 entry:
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, offers ~all offers the possibility to test SPF for your own system and later switch to –all umzustellen. . Domains that are not intended for sending emails can be completely blocked by using an SPF record with -all.
Enhancing the security 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.
