Email is such a mess of technologies and standards, it’s hard to understand how everything works together. When it comes to SPF, DKIM, DMARC, there are some misconceptions.

The major misconception is around what SPF and DKIM actually do. Many people think that SPF and DKIM are somehow related to controlling who can send messages From your domain, but that’s not totally true.

The first thing to understand is that there are two email addresses in an email:

  • The From: header is what everyone is most familiar with. This is what you see in your email client as the sender.
  • The other is MAIL FROM which is usually invisible to users.

Envelope vs message

SMTP is the protocol used to send email. When using SMTP to send email, there are actually two parts.

The envelope (RFC 5321) is a set of properties that are provided to an SMTP server that defines who’s sending the message and where the message should be sent.

The message (RFC 5322) is the actual email message that you’re most familiar with: It contains email headers, content such as text and HTML, attachments, etc.

There’s some overlap here though. The envelope includes a property for MAIL FROM which is a bit like the From: header, and it also has a property for RCPT TO which is a bit like To: and Cc: headers.

The important thing to realise though is that they are completely different things. The properties in the envelope can be completely different from the related headers in the message itself.

This is how something like a BCC works: You can define a recipient in the envelope with RCPT TO but not list it in the message To: or Cc: headers. That results in the message being sent to the recipient, but no one would know (hence the “blind” in “blind carbon copy”) because there’s no record of it in the actual email body.

Similarly, the message envelope can be from an email address that is different from the From: header that you see in your email client.

So the envelope is a protocol thing; it helps SMTP servers route messages through the internet. The message is the actual thing you get into your email inbox that gets decoded and rendered to your screen as a user.

So what is MAIL FROM?

MAIL FROM in the envelope is there so messages can be returned in the case of errors such as a bounce. If a message bounces, then the SMTP server on the receiving end knows to return the message to the sender declared in the MAIL FROM. (As a user, you can usually see the value in the Return-Path header. Most mail servers will modify the message itself to add this header.)

In simple cases, the MAIL FROM and the From: header are the same. For example, if you send an email from your iPhone, then most likely the two values will be the same email address. If you send an email to someone and make a typo in their email address, then you get a bounce message back to your inbox.

But sometimes you might want to return messages to a different email address. This is really common today where services want to automatically catch and process bounces. For example, imagine if you’re sending a few million email newsletters – you’ll want to automatically catch and remove bogus email addresses so you don’t send to it next time.

This is often done by using a special mailbox where software can monitor emails and process them accordingly. For example:

MAIL FROM: <[email protected]>

From: [email protected]
To: [email protected]
Subject: My greate newsletter
...

The software might listen on emails sent to anything @bounce-detection.my-site.com and handle it.

SPF

SPF verifies that the server sending a message is allowed to send. A domain owner publishes a DNS record that declares the IP addresses of all the servers that are able to send from that domain. If SPF fails, then depending on the policy defined, the message might be classified as spam or dropped completely.

The key thing to recognise here is that this validation applies to MAIL FROM and not the From: header. As we discussed above, these are two completely different things. For example:

MAIL FROM: <[email protected]>
From: [email protected]

When a receiving server gets a message here, it will look-up the SPF record for bad-actor.com and verify that the server sending the message is published in the record. It doesn’t look at or care that the actual From: address is totally unrelated.

In other words, anyone can just go and buy a domain and validate their own SPF records. They can spoof the From: address that the user sees and the message would still pass SPF checks.

So SPF checking by itself doesn’t do much to prevent spam and spoofing, but it does make bad actors easier to trace and easier to handle once found.

DKIM

DKIM is a method to sign email messages in such a way where the receiving email server can verify the integrity of the message is valid.

An administrator or email provider has a secret private key that is used to generate a signature that gets added to the message. It looks a bit like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=foobar;
	...

The signature declares a domain (d) and a selector (s). To validate the message, you fetch the public key from $selector._domainkey.$domain – which is a TXT record. Using the public key you can verify the provided signature is valid.

Note that the domain can be anything here, which means DKIM also fails to prevent spam and spoofing because a bad actor can very easily just sign messages using his own key and publish it on his own domain.

But like SPF, it’s a tool in the toolbox. It makes it easier to track, and it has another benefit in that it guarantees the message integrity – the message you receive cannot have been modified by anyone else along the way.

Spam vs Spoofing

So SPF and DKIM are two methods that help validate who sent a message and verifies the who sent from a place they’re allowed to. This enables a kind of paper trail and tracking that would not otherwise be possible.

These technologies help email providers handle bad email because they make bad emails trackable. A bad actor needs to buy a domain and rent a server – and once someone figures it out, it can be banned very quickly. Additionally, brand new senders might be trusted less than senders that have online for years with a good track record.

The so-called reputation of your domain and sending server is important. For example, if Gmail detects a bunch of its users sending messages from your server to spam, then it might start to filter your messages more aggressively.

So SPF and DKIM can help with spam, but as we’ve seen, it does nothing to help with spoofing. A bad actor can very trivially buy a domain and configure SPF/DKIM, and send you an email with any From: address.

In practice, many email providers have special heuristics to detect spoofed messages. A lot of email providers might apply more stringent filtering to messages from a bank, for example.

Domain Alignment with DMARC

The main point is SPF and DKIM don’t address the problem of spoofing. As an end-user who gets an email into your inbox, you don’t know if the From: address you’re actually seeing is legit or not.

Well, that’s not entirely true. In some email clients, including Gmail, if the MAIL FROM doesn’t match the From: address, you’ll see a “via” tag. For example, From [email protected] via bad-actor.com. This does make things a bit more visible, but it’s a hack to workaround a failure in the protocol.

That’s where DMARC comes in. DMARC is a protocol that ensures the From: address is valid by specifying that the domain used in the SPF or DKIM validation step aligns with the From address.

DMARC requires SPF or DKIM to pass domain alignment. So at least one of these must exist and pass, and at least one must be aligned.

  • For SPF, domain alignment passes if the MAIL FROM domain matches the From: domain. For example, MAIL FROM: <[email protected]> is aligned with From: <john@example>.
  • For DKIM, domain alignment passes of the DKIM domain (d) is the same as the From:.

Every administrator can publish a DMARC policy in DNS that tells receiving email servers what to do when domain alignment fails. Increasingly, the policy is to quarantine (aka send to spam) messages that fail domain alignment.

Bottom line – use all three!

The bottom line is you need to use SPF, DKIM, and DMARC if you want to secure your domain from spoofers and spammers.