When it comes to your email address, you might presume that only you can send an email that originates from that address. Similarly, when you receive an email, you might presume that whoever owns the email address it claims to originate from has sanctioned that message. However, there is nothing in the original standards for email that guarantee either of these things. In reality, this aspect of electronic mail works very similarly to physical mail. A sender address might be on the envelope, but that alone proves nothing.
Of course, as email grew in popularity, solutions were devised to address this problem, but since they are not part of the core standards, they remain optional. It requires careful configuration on both the sender’s and receiver’s side to make it possible to verify the authenticity of sender information.
Has your organization configured these optional features correctly? There is an easy way to check. Take the domain part of your email address (for first.last@example.com, that would be example.com), and check if it is protected using this excellent scanner, provided courtesy of dmarcian.
Did you receive a nice, green message that says well done? Congratulations, it seems that you have done what you can to prevent others from sending messages in your name.
For anyone who didn’t see that welcome flash of green, were you greeted with a large, red message that tells you that your domain is not protected? Don’t worry, we’ve got you covered.
The Three Musketeers of Email Security
As email became more and more popular, three important new mechanisms were added to help others verify that emails sent from your address actually originated from servers under your organization’s control. All of these work by adding additional DNS records (publicly available information that can be retrieved for a domain) that help whoever received email from your address decide if it is legit. Each has to be configured correctly for this validation to work reliably.
1. Sender Policy Framework (SPF) Records
SPF works by specifying which servers are allowed to hand over mail that claims to be from the domain. If the receiving mail server at 175.45.176.2 wants to check if another mail server at 175.45.177.43 is allowed to send a message that claims to be from first.last@example.com, it can look at the SPF record of example.com, which will specify which servers are allowed to do so.
There is a slight problem, however. An email under delivery contains more than one address that may mark who the sender is:
- The From field contains the people who wanted the message to be sent
- The Sender field contains a single person who actually sent the message
- The Resent-From and Resent-Sender fields are added when an email is forwarded to another address
- Replies to the email should be sent to the address specified in the Reply-To field
- Delivery error notifications (bounced emails) should be sent to the address specified in the Return-Path field
These fields are stored in the headers section of the email, which is not directly shown to users, but the values they contain are used at various places of the user interface. In a simple email, it is quite possible that Sender, Resent-From, Resent-Sender and Reply-To are missing and From is the same as Return-Path – but for emails that go through mailing lists, are routed through multiple servers or have advanced error detection for delivery failures, these addresses might all be present and quite different.
Since each of these addresses can be for a different domain, one had to be chosen for SPF. The standard designates Return-Path – unlike other fields, it is not part of the original message, but appended by the receiving mail server based on who the sender mail server claims the message is from.
There are many problems with this approach: the Return-Path is usually not displayed on the user interface of mail clients and it does not have to have any connection with the actual person sending the email. Nonetheless, if configured correctly, SPF at least validates one address – even if not the most useful one.
2. DomainKeys Identified Mail (DKIM) Records
DKIM took a very different approach – it added a digital signature to the message that proves that it has not been tampered with. Digital signatures use two keys: a public key and a private key. The private key is used to sign data, while the public key can be used to verify that the data is signed. For DKIM, the private key is usually managed by the organization’s mail server (which uses it to sign outgoing messages), while the public key is published through DNS for others to retrieve. When somebody receives a DKIM signed message, it checks its signature using the public key. Part of the signature itself specifies the domain name that can be used to retrieve the public key. A verified signature means that whoever owns this domain name has claimed responsibility for the message.
Since according to the standard, the domain designated by the signature does not need to be the same as the one used by any of the addresses in the aforementioned fields, we haven’t gotten closer to verifying that the email is legit. But now we have cryptographic proof linking the contents of the email and its claimed sender to a domain. Also, if no DKIM signature is present, there is no way to tell if the message should be signed in the first place - since the domain which the message should be validated against is only specified in the signature itself, it is impossible to decide if an unsigned message is valid or not.
3. Domain-based Message Authentication, Reporting and Conformance (DMARC) Records
SPF and DKIM are pieces of the puzzle, but they alone are not enough. An email that claims to be from first.last@example.com can be sent by a rogue mail server with a valid SPF record, a valid Return-Path that passes muster and a valid DKIM signature by an unrelated domain, but that brings us no closer to authenticating the sender.
DMARC aims to solve these problems by providing the missing information. It works by looking at the From header, using its domain to query for a DMARC record, which when present indicates that the domain used by the address in the From field must match an authenticated domain - either the domain of the Return-Path address validated by SPF or the domain used for a valid DKIM signature. One or the other is enough to pass DMARC checks.
With DMARC in place, others receiving your messages can be sure that the message needs to pass either SPF or DKIM validation, and can take appropriate action when they do not. Keep in mind that this still does nothing to validate the actual person sending the email, just the domain part of the From address. It is up to us to trust the owner of the domain to set up the infrastructure to authenticate its users and tie them to specific addresses.
Doing it Right
So you want to configure your email system to send messages that pass muster and to prevent others from doing the same? Great! While every system is different, we compiled a list of actions you can take to secure your system.
Don’t Do it on Your Own
The easiest way to maintain a secure email system is not to maintain one. There are several cloud providers on the market who will be more than happy to take care of all these issues - the two largest being Google (with G Suite and Gmail) and Microsoft (with Office 365 and Outlook). In fact, you might already be using one of them. They both have detailed guides on how to configure your domains to use their services, and they take care of all the technical aspects of both signing and delivering your messages and verifying messages sent by others.
- See Set up SPF in Office 365 to help prevent spoofing and its follow-up articles if you are an Office 365 user
- Start with Enhance email security if you are using G Suite
Configure it Yourself
If you don’t trust cloud providers, or you have requirements they can’t hope to meet, you can always configure your own email system. Please note that this is not a leave it and forget it task - maintaining your own email system is a significant burden on IT personnel.
Make Use of SPF, DKIM and DMARC
To deploy these DNS records, you will first need to take inventory of your existing systems:
- Which domains are used by your organization to send email from?
This includes top level domains (@example.com) and their subdomains (@newsletters.example.com). You will need to deploy the new DNS records to all of them.
- Which servers do you use to send emails?
All of these servers need to have their domain names reverse DNS resolvable, and they must be included in the SPF records of all domains they are sending emails from.
- Do you have any third parties or internal services sending emails on your behalf?
Most services have guides on how to configure them for SPF, DKIM and DMARC. If not, they can usually be configured to either send email through a relay you maintain, or to send messages under their own domain. Carefully consider which third parties you allow to send emails on your behalf. It is best if they are assigned their own domain or subdomain so they cannot fake emails under your primary domain, which is often used for the email addresses of employees and departments.
Please note that DKIM requires additional configuration - your mail server needs to be configured to sign outgoing emails. You should use a separate key on all servers and add them under different selector names to your domains. Selector names should be hard to guess but easy to identify.
Secure Your Server
No amount of DNS configuration helps if your servers are vulnerable. You need to ensure that only authorized users can use it to send emails:
- Do not run an open relay: open relays are servers that will forward incoming mail to any other mail server if the recipient cannot be found locally. If you do so, they will be used by malicious parties to send messages on your and others’ behalf
- Authenticate senders: ensure that your mail server requires users to be authenticated before accepting emails for delivery. Establish a strict relationship between your users and the email addresses they can send messages from
- Use TLS for message submission: do not allow unencrypted connections to send emails or to authenticate. If your employees are working from outside the office, it is possible that someone is listening, and can catch unencrypted credentials sent over Wi-Fi. This kind of attack is quite common at airports or hotels.
The way electronic mail was designed has made it very hard to conclusively verify the legitimacy of the sender. Fortunately, solutions exist to this problem, but they must be deployed and maintained. Many companies today ignore this risk – and attackers have free reign in sending mail on their behalf. Most companies usually wake up to this problem once their emails land in the junk folder of their partners, but by that time, the damage to domain reputation has already been done. It is in the best interest of every company, administrator or even end user to use an email system that is well-configured and prevents sender fraud.
Curious to know more? Check out this in-depth guide to email security here.
