Email is an ancient thing, it was born much longer before the Internet.
The first email system was born in 1965 at MIT. At that time email communication was limited within the boundaries of a single mainframe, those huge and very expensive and delicate multi-user computers that occupied entire air-conditioned rooms and required continuous supervision.
In 1971, the first transmission of an email between connected computers happened. It was a small step for a single email, but a huge first step for humankind.
In 1982, the SMTP protocol was born; this is the protocol we still use today to exchange email on the internet.
The main issue about email (and SMTP) is that, being born in a collaborative environment where security wasn’t an issue at all, being designed at a time where abuse was not even an theoretical option, the protocol did not have any security at all among it’s design requisites.
No authentication of the sender: anybody could pretend to be anyone.
No confidentiality: messages were exchanged and stored in clear.
No integrity checks: manipulations of the email content along the path could not be prevented or even detected.
No protection about unsolicited messages: anybody could send any amount of email to any recipient.
Then email became popular and these issues started quickly to pop up.
It became clear that we needed to do something in order to address this lack of security in the protocol. Nobody had thought about it earlier because nobody envisioned that email would become what it is today: the main form of electronic communication that our societies are based on, something that all organizations, businesses and individuals rely on every day in order to run their lives.
As we all learned the hard way in the following years, adding security afterwards is much more difficult than putting it in at design time. This is one of the most important principles of GDPR: if you want real security you need it by design.
Adding security as an afterthought is hard. It is even harder if you have to guarantee backward-compatibility. Email is the most clear example of how hard is to add security to something that is already deployed worldwide—where you have to guarantee that email can still be exchanged with servers that are not upgraded to the new standards.
This is where the acronyms that are in the title of this article come into play: SPF, DKIM and DMARC are three standards that have been added to the email in the attempt to make it more secure.
SPF has a very simple task: prevent domain spoofing. Your organization can declare to the world a subset of IP addresses authorized to send email on behalf of your organization’s domain. By defining this policy, you can prevent malicious actors sending email pretending to be your organization.
The configuration of an SPF policy is very easy and relatively risk-free: you just need to map all the IP addresses that your organization uses to send email. A little effort for what you receive in exchange, and if you correctly enumerated all your legitimate IP addresses you send email from, no email will get lost.
SPF isn’t perfect, though, and it is not sufficient to prevent all types of spoofing, but it is still much better than nothing.
DKIM has a main purpose: guarantee the integrity of the email content. Integrity means that the recipient can detect if the email has been modified or tampered with along the path. This is done through an electronic signature: if the signature is valid, you know that you can rely on the content of the email. If the signature is invalid, then the message has probably been tampered with. This signature is automatically added and checked by mail servers, and the user doesn’t need to do anything.
Setting up DKIM requires a little more effort than SPF but it is safe: if you misconfigure it, email will not get lost.
SPF and DKIM still don’t completely solve the phishing problem. Email is a little bit like a plain paper letter: the sender and the recipient written on the envelope are used for the delivery, but the recipient does not see the envelope. The recipient just sees the letter inside the envelope, and in that letter the name and address of the sender can be spoofed. Basically, the email client shows the sender that is written in the letter, not the one on the envelope (which can be protected with SPF).
DMARC has been designed exactly for this purpose: making sure that the sender that your email client shows is reliable. This is done by publishing a DMARC policy that instructs the recipients to check if the sender displayed to the recipient matches either SPF or DKIM. The email must be sent from an authorized IP address for that domain (SPF is ok), or it must be signed with a legitimate key of that domain (the DKIM signature is ok), otherwise it will not be delivered.
DMARC must be configured on a domain by domain basis by the email administrator of the sending domain. It provides great protection against spoofing and impersonation, but the configuration is not straight-forward and mistakes in the configuration can lead to email loss. Therefore, configuring DMARC must be done with expertise, without improvising.
There are other standards that have been introduced in email, like TLS (to encrypt the email in transit) and S/MIME or PGP for end-to-end encryption. These are things you don’t need to care about. TLS is automatically managed by mail servers. S/MIME and PGP have minuscule adoption because of the complexities related to the key management by the end users.
Should you care about SPF, DKIM and DMARC for your organization? Yes, you should.
Start with SPF, then proceed with DKIM and finally evaluate DMARC.
These configurations will not solve all email security problems, but they will make your email communication much more secure and reliable.
Keep in mind that under the hood email is much more complex than it looks on the surface, so consult with an email expert in order to be effective and avoid trouble.
