Wednesday, 14 May 2014 09:03

Business Email: SPF and DKIM; what are they and do I need them?

Written by  Tony Ravenhill
Rate this item
(2 votes)

A friend who runs his own business with an in house mail server asked me a question about SPF and DKIM the other day. He was under the impression it was something that he needed to address in order to legitimise his business email, but he knew little about what they actually are or how they were implemented and the consequences of not using them. Coincidentally I’d recently tackled this issue myself and so I decided to jot down a few notes that may save others a little time investigating the subject.

Firstly it is worth checking whether or not you already have them implemented. A quick test is to send an email to This email address is being protected from spambots. You need JavaScript enabled to view it. which will send you a report, letting you know whether DKIM and SPF are working for your domain. Note: It will also verify ‘Domain Keys’ as well as DKIM. DKIM is a standard, in part based on Domain Keys, whereas Domain Keys was originally developed by Yahoo and is now effectively obsolete, although it is still supported by some email service providers. You shouldn’t worry about not implementing Domain Keys, in fact many MTA’s (email servers) will not support it.

SPF

As you’ll probably know a spammer can send emails from any address that he chooses. That email address, may be, and probably is on occasion, yours. SPF (Sender Policy Framework) records are designed to combat spam by verifying that email for a particular domain has originated from a legitimate source, i.e. your own mail servers.

SPF is implemented using DNS TXT records. A dedicated SPF record type was created for this purpose but it is current practice to use TXT records, although it is often recommended to use both record types if possible.

So how does it work? When your mail is received by a remote MTA it will look up the SPF record for the domain in the email’s return path (also known as the envelope or bounce address). The return path is the email address specified in the SMTP ‘MAIL FROM’ command.  The SPF record specifies a list of legitimate sources (addresses of mail servers) for the domain along with instructions on what to do should the email’s origin match, or not match, the addresses specified in the record. Common instructions (known as qualifiers) are PASS (default), FAIL and NEUTRAL. The first two are self-explanatory; however NEUTRAL allows you to specify that you don’t have a policy for that address. Once a result has been obtained the remote MTA will have an idea that your mail came from a valid source and can decide whether it will accept it or not.

For example, my SPF records specify that emails originating from servers specified in my MX records should pass, from other servers on my network should be neutral and from anywhere else should fail. The first part of the record specifies the version of SPF (v=spf1) and is followed by a list of qualifiers and ‘mechanisms’ (basically the source addresses and their type). The plus ‘+’ qualifier denotes PASS, ‘-‘ denotes fail and ‘?’ denotes neutral. The ‘mx’ mechanism represents all servers listed in my MX records, the ‘ip4’ mechanisms specify my network’s public IP addresses (although I have used private addresses here for illustrative purposes). The ‘all’ mechanism represents everything else not matched elsewhere.

v=spf1 +mx ?ip4:192.168.70.1/25 ?ip4:172.17.0.0/16 -all

A full description of the structure of an SPF record is beyond the scope of this blog, but there are many tutorials on the web that will help you to construct yours.

DKIM

DKIM (Domain Keys Identified Mail) is another mechanism for proving that your email originated from where it claims to be from. To do this your MTA signs your outgoing mail by adding a header containing an encrypted hash of certain other header fields such as addresses in ‘from’ fields (which are distinct and may be different from the envelope address specified during an SMTP session). The remote MTA downloads a key via a DNS TXT record and decrypts the hash. It then re-generates the hash and compares it to the decrypted hash. If they are the same then the recipient can be fairly certain that the email originated from a legitimate MTA for the domain and that the headers have not been tampered with or forged.  As SPF cares only about the domain in the envelope address and DKIM verifies addresses in from fields, DKIM complements SPF rather than being an alternative to it.

Unlike SPF, DKIM must be configured on your MTA, so that your mail can be signed as well as in DNS. Implementation will vary depending on your MTA. I use Exim on which it was quite a straight forward task. Make sure you use a minimum of 1024 bit keys as 512-bit keys have been compromised and the cracking of 768-bit keys is not beyond the realms of possibility with access to enough computing power. Further details on implementation are again beyond the scope of this blog but again there are many tutorials out on the web.

So do I need them? …

It is not compulsory to implement SPF and DKIM. Neither of them guarantees that your mail isn’t spam to third parties as the bad guys can use it too for their own domains or hijack user accounts in your domain, but they do go some way to verifying that the mail originates from a valid location (SPF) and from one of your MTAs (DKIM). This is useful for whitelisting, i.e. if an organisation has received legitimate mail from you previously, then subsequent mail validated by DKIM and SPF have a very good chance of also being valid. Usage could also discourage spammers and phishers from forging your addresses as they know there’s a good chance spam filters will reject their mail as invalid.

Not many organisations will reject your mail if it doesn’t implement DKIM and SPF, however, this may not be the case forever and in the meantime, while they don’t beyond all doubt prove you’re not a spammer, they do generally add to the credibility of your mail.

You should also be aware that they aren’t for everybody and don’t work in every situation, for example if you need to send email using your domains from outside your organisation DKIM headers won’t be added and the envelope address may not be from your domain. DKIM can also be broken by mailing lists, however implementing SPF too can provide a way for the list owner to mitigate this. SPF can also be broken in certain scenarios where third parties have to forward your email on to its destination, especially if you use the FAIL qualifier as the mail can appear to originate from sources not specified in your SPF records.

So in conclusion, whether or not you implement is up to you, but if your current procedures permit its use it definitely won’t do the reputation of your email any harm. If you’d like to know more, contact us at the Agile Office project. If you’re eligible, we may be able to help.

 


 

Read 3784 times Last modified on Monday, 22 December 2014 11:07
Tweet

The Agile Office Project is part-funded by the European Regional Development Fund

erdf