The purpose of a Sender Policy Framework (SPF) record 1

I use SPF records for many years. My implementation of SPF records in ISPConfig occurred to me to point out the advantages again.

SPF is an authentication method that is stored in the DNS. This entry specifies which server can send mail for a particular domain.

And why do I need a SPF record?
When sending emails there is initially no way to verify the sender. A spamer can use any of your email addresses to e.g. send phishing emails. For the recipient, it looks as if the email comes from you. The result is that the reputation of the address (or company) decreases.
Here SPF comes into play. The receiver can check when you receive a mail, if the sender is legitimate and process the mail or reject or further highlight the mail. The integration into Postfix was described by me earlier here.

In order to create an SPF record, there are many generators as spfwizard.net or spf-record.de. I decline therefore at this point to the explanation of all parameters. The syntax is published at openspf.org.

However, a possible source of error are the servers that are allowed to send mail. My checklist looks like this:

• web server
• own mail server
• Office mail server (eg Microsoft Exchange)
• mail server of the ISP
• mail server of the ISP that at home using the user
• other mail servers

It just depends on the mail server that sent the last mail to the outside. Intern is only important that each server will not reject the mail because of an incorrect SPF records.

SPF limits the number of permitted lookups to 10. Everything else can be penalized by the recipient. Before a SPF record will be permanently stored in the DNS, it should be checked for possible errors with www.kitterman.com.