Renuo – Trustworthy E-mails

E-mail Seals: How Mechanisms Protect Sender Authenticity

Have you ever wondered if the sender on the letter you just pulled from the mailbox is genuine? It would be easy to write a different name on the envelope, wouldn't it?

As far back as 2000 BC, people in Egypt wore signet rings, originally used to seal documents. Like in the Middle Ages, this practice was reserved for the upper class. Eventually, every bourgeois family had its own seal in the form of a family crest. The seal added a certain credibility to the letter, much like a signature. Thus, a letter with a seal or on high-quality stationery was considered genuine.

In the world of digital communication, email has largely replaced letters, and we now contend with spam and phishing. How do we verify the sender today? Imagine you own the domain "my-business.com". Who ensures that I, as an outsider, can't send an email under your name using [email protected]?

Mechanisms like SPF, DKIM, and DMARC attempt to provide a form of digital security by offering methods for sender authentication and verification.

SPF (Sender Policy Framework) specifies which servers are allowed to send emails on behalf of a particular domain. This is the most widely used method. In comparison to letters, it's like a list that all post offices can check upon receiving a message to verify if the sender is genuine. Each server has an IP address. For instance, it might look like two servers with IP addresses 123.4.5.6/7 are allowed, but all others are not.

  v=spf1 ip4=123.4.5.6 ip4=123.4.5.7 -all

In addition, DKIM (DomainKeys Identified Mail) can be used. This technique is less common but allows the sender to sign their email with a digital seal. The Internet works with the Domain Name System (DNS), a kind of internet phone book that contains information about a domain (e.g., my-business.com): the exact address (IP) of the server, or a key to verify this mail seal (a so-called DKIM-TXT record). This ensures that, for example, the attachment or content of the email has not been altered after sending. Public-key authentication is used for this. The message is signed by the sender with a private key. The DNS entry only knows the public key, which can be used to verify the seal. The private key remains private, so no one but the sender can sign messages. The mail server, such as Gmail, can now verify this seal upon receipt and check the message's trustworthiness.

The fact that such a TXT record can be stored at the domain “my-business.com” serves as proof that you are the owner of this domain. The key contains the type of encryption (in this case, RSA) and the public key (p=<key>).

DMARC is the final piece of the puzzle. This policy dictates how email servers should handle messages that fail SPF or DKIM checks. A typical DMARC policy is provided in a machine-readable format:

This rule states that emails failing the checks—since DKIM and SPF are set to "s" for "strict"—will be quarantined. In short, these policies help filter out unwanted emails and promote the delivery of authentic messages.

Why is this relevant for us at Renuo? When we develop applications for our clients, there is almost always a request to send emails. The sender should be from the respective domain, e.g., "[email protected]". To ensure we are authorised to send emails using your domain, we also use the mechanisms described above, so the emails don't end up in the spam folder.

How can you, as an end customer, verify that the email was indeed sent by the sender? Fundamentally, you can trust your email provider (like Gmail, Microsoft, etc.) to check these seals and either reject the emails outright or move them to the spam folder based on the configuration. This is akin to a reputable postman delivering only trustworthy mail to you. You can verify this yourself, though. By downloading the email as a *.eml file and opening it with a text editor, you can see the result in a machine-readable form.

The message might read as follows: The DKIM check (1) was successful. There was no SPF entry (2), so the check was neutral. DMARC was thus successful (3). According to the DMARC policy (4), the email would otherwise have been directly rejected by the recipient's (Google) server.

It's important to note that while these mechanisms help promote the delivery of authentic emails and reduce spam, they alone cannot protect against all types of email fraud. We should still be aware that a sender address is no guarantee of the actual sender. The described methods do not solve all problems—such as using a different address within a company—or prevent fraudsters from finding new tricks to deceive users. Our mailboxes won't be entirely spam-free anytime soon. But take it with a sense of humour—and, for example, be inspired by the following TED Talk on how to creatively respond to spam ;-)

This is what happens when you reply to spam email l TED

Trustworthy E-mails

E-mail Seals: How Mechanisms Protect Sender Authenticity

We are ready!Are you?

We are ready!
Are you?