Email spoofing is one of the techniques the forces of evil use to convince you their spam/phishing email is legit. In short, email spoofing is used by these malicious agents to make it seem like their emails are coming from trusted sources like your bank, your favorite product, or your boss.

Email protocols have been with us for a really long time. Simple Mail Transport Protocol (SMTP), the main protocol email communications are based on, is from 1981. The internet has changed quite a bit, unfortunately, email not so much. When email was created there were just a fraction of today’s users. Back then there was little harm in sending a fake email. Now, emails are used for almost all digital services you can think of and the technology has been slowly catching up.

Let’s start off by talking about how emails work so everyone is on the same page. Bear with me here, this is an extreme simplification of how email works but it will help me explain the mechanisms to make this a secure process. Roughly speaking, when someone sends an email, it goes like this:

  1. Alice (hi@alice.com) writes an email to Bob (hi@bob.com).
  2. Alice sends the email to her email server to be delivered.
  3. Alice’s email server locates Bob’s email server and transmits the email.
  4. Whenever Bob connects to his email server, he asks for new messages and a new email pops up in Bob’s inbox.

Simple! However, many things can go wrong in the process of sending an email. Let’s dive in!

Sender Policy Framework (SPF)

Oh, but the Internet is full of horrors. Let’s imagine there is an evil actor, let’s call him Chuck, that wants to trick Bob into sending him his Harvest password.

That’s right, plain SMTP does not tell us if whoever is sending an email is who they say they are.

To protect our emails from this kind of attack, we can use Sender Policy Framework (SPF). When an email server receives a new email, they ask the source domain if the sender is allowed to send emails in their name. This is what SPF does; when Bob’s email server receives an email that is supposedly coming from alice.com it will first ask alice.com if the real sender, chuck.com, can send anything in their name.

In the image above, you can see that Bob’s server performs a DNS request. This technique and all the others in this blog post are all based on this protocol. When I write about Bob’s email server asking alice.com for some information, it just means sending a DNS request to alice.com looking for specific records.

If alice.com hasn’t listed chuck.com as one of its allowed senders, then Bob’s email server might tag the email as spam. You heard that right, it might do that or it may not. Bob’s server always has the last word and there are other checks to run before making a final decision.

DomainKeys Identified Mail (DKIM)

Emails should be safe now, right? Well... not entirely. We prevented Chuck from sending fake emails from his own servers but what would happen if he found a way to intercept in-transit emails? What if he was able to change the contents of Alice’s messages? Remember, SPF only verifies that the sender is allowed to send emails in her name, but it doesn’t say anything about what happens in their way to the recipient.

This is the perfect scenario to use signatures. In the digital world, a signature is a mechanism to ensure and verify that the contents of whatever is being delivered have not changed. When Alice sends an email to Bob, now Alice’s email server will add a signature to the contents of the email. If anyone changes just a single bit of that message, Bob will know. What's more, Alice's email server is the only one who knows how to create these signatures. No one else can do it without the receiver noticing it.

This is exactly what DomainKeys Identified Mail (DKIM) does. In practice, DKIM configuration starts in Alice’s email server:

  • There is usually a way to "start authenticating" sent emails. It usually means just enabling DKIM.
  • The email server will ask you to publish some cryptic words in your DNS; that’s your signature’s public key. In plain language, the public key makes it possible for others to verify that a signature they got is valid and that the message has not been modified in-transit. The server keeps the private key so that it's the only one able to create signatures.
  • Once the public key is published the email server will start sending a signature with every new email.

How is the signature useful? When Bob’s email server receives an email with an attached signature it can validate that the signature is correct. To do that, the server needs to retrieve the public key and the email contents. With only those two things, the server can detect if there has been some unwanted modification.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Now Bob can be pretty sure emails are coming from a trusted source and that they have not been tampered, right? RIGHT?... If only it’d be that easy... Chuck, our evil character, can still modify the contents of the email and just get rid of the DKIM signature. Who needs that anyway? It’s better to have a neutral check than having a negative one.

Not everything is lost, though. We just need a way to tell Bob’s email server what security measures have been configured and a policy that defines what to do if any of them fail. Let’s go for our last acronym: Domain-based Message Authentication, Reporting and Conformance (DMARC).

With DMARC, Bob’s email server has a public point of information defining what to do with emails it receives. More specifically, a DMARC record describes:

  • If SPF or DKIM are enforced in the receiving email
  • A reporting email address for monitoring purposes
  • A policy to decide what to do when there is a failing check. There are 3 different policies:
    • No policy - DMARC check results will be ignored. However, email servers will send reports for further analysis. This is often used while configuring DMARC to see if it’s working as expected.
    • Quarantine - Emails failing any DMARC check will be sent to the recipient’s spam folder.
    • Reject - Emails failing any DMARC check will not reach the recipient.

DMARC is the last piece in our toolbox, and it’s the only one that specifically tells email servers to discard non-compliant emails, and under what circumstances that happens.

Conclusions

We are happy to say that Harvest is using these techniques to protect our emails. It took us months of learning and collecting data until we finally got where we are now. We made it really difficult for others to impersonate us and undermine Harvest's reputation. This has been an incredible achievement that will impact our customers for good.