How to prevent email spoofing
Email dates back to the very early days of the internet – back when the internet was just ARPANET; and it’s fair to say it’s showing its age. Email itself provides no validation that the sender is who they say they are. Just like a paper letter, the sender can write any reply address they want. A lot of unsavoury characters have taken advantage of this, and will try to add perceived legitimacy to their scam attempts by adding a trusted sender’s address to the message.
In response to this threat, several technologies have been developed to try and weed out these fake messages. Whilst some are quite easy and free to implement, you have to set them up as the sender (or rather, the sender’s IT team) in order for other people to validate your messages.
Why should you care?
It protects your reputation and your brand. If one of your customers receives an email from you that tricks them into losing money or having their systems breached, it won’t reflect well on you. The fact that you didn’t actually send the email may be irrelevant. Why didn’t you have measures in place to prevent it? Can they ever trust an email from you again?
It prevents your messages being blocked. Most spam filters look for anti-spoofing measures on the sender’s side to inform them. If they can’t find anything to base decisions on, they’ll fall back to using their best guess; and they may guess incorrectly. Many spam filters will treat messages with no anti-spoofing measures harshly, defaulting to blocking them rather than letting them through.
What can you do?
There are three pieces of information you can provide to help recipients identify which messages are legitimate, and which are from a scammer: SPF, DKIM, and DMARC. All 3 methods use DNS records. These are public pieces of information you can choose to publish to the world. If you’ve got your own email domain, you’ll have a DNS service already. These methods work as follows.
SPF (Sender Policy Framework)
An SPF record contains a list of servers which are authorised to send emails on your behalf. Recipient spam filters can check the record, and if the sending server isn’t on the list, they know it’s a scam. This is an easy and effective way to protect against spoofing.
You do need to make sure you have a complete list of legitimate message sources first, though. This doesn’t just mean your email system – if your website sends emails, or you use an external newsletter service, then you need to include those too. Remember that if anything is not included on the SPF record, you’re telling recipients not to trust it.
DKIM (Domain Keys Identified Mail)
DKIM authenticates messages using a digital signature. Every message signed by DKIM can be validated using a public encryption key that is displayed in your DKIM record. This key is linked to a private key that you control. Only signatures created using your private key will validate using the public key.
DKIM proves a message is legitimate and hasn’t been modified in-transit; however, the reverse is not true i.e. the lack of a DKIM signature does not prove a message is spoofed. This makes it useful to avoid messages being blocked, but it should be used alongside SPF to weed out scam emails.
DKIM is a bit trickier to implement than SPF because it uses cryptography in addition to a DNS record. If you use a hosted email provider (e.g. Office 365) they’ll usually do most of the leg work for you – requiring you only to add the DNS record.
DMARC (Domain-based Message Authentication Reporting and Conformance)
DMARC is essentially a policy that tells recipient servers how to handle validation of your messages, and how to report spoofing attempts. This closes a couple of loopholes which exist in SPF and DKIM, and provides you with insight into what messages are being sent with your name attached to them. This can be useful to check that you aren’t accidentally blocking legitimate traffic, or to see if you or your contacts are being specifically targeted. Like with SPF, the DMARC policy is published to the world using a DNS record.
DMARC reports are sent to an email address you specify in your DMARC record. They are XML-based, which means they are easy for a computer to read, but not ideal for a human. Rather than having a mailbox swamped with such reports, you may wish to use a third-party reporting tool which will ingest these messages and provide you with useful summary reports. A number of free and paid tools exist for this purpose.
More information
If you want help or further advice about securing your emails or data, feel free to get in touch with us today.