All mail server administrators will have encountered the following problem: spammers send out spam and they spoof the mails so that the sender appears to be a user in the domain you are managing. Unfortunately there is not a lot that can be done to prevent spammers from sending such these spam mail. There is however a way in which receiving mail servers can check whether the mail was send from your mail server or whether is was a spammer who used a mail server that is not authorized to send mails from your domain. This can be accomplished with SPF (Sender Policy Framework).
SPF requires that you make a change to the DNS configuration of your domain name. By adding a record for SPF, you define which servers are authorized to send email from your domain.
Email servers that receive an email from your domain will request the SPF settings from your DNS server. If the mail server that has sent the email is listed in the SPF settings, then the email will be accepted and delivered by the email server. If the mail server is not listed, then the email is rejected.
Sender verification process using SPF
This process goes as follows:
-
As a mail administrator from domain example.com, you create a DNS TXT record that contains the SPF configuration. The SPF configuration defines that the server with hostname mx.example.com is authorized to send emails from the example.com domain.
-
A spammer sends out a mail to [email protected]. He spoofs the sender address so that the email appears to come from [email protected]. The spammer sends his emails using his own mail server mx.spammy.com.
-
The mail server processing the mails of the business.com domain receives the email from the spammer. The mail server extracts the domain of the sender, being example.com.
-
The mail server requests the SPF settings for the example.com domain. The SPF settings tell the mail server that only mx.example.com may send emails for the example.com domain.
-
The mail server extracts the details of the sending mail server from the email. This is mx.spammy.com.
-
The mail server concludes that mx.spammy.com is not equal to mx.example.com so the email has been sent from an unauthorized mail server. Hence the business.com mail server drops the spammer’s mail.
Before enabling SPF for my domains, it happened frequently that I received backscatter: out-of-office emails or “message undeliverable”-email from all over the world since spammers abused my domain to send spam. Since I have enabled SPF, this has been reduced immensely.
SPF and cloud-based applications
A word of caution however: if you enable SPF, make sure that you list all servers that could possible send emails on behalf of your domain. Think about web applications that might directly send emails, or a cloud-based CRM.
Many cloud-based solutions have support pages available that help you with defining SPF records. For example:
-
If you use Salesforce, then chances are big that Salesforce will be sending emails on behalf of you domain. To allow this, you should add include:_spf.salesforce.com to your SPF record (see https://help.salesforce.com/apex/HTViewSolution?id=000006347).
-
If you use Google Apps, then you should add include:_spf.google.com to your record (see https://support.google.com/a/answer/178723?hl=en)
To test if a domain has an SPF record or to validate if the syntax is correct: http://www.kitterman.com/spf/validate.html
References
- Understand SPF records: https://support.google.com/a/answer/33786?hl=en
- Create SPF records for Google Apps: https://support.google.com/a/answer/178723?hl=en
- Add Salesforce to your SPF record: https://help.salesforce.com/apex/HTViewSolution?id=000006347
- SPF record testing tools: http://www.kitterman.com/spf/validate.html