Setting a Sender Policy Framework (SPF) record
Setting correct SPF records for your domain's mail server can help in reducing spammers using your domain for nefarious purposes!
Spam. No one likes it. No one wants it. No one needs it. However, it is there and is likely to be there for the foreseeable future.
All we can do as responsible mail server administrators is to ensure we are not part of the problem by not running an open relay and locking down our services as much as possible.
One tool that can help our legitimate email not being classed as spam is to set a Sender Policy Framework (SPF) record in our domain's DNS zone.
Sender Policy Framework
A SPF record is a DNS TXT record and is added to our DNS zone in the same manner that A records and MX records are added.
I started the article with a commentary regarding spam email. A common method spammers use is to forge the sender address in the email. Thus, they send email from their mail servers but with your domain as the sending email.
The SPF record (remember the record is associated with the domain) specifies which mail server(s) the domain uses to send mail.
It does require the server receiving your mail to check the SPF record to ensure it complies with the domain records but the majority of public mail servers (such as your ISPs mail servers, google mail and so on) will do so.
Having said, that I do not guarantee every ISP complies with the SPF policy or, even if they do, that they do so correctly.
If the receiving server complies with the SPF policy correctly, and the sent email does not conform to your domain records (i.e. comes from an unknown server), it will be marked as fake and either deleted or marked as spam.
One thing to note is that the SPF record allows mail to be quickly assessed by compliant recipients as the checks are completed from information in the header of the email. That is, before the body of the message is loaded. This saves a great deal of time and resources if the mail is a forgery.
To correctly set the SPF for your domain you need to think about a few things such as:
From what server(s) will mail from the domain originate. The answer may not be as simple as 'from my Cloud Server, of course!'. If you are sending mail from your workstation via your ISP's mail servers, you may want to consider their servers.
Perhaps you use Google Apps for their mail services.
All possible (legitimate) sending servers need to be taken into account.
How do want non-legitimate mail to be handled? Do you want them to be rejected out of hand with no questions asked, or do you perhaps want the message to be classed as a 'soft fail', meaning the email will be subjected to further scrutiny.
Let's say we have listed the following as details for our mail on democloud.com.
The Cloud Server itself (i.e. the incoming MX details also send mail).
We also want to ensure that no other mail servers are authorised.
The TXT record would look like this:
v=spf1 mx include:_spf.google.com -all
Let's go through each one:
This sets the SPF version being used
Allows the domain's MXers to send mail
Included in our list of authorised sending servers are the google mail servers
Any servers not listed previously as NOT authorised. This will produce a fail and action will be taken according to the receiving mail server's own policy (i.e. delete it or mark it as spam, etc).
The 'all' setting
The final setting shown above - the 'all' setting - is an important aspect of the record and has 3 basic markers:
As already explained, this means that any server not previously listed is not authorised - no questions asked.
If mail is received from a server not previously listed, mark it as a 'soft fail' - this allows the mail to be scrutinised further.
Allow any server, anywhere to send mail from my domain. Naturally, this is a very silly setting and should never even be considered.
Setting Your SPF Settings
So, back to democloud.com.
I have given it some thought and I know that all I need is to send mail from this Cloud Server. I won't be sending mail via Google or via my ISP.
I also want to ensure that no other mail servers are authorised.
As such, my SPF record is going to be quite simple:
v=spf1 mx -all
It is a sparse record but suits the needs of this Cloud Server perfectly.
Naturally, you will want to consider all options for your Cloud Server needs. Perhaps an '~all' may be better for your domain.
Do give it some thought and plan carefully what your mail needs are for the domain.
Adding the Record
So now we have the record we want to use, we can go ahead and add it to the DNS zone.
Please create the SPF record as a TXT record in the DNS Control Panel. Access the DNS Control Panel for the domain you wish to modify. You'll need set the text of the SPF record, as well as the record name and TTL value.
There is a huge amount of data on the Sender Policy Framework and I highly recommend reading more on the subject to get the most from this policy and to reduce the chances of your domain being used by spammers.
A good site for this research is Sender Policy Framework Project Overview.
Setting an SPF record for your domain can help in reducing the chances of a spammer using your domain name in unsolicited emails.
Research carefully what mail servers your domain is likely to use and plan how you want any non-authorised email to be handled.
- Postfix - Installation -- Go here to set up your Cloud Server for basic mail delivery needed by web applications.
- Mail Server - Overview -- Go here to set up your Cloud Server as a fully-featured mail server.
© 2014 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
See license specifics and DISCLAIMER