in

Email – setting a Sender Policy Framework (SPF) record

Email - setting a Sender Policy Framework (SPF) record

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.

Not good.

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.

Setting SPF

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 Slice 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.

Example

Let’s say we have listed the following as details for our mail on demoslice.com.

The Slice itself (i.e. the incoming MX details also send mail).

Google mail.

We also want to ensure that no other mail servers are authorised.

The TXT record would look like this:

v=spf1 mx include:aspmx.googlemail.com -all

Let’s go through each one:

v=spf1

This sets the SPF version being used

mx

Allows the domain’s MXers to send mail

include:aspmx.googlemail.com

Included in our list of authorised sending servers are the google mail servers

-all

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:

-all

As already explained, this means that any server not previously listed is not authorised – no questions asked.

~all

If mail is received from a server not previously listed, mark it as a ‘soft fail’ – this allows the mail to be scrutinised further.

+all

Allow any server, anywhere to send mail from my domain. Naturally, this is a very silly setting and should never even be considered.

demoslice.com

So, back to my domain.

I have given it some thought and I know that all I need is to send mail from this Slice. 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 Slice perfectly.

Naturally, you will want to consider all options for your Slice 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.

Log into the DNS Manager.

Select the DNS tab and then the ‘records’ link for your domain.

Click new record.

Select TXT from the drop down and enter the details as shown in the example here:

Email - setting a Sender Policy Framework (SPF) record

So that gives us the record for the demoslice.com domain.

More information

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 is http://www.openspf.org/.

Summary

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.

PickledOnion @ SliceHost

What do you think?

10 Points
Upvote Downvote

Leave a Reply

Your email address will not be published. Required fields are marked *

Umask and unusual file permissions and types

Umask and unusual file permissions and types

Postfix - basic settings in main.cf

Postfix – basic settings in main.cf