“Hey, did you get my email?”
“Oh, I definitely sent it”
“Hang on, I just found it in junk”
How often have you had this conversation? It’s bad for business!
Below are a few tips to help you stop landing in the spam folder and get your message in front of people. As a bonus, they will actually increase your security too – by making sure that only you can send emails from your domain.
These tips are techy tips (but as simply explained as possible!), and should compliment the obvious stuff like don’t make it read spammy!
Before we jump into it, let’s get a few techy terms out of the way:
What is DNS?
DNS stands for Domain Name System. It’s basically a big database of name to IP mappings, so that humans can use names and computers can translate those into numbers. Each entry is called a “record”, for example:
www.alwaysnetworks.co.uk. 60 IN CNAME alwaysnetworks.co.uk. alwaysnetworks.co.uk. 60 IN A 188.8.131.52
These are two entries from Always Networks’ DNS. There is, a “CNAME” and an “A” record. The CNAME says:
If you’re looking for www.alwaysnetworks.co.uk, it’s the same as alwaysnetworks.co.uk.
The A record says:
If you want to get to alwaysnetworks.co.uk, it can be found at 184.108.40.206
There are a few types of records in DNS, including A, CNAME, and a few others, but most are beyond the scope of this post.
One of particular interest for this post is a TXT record. This is a free text record that can hold anything – but there are a few standards which use TXT records to enforce security.
What is a domain name?
A domain name is your identity. It’s the web address people go to. It’s the bit after the @ in your email. For us, it’s alwaysnetworks.co.uk (though we have some others too).
Using your own domain name, for both your emails and your website, gives out the right professional image. No major companies use @outlook.com email addresses – why should you?
How can I secure my email using DNS?
The specific DNS records set out below are designed to prove it is you sending emails from your domain name. Ultimately, honouring them is up to the third party system, but these standards are widely implemented. Ensuring you have them configured correctly makes sure that receiving clients will accept your email if it’s genuinely from you, and dump it in junk if it isn’t.
Get the right SPF
This isn’t about sun cream! SPF stands for Sender Policy Framework. It’s a specially formatted string that you add as a TXT record, which lists everyone who is allowed to send emails from your domain.
Anyone who isn’t in the list should be treated with caution, and most email clients will throw the emails in the junk.
This is what it looks like:
v=spf1 include:spf.protection.outlook.com +ip4:220.127.116.11 include:zcsend.net -all
To put this in English, it goes something like this:
Allow anything in the Outlook SPF record (because we use Microsoft 365!)
Allow anything from that IP
Allow anything in the Zoho Campaigns record
Drop anything else
There are a lot of options that can go into an SPF record, as defined by the standard RFC 7208.
Nobody wants to be reading standards though, so this tool from MX Toolbox is great to help you work out what you need.
It’s vital to consider all services which send email from your domain when setting up SPF – including your email server, contact forms on your websites, your accounting software, email campaigns, etc.
What the DKIM?
DKIM uses cryptographic techniques to make sure that an email server is who it says it is.
If I send you an email, my mail server puts an encrypted signature in the email. Published in a TXT record on my domain is a code that allows you to verify the authenticity of that signature. Only my mail server knows how to make that encrypted signature, so if it passes that verification you know with certainty that it comes from my email server.
You can see here on the UK Government’s website more about how it works.
DKIMs must be generated on the mail server (as they sign the messages). The mail server will then give you a record to add to your DNS to allow third parties to verify the signature.
Like SPF, DKIM should be implemented for any services which send mail from your domain.
Where is your DMARC?
Domain-based Message Authentication, Reporting & Conformance (catchy!) builds on SPF and DKIM to add some policy and reporting.
It has a mechanism for the sender to instruct the recipient what to do with messages that don’t meet the SPF/DKIM policies:
- Allow them
- Quarantine them
- Reject them
Allowing them should only ever be used for a phased introduction of DMARC – in general it’s a bad idea.
It also adds some reporting functionality. Optionally, published in this TXT record are a couple of email address fields, which allow the recipient email server to automatically send reports back to the domain owner if there are any policy breaches. So for example, if someone is sending a load of spam from your domain name you will be notified.
Ensuring your domain’s SPF, DKIM and DMARC records are configured correctly is a great way of ensuring that your legitimate email stays out of the junk folder, and any spam is correctly identified.
If you need a hand with this, contact us and we can help. We have experience setting this up for many of our clients.