Keep emails out of spam bins

A common problem some clients experience is making sure that they keep emails out of spam bins when they send them to their customers, and make sure they end up in their inboxes instead.

This post contains a few suggestions on how best to go about this - they are in a specific order, so the further down the list, the harder they are to implement, but the greater the weight that they have. They're all cumulative, so the greatest benefit will be obtained from implementing them all, but each will make a difference on its own.

Content

It's key that your emails aren't perceived by spam filters as being spammy, and the content of them is key to ensuring this. Be sure to keep a high ratio of your text to your images - at least two lines of text for every image seems to be the recommended ratio - and never ever send image only emails as they wave a big 'spam' flag.

There are a number of locations which have a list of 'high-risk' words - ones like 'amazing', 'click here', 'Dear friend' (when has anyone other than a Nigerian s. 419 scammer ever used that one!), and so on - which are to be avoided if at all possible. Hubspot has a good run down of them.

Blacklisting

It's not inconceivable that you've inherited an IP address for your server that has previously been used for some less than palatable behaviour, so it's worth checking that it's not been blacklisted. There are a number of free tools on the web for doing so, including this one - pop in your IP address and it'll check the major blacklists to see if it features. If it does, it'll have instructions on how to get your server off the blacklist.

Spam checker

Before you send an email, consider testing it with a spam checker to see how your email scores with commonly-used spam checking tools. Mailingcheck has a tool that can be downloaded (on Windows) which checks your email using the same filters used by SpamAssassin (the most wide-spread Linux-based spam filter) and will return the score that it would receive, giving you pointers on where you can improve the content to improve the likelihood that it's not sent to the spam bin.

SPF

Sender Policy Framework is, put simply, a list which specifies which domains are allowed to send emails on behalf of a specific domain (example.com). So that it is easily accessible, the list is maintained as a DNS record for example.com.

When a customer's email client (Outlook, Gmail, Mac Mail, or whatever it may be) receives an email from someone@example.com, it can then look at the DNS record for example.com and see if the server from which the email has come (which may or may not be the same server as example.com itself) is in the list of permitted senders. If it is, it can give the email more weight as being valid and not spam - if it's isn't, then depending on the way the SPF record has been set up, it can either not give it any more or less weight, or it can consider it spam.

Take the SPF record for hummingbirduk.com - it looks like this :

v=spf1 ip4:95.138.174.52 ip6:2a00:1a48:7805:113:96a0:bc15:ff08:3fe5 include:_spf.google.com include:servers.mcsv.net -all

Breaking it down, the sections work as follows :

v=spf1

This just tells you that this TXT entry in our DNS is an SPF record.

ip4:95.138.163.73

This says that if the email comes from a server whose IP address (v4) is 95.138.163.73, then it's a legitimate email.

ip6:2a00:1a48:7805:113:96a0:bc15:ff08:3fe5

This does the same as the preceding entry, but covers off our IPv6 address.

include:_spf.google.com

We (like many other people) use Google Apps, which means that emails we send may well not come from our server's IP address, but instead will come from Google's servers IP address. Rather than having to list all those possible IP addresses out there (and risk issues if they change and we haven't updated our SPF record), we can use this little snippet to automatically include Google's SPF records by default. That means that if the email comes from an address that's covered by Google's SPF records, then it's deemed to be valid too - when Google update their own SPF records, our records don't need to be updated to reflect that.

include:servers.mcsv.net

Anyone who can send emails on behalf of your domain, so where the from address looks like it's someone@yourdomain.com, would need to be covered off in this way - since we use Mailchimp to send our newsletters, their servers are included in the same way here, for the same reason.

-all

This bit's important...as it tells your email client what to do if it hasn't managed to match the sending domain with any of the preceding rules. The four possibilities are :

-all : FAIL - the mail should be treated as being spam.

~all : SOFTFAIL - the test is inconclusive and the message should be treated as though there were no SPF records.

?all : NEUTRAL - the test is inconclusive and the message should be treated as not spam.

+all : PASS - the mail should be treated as not spam.

Once that's set up and the DNS changes have propagated around the internet, it's possible to check by sending an email to check-auth@verifier.port25.com - you'll get an email back with a summary of whether or not your email passes the SPF check.

DKIM

Domain Keys Identified Mail is a similar method of authenticating that your email is coming from where it says it's coming from, but through a different mechanism. Each outgoing email is signed with a digital signature - that email signature can then be decoded and compared against a public record (kept in your DNS). If the two match, then the email is authentic and can be weighted accordingly.

If you're sending mail through your own mail server, then your mail transport agent will need to be set up to sign outgoing emails. DKIM can be installed easily enough through the opendkim package and once installed you will end up with a public key - this public key is then to put into your DNS record for the recepient's email client to compare against the results of its decryption of your signed mail.

If you're running your email through Google Apps, then configuration is considerably easier - starting from Google's own guidance on the matter, get your domain key, add it to your DNS record, then turn on authentication in Google Apps to tell it to start signing outgoing emails. Within 24 hours that should all be in place.

No matter how many servers you use for your outgoing mail, you can have multiple DKIM entries in your DNS records - each one will be prefixed with a different word, which is incorporated into the encrypted signature, so that the right sender record is checked for the right result.

Note that DKIM is different from Domain Keys, which is Yahoo's proprietary implementation of a similar method. Whilst there's little to stop you using both, it's probably easier to implement DKIM, as it's a more advanced solution, and whilst Yahoo does make claims over some central tenets of its functionality, there's less likelihood that it'll be made subject to licensing restrictions in the future.

As with SPF, you can check if you've implemented it properly by sending a blank email to check-auth@verifier.port25.com - the results of the test will be emailed back to you.