Emails – Why are emails to valid email addresses being rejected or sent to spam?
Emails are an interesting topic. We set up email accounts and then just expect them to work don’t we – and why not, they should shouldn’t they?
Well in a perfect world yes, our emails should ‘just work’. The trouble is, there are just too many rogues in the world that are just waiting to take advantage of us and therefore our mail providers are finding new ways to tackle the dreaded SPAM.
Most of the time it’s badly formulated subject lines or perhaps specific words that are used in the body of the email that make the automated spam detector spring in to life and make decisions about our emails for us. However, in recent times there are other mechanisms that are being used more and more to help the mail systems make spam decisions and these methods need a little work by the Club to ensure that Crossmember emails are regarded as safe.
Here’s a diagram that helps to explain one of the mechanisms that mail servers use to stop domain spoofing and email forgery from our perspective.
So here, Crossmember needs to send out an email to a member. It could be to remind them that they need to renew their membership or to send out the login link so that they can view their own membership record.
Crossmember always uses Club emails to send out these messages because they need to come from the Club, but when the member’s email servers receive the email, they do a variety of checks to make sure it’s authentic. One of those is to ensure that the original sender is allowed to send from the domain. In this case it’s asking can crossmember.co.uk send emails on behalf of the-car-club.com.
So how do we fix it? That’s all to do with something they call the Sender Policy Framework or SPF for short. Basically it is a DNS record associated with your domain that the receiving mail server looks up to see who has permission. So what do you do?
First, login to your hosting/domain provider that is handling your DNS and look for a record that looks similar to this:
TXT “v=spf1 a mx include:gridhost.co.uk ip4:95.142.156.0/24 ip4:195.62.28.0/23 ~all”
You know this is an SPF record from the v=spf1 version field at the beginning of the text.
If you don’t have one of these, then ask your provider to create one for you because all the rest of the text is dependent of your own mail server needs so you can’t just make it up. Once they’ve created one, then you can go about editing it.
Using the above SPF record as an example, we’re going to add in crossmember.co.uk to this record to inform all receiving mail servers (the member’s in our example above) that Crossmember is allowed to send on behalf of the club. So our record now becomes:
TXT “v=spf1 a mx include:gridhost.co.uk ip4:95.142.156.0/24 ip4:195.62.28.0/23 include:crossmember.co.uk ~all”
Note: that there are no spaces in the added text.
… and that’s it – that is the Club giving Crossmember the authority to send emails on your behalf and therefore satisfy the email forgery / domain spoofing checks.
Hang on though …. while we’re at it, there’s more …..
DKIM – DomainKeys Identified Mail
While you’re doing all the above with DNS and talking to your provider to create SPF records – ask them to enable DKIM. You can’t do this one on your own unless your provider has easy options to enable/disable DKIM.
So besides that fancy name, what is DKIM?
DKIM is a means of associating an email message with a domain through the use of public key encryption and simplistically it works like this…
Public key encryption is a cypher with two keys. One is a public key (anyone can know it) and one is a private key (kept secret). Both keys are required in order for this encryption method to work.
The email sender puts a ‘signature’ in the email header, but this ‘signature’ is encrypted using the private key. When the receiver receives the email, the DKIM public key is looked up in the DNS record and the signature decrypted. If the decryption works then the email is known to have been sent by the domain.
The public key is put in …. yup you guessed it …. another DNS record. Crossmember’s DKIM record looks like this:
default._domainkey TXT “v=DKIM1;k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR2qFhr+ZSG8ARR9MRL+0B5xXpLeeFXGTXe2pCsTTORyd/1V2yQJ2Fdpu6IxRks3NHCeSkFzhEWWfVtdm38a/7m/UcC7f8JyKL830XNTmziGb+rMjdejn/Yj86MrG0hL8K9yN30I3yBewGxUjOu56C3HI8laeeWDrQ9iD+OolgQIDAQAB”
and that big long random string of text is the public key.
The public and private keys are generated by the Club’s email servers, so ask your provider to enable DKIM. Besides helping to keep Crossmember’s emails out of the spam bin, it will help all Club emails too.
And Finally …
After making these changes, it’s possible but unlikely that they’re going to work straight away. DNS is cached by the servers that do the look up to cut down on what would otherwise be a significant amount of internet traffic. So all records have a TTL – Time To Live. The TTL is the caching timeout. If your DNS provider shows you the TTL (not all do), it’s always specified in seconds – so 86,400 is 24 hours, 14,400 is 4 hours etc. It will be updated, you just might need to wait for it.
If you need any help with this …. just ask 🙂