The holy trinity of Email Security

Email can trace it’s history back to around 1965, it’s proved to be a very versatile communication method, we use it nearly every day, even your gran probably has an email address. We’ve built business around it, we check in with loved ones, we use it to pass good news, bad news, business updates, lunch menus, cat jokes and, of course, Spam.

Email Spoofing is when someone forges the address of an email sender, that is to say they send email on your behalf. This forged email is a significant part of the Spam we receive, but more importantly, it can be used to manipulate the existing relationships between two or more parties.

We’ve probably all heard of those email scams where a Supplier appears to send an updated Invoice whereby they include their new bank details. The Accounts Payable folks check the invoice against their records and for whatever reasons the transaction appears to be authentic, so they update their system and generate a payment. The genuine Supplier never receives payment, this spoofed email had the bank details for another party in there, the payment has been made and is usually unrecoverable.

Protecting against Email Spoofing is one way we can try to tackle this kind of malicious behaviour.

SPF – Sender Policy Framework

SPF validates the senders domain by checking if the sending server was on a list of approved IP Addresses. This ‘list’ isn’t some central super list, this is a list specific to the sending email domain. If the email doesn’t come from a trusted source, the receiving mail server can tag the email as spam and either deliver it to the users spam folder or not deliver at all (dependent on mail server policy).

DKIM – DomainKeys Identified Mail

First of all, a word to the wise; DKIM is not universally supported! You need to research this, especially if you use Microsoft Exchange.

Most, if not all, of the Cloud based email providers support DKIM and make it relatively easy for you to configure.

DKIM has a bit of a reputation for being a bit tricky to understand. It is essentially a way for a sending organisation to take responsibility for the authenticity of mail transmitted by using cryptography.

A sender gets to chose what parts of the message will be used for the cryptographic signing process. This could be the entire message, or just parts of the header. It is important to note that once the message has been signed, the element(s) used in the signing process must remain intact throughout the mail transmittal process otherwise the cryptographic check at the receiving side will fail.

This is important if your mail is forwarded or checked by another party, for example, if you had some service that checked outgoing mail for viruses, and that service then made a change to the header so that it knew the check had been made (to prevent the same message being stuck in a loop) this might break the DKIM check. You need to identify what parts of the message/message header will remain the same, such as the From field for example.

DKIM works by signing your message (using elements defined by you) with a Private Key, as the email is received by the receiving mail server, the receiving mail server asks for the sending mail servers Public Key. If the DKIM signature can be verified against your mail servers Public Key then the message is deemed to be authentic and passed on to the intended recipient. If the message fails the DKIM check, then the message will be either rejected or marked as and sent to spam.

DMARC – Domain-based Message Authentication, Reporting & Conformance

DMARC – one of those acronyms that just rolls off the tongue.. SPF and DKIM have been around for over a decade, the noble ideas behind those protocols should have reduced spoofed emails, yet that doesn’t seem to be the case. It would appear that SPF and DKIM do not really allow for highly agile environments, the types that are always changing, those that are using cloud based services and those that allow third parties to send on their behalf for example.

It was felt that the only real way of tackling this was to allow a process in which a sender and receiver could share information, for example, the sender should explain how it’s infrastructure is secured and what to do with messages that do not meet certain expectations.

• Senders can send messages that are sometimes encrypted, but if they use third parties, the chances of some emails not being signed increases.
• Receivers don’t always know what to do with a message.
• Senders get poor feedback on why some of their messages were blocked.
• Even if a sender locks down their outgoing messages, receivers may still be hesitant to block unauthenticated messages through fear of disrupting legitimate business.

The answer is to share information about the authentication you expect to appear on emails you send. You add to this by defining what the recipient should do when something doesn’t tick all the boxes. Periodically the receiving mail server will produce a report and send it back to the sending mail servers so that they can review what messages appear to come from them and update their policy accordingly.

Back in 2007 Paypal started sharing information about their email authentication with Yahoo Mail and followed this up with Google Mail. The results were deemed to be extremely effective with a significant decrease in the number of spoofed Paypal emails reaching users within the Yahoo and Google mail services.

The goal of DMARC is to build on this system of senders and receivers collaborating to improve mail authentication practices of senders and enable receivers to reject unauthenticated messages.