The ending of the almost eponym 1946 movie finds Frank musing about his own incoming death. You see, he and his beloved Cora escaped justice once after having killed her husband, Nick. But here he is, condemned for murdering Cora, even though her death was accidental. And in his mind, it feels pretty much as if Justice was served in the same way as the postman delivers letters, who rings once, and if nobody answers, rings again for important missives.
Arguably, a lot of drama could have been avoided if Frank had just absconded with Cora straight from the beginning. And instead of a goodbye note left in a cash register for Nick, Cora would have posted a letter from far away. But that would probably not have made an interesting story, apart maybe, the said delivery of the letter by a postman.
That will be the focus of today’s post. Except instead of an envelope, stamps and paper, we will bring it to our digital era and look at how emails travel and what measures can be taken to ensure they are legitimate.
Or even better, what measure can be taken to prevent unauthorized people to send an email seemingly coming from our domains.
Re-introducing SPF, DKIM & DMARC
Even though this topic might have been addressed numerous times, according to the annual ENISA Threat Landscape, emails still figured amongst the prime cyber threats faced by organizations in 2021, with phishing being a common initial vector for cybersecurity breaches.
We all made our due diligence and spent countless hours giving our users’ awareness training. If not, well, now is a good time to start. But at some points, one must realize that the responsibility of detecting email impersonation cannot be left to the end-users alone. We can implement technical solutions to block illegitimate emails from even reaching them. Moreover, these solutions work often both ways by also protecting others from receiving malicious emails from your domains.
So let’s dig into the three pillars of email security that should be deployed for all your domains, namely:
- The Sender Policy Framework (SPF),
- The Domain Keys Identified Mail (DKIM),
- And the Domain-based Message Authentication Reporting & Conformance (DMARC).
Emails’ format
If Cora wanted to write an email to her husband, Nick, today, she would probably start by opening her favorite email client, such as a web browser or a desktop application. Then, she would specify the recipient, to “nick@twinoaks.com”, add an ominous subject, compose a heartbreaking message, and click on the send button. On the other side of the line, Frank would get an email apparently coming from “cora@twinoaks.com”, and after the initial shock of the revelation, would go on with his life.
The structure of Cora’s email before transmission should follow the Internet Message Format, and it is the responsibility of the client to format it properly. To put it very simply, the client will prepend Cora’s message with several headers. The sender becomes “From: cora@twinoaks.com“, the recipient, “To: nick@twinoaks.com“, the subject has its own header “Subject:”, and possibly a date or other metadata will be added as well before the client finally submits the email for sending to a mail relay.
These headers are the only information available for verification by your users. And all can be tampered with or simply crafted. Frank could have formatted the email himself and changed the From header1You’ll see mention of this specific From header as the “RFC5322.MailFrom” in the literature into virtually anything suiting him. The same goes for the To header, which could have been replaced by nick@istoleyourwife.com, as long as Frank has control over his clients’ emails (or over any other means to submit the email to the gateway) which incidentally, is perfectly feasible as we will see later.
Only two out of our three pillars mentioned earlier, DKIM and DMARC, can help protect against this kind of forgery. Let’s not get sidetracked and focus on the Simple Mail Transfer Protocol, or SMTP, which plays the role of the delivery guy in our story.
Emails’ transport with SMTP
The venerable SMTP 2RFC 772, RFC 788, RFC 1869, RFC 5321 and many others was developed in the early eighties, in a dark age when neither Mac nor Windows existed. Designed to reliably transfer messages between mail gateways, SMTP exchanges were and still are mainly done in plain text with a very simple encoding. And if several extensions and security layers have been added since its infancy, it is still perfectly possible to connect manually to a mail gateway3In ASCII, although Unicode is supported nowadays and submit an email with whatever headers and content you desire.
So, back to our story. Nick received his now ex-wife’s emails and decides to write a last message to Frank. With carefully chosen words, explaining in the politest way, how he is totally fine with the situation and wishes them a long and happy life. A client’s mail is opened, a message is written, and the send button is hit again.
The email client, having formatted the message properly with at least the headers “To: frank@chambers.com” and “From: nick@twinoaks.com“, submits it to a mail gateway, which will now attempt to deliver it to its intended recipient. That involves looking up specific records4For the tech savvy, we are talking about DNS MX records with a fallback to the A records of the domain in the vast Internet directory to determine to which other mail gateways the message is to be transmitted to.
Having found the location of the mail gateway for the domain “chambers.com”, our sender gateway will use SMTP to contact it. Being a very polite gateway, and because the protocol mandates it, it will always start the communication by saying “Hi, I am the gateway at twinoaks.com”. Of course, not in so many words5HELO for legacy SMTP, EHLO for ESMTP but you got the gist. Then, it will proceed to tell the other gateway that it holds a message from “nick@twinoaks.com” to “frank@chambers.com”.
Now it might be a little confusing because SMTP will use apparently similar From6MAIL FROM: nick@twinoaks.com, referred as the “RFC5321.MailFrom” header and To7RCPT TO: frank@chambers.com headers than the client, but these are actually quite different. The literature will differentiate them by using “envelope headers” for the SMTP ones, and “email headers” for the client’s ones, but we could use “transport headers” and “body headers” for simplicity as well.
Amongst the differences between them, the transport headers will be used to determine a return path, in case the delivery fails. They can still be spoofed, and the worst is that they do not even need to match those prepared by the client. This time, out of our three pillars, only SPF and DMARC can verify them.
Now if everything goes well, the final mail gateway at chambers.com will deliver Frank’s message in Nick’s mailbox, who, upon reading it, will probably not burst an aneurism reading the gentle words it contains.
About emails’ forgery
So far, our protagonists have all considered the emails they received as legitimate, without questioning their origin. But what if Cora’s goodbye email was never sent by her, but by another party, just for the sake of wreaking havoc with the couple’s life? Or if Frank’s response contained a demand for payment in exchange to forget his wife and the promise to never go after them with bank account details to transfer the money for good measures?
These are the kind of emails an organization is expected to receive at some points. Not the whole love affair shenanigans of course, but a bill sent from the president of a company to its finance accountants. To properly understand what controls we can put regarding such emails, we must keep in mind the two sides of the story. On one hand, what the users see within their client’s mail, and on the other hand, what passes via SMTP between mail gateways.
Protecting yourself & others with SPF, DKIM & DMARC
There is no point in delaying the inevitable now, we must deepen our understanding of SPF, DKIM, and DMARC. To begin, all three of them rely on the Internet directory (the DNS) to work. That means you have two responsibilities here. First, you must set up your DNS records correctly for all your domains, so that receiving parties can check them against any email they receive from supposedly you. Then you must check the records set by other companies whenever you receive email from them.
SPF
But how does that work? Once again, let’s be simple, if Nick was to set an SPF record8https://datatracker.ietf.org/doc/html/rfc7208 for the twinoaks.com domain, he would identify his own mail gateway as the sole gateway authorized to send an email on this domain’s behalf. And maybe one or two others9As a TXT record it could contain up to 64K of data, or up to 10 extra DNS lookup, but who does that anyway? for advertisement purposes. After all, Nick runs a dinner and a little bit of marketing is always a good idea.
DKIM
Nick also likes the idea of letting others know that this or that email was really sent by him10The non-reputability concept, so he configures his mail gateway to sign his emails, or more accurately, some of the body headers and maybe a portion of the message. That’s good, but how in the name of the Post office will anyone verify these signatures? That is when DKIM11https://datatracker.ietf.org/doc/html/rfc6376 comes in handy. Nick will generate a pair of digital keys linked by convoluted cryptographic algorithms. And that is the extension of what we will explain here because some people at the back of the room threaten to fall into a deep slumber already. Suffice to say that Nick will keep one of these keys private to himself and his mail gateway, which will be used to sign messages. The other one will be publicly set as a DKIM record and will allow others to verify the signatures because the signing mail gateway will include a reference to it as a body header.
Nick has now a mean of control on both the transport headers and the body headers. But so far nothing prevents someone from using another mail gateway to send emails to his wife or his customers, the worse case being at your discretion. Remember, transport headers do not need to match body headers, so sending an email from Frank’s chambers domain gateway but containing Nick’s name in the message should not bother any SPF aware gateway, especially if no such SPF record has been set for the chambers domain. Similarly, nobody forces Frank to sign his message, so DKIM might not be as useful as it seems. It is indeed much more troubling than that, as Frank could actually sign a message with another set of keys from another domain and that might be perfectly fine. DKIM only validates the signing domain, not the sender domain.
DMARC
What Nick is missing here is a properly configured DMARC record12https://datatracker.ietf.org/doc/html/rfc748913https://datatracker.ietf.org/doc/html/rfc9091. By setting a DMARC record on top of the SPF and DKIM, the recipients’ mail gateways will now be able to compare and correlate the result of the SPF and DKIM controls against the content of both transport and body headers. If they deviate from the given DMARC policy, the mail gateway will accept or reject the emails. Even better, in case someone receives an email from Nick’s domain but rejects it due to DMARC, Nick can also get automatically a report about it by specifying a dedicated email address directly in the DMARC record. In other words, his own customers, as long as they check Nick’s DMARC policy, will warn him of any fraudulent emails they receive from his domain.
SPF, DKIM & DMARC’s pitfalls
Of course, everything is not perfect in the email world, and there are numerous pitfalls on which unicorns can trip if our three pillars are implemented without a good understanding of their limitations.
First, neither SPF nor DKIM protects your subdomains. Yes, you read that one correctly. In layman’s terms, if Frank decides to send an email from the subdomain @istillgotyourwife.twinoaks.com, neither SPF nor DKIM will do anything to protect the recipient. Luckily enough, that is when DMARC really shines since it can also cover your subdomains.
SPF has other limitations tied to the Matryoshka doll syndrome, as an SPF record can reference other SPF records, which in turn can reference … you get it. But they are mostly corner cases that we are not going to list here. However, we can build a solid case against DKIM, which has been designed with too much flexibility. Indeed, DKIM allows you to specify a third signing domain different than the transport or body From headers. So, if Nick was to use his own signing key tied to the chambers domain, providing that he also sets up a corresponding DKIM record, the receiving mail gateway would happily let the message pass. Of course, it goes without saying that it would be a stupid mistake on Nick’s part to sign an incriminating email with his own DKIM signature. Luckily, setting up a rogue domain nowadays is a straightforward process thanks to the countless marketing companies that make their business of sending emails on your behalf. Again, DMARC comes in handy here and, a properly configured policy would prevent this kind of abuse.
Conclusion
We could go on with other common mistakes often seen in the field, but at this point, it should be pretty clear in your mind that in order to protect your organization and others, you need to implement all of our three pillars together. Or course DMARC is not perfect, and some of its limitations come from a lack of wide adoption and the actual difficulty of its implementation. Not to mention that some cloud providers14Looking at you Microsoft, seriously, treating a reject policy as equivalent to a quarantine one?, who pretend to automatically enforce it for you, make a botched job out of it.
Anyway, the simple conclusion to our story is twofold. First, implement SPF, DKIM and DMARC for all your domains. Finally, carefully review the DMARC reports you will receive, and take appropriate actions to stop malicious activities.
To go further
We mentioned at least twice in this episode that SPF, DKIM, and DMARC should be implemented on all your domains. That is because limiting those controls to your main one is not enough. You have probably several other domains that are not meant to receive or send emails, some of them you might not even be aware of. For example, think of this one-time event website launched by your marketing team on a dedicated domain without mentioning it before to the security team. Or a lookalike domain you bought to protect your brand. In all likelihood, these domains will lack any security measures and will not have any SPF, DKIM, or DMARC record configured.
Generally speaking, any domain you own can be abused by attackers to send convincing, illegitimate emails to your users or customers. To protect them, the steps are the same as for your main domain, you must implement all the necessary DNS records needed. Even if these records might be a bit different in their form15NULL MX records or SPF null values come to mind, they will perform identically.
On those last words, that’s all folks, thanks for your attention and keep following us for future installments as we will elaborate on SPF, DKIM and DMARC DNS records individually.
