Operating and managing a remote server located in a data centre is often carried out by using a secure network connection provided by the SSH protocol. The necessary registration on the server is preceded by an authentication process. Usually this occurs in the form of the username and password. Alternative methods such as the public key authentication used by SSH, do have their advantages. But...
All reputable email servers try to block emails with forged sender addresses. Scammers use spoofed sender addresses that appear to come from a legitimate source in order to plant a Trojan or trick the user into revealing sensitive data – a process called phishing.
One way to verify the authenticity of the sender is to use DKIM, a method that allows you to digitally sign emails. DKIM stands for DomainKeys Identified Mail.
Widely used today, DKIM was initially created in 2004 as a collaborative effort by a consortium of companies. DKIM combines Yahoo’s earlier “DomainKeys” and Cisco's deprecated “Identified Internet Mail” systems. Hence, the abbreviation DKIM: DK = DomainKeys, IM = Identified Internet Mail.
How DKIM works
DKIM is based on the communication between the outbound and inbound mail server. The end user is not aware of this process.
Put simply, the outbound mail server affixes a digital signature to the email. That signature is then verified by the inbound server. To do this, the inbound server looks up the public key that matches the signature from the mail server that is specified as the sender.
The public key may not match the signature for the following reasons:
- The email was not sent from the mail server specified in the email header but was sent from another (fraudulent) server instead.
- The email was changed in transit from the "real" mail server to the recipient. For example, a hacker could intercept the email, change it, and then resend it.
The technical components of DKIM
In order to understand DKIM, it's best to look at the underlying building blocks of the concept.
A string called the hash value is calculated from the contents of the email using a specific algorithm. This value is added to the header of the email.
Hashing is based on the same principle as the check digit on a bank deposit slip, whereby a value is calculated from the digits of the reference number and is added as the last digit of the reference number.
If the recipient calculates the hash value of the received email using the same algorithm, then the recipient should receive the exact same string that was added to the email header. If the hash value doesn’t match, the recipient knows that the email has been changed.
Another step is required so that the recipient can be sure that the hash value actually comes from the original sender: the digital signature.
Senders are authenticated using asymmetric encryption, which is based on a key pair: something encrypted with key A can only be decrypted with key B. One key is kept secret (private key), the other is published (public key).
For more detailed information on encryption, see this summary of encryption methods.
The process looks like this:
- The sender encrypts the calculated hash value with the private key.
- It adds the encrypted hash value to the email header ("signature").
- The receiver looks up the sender’s public key on the sender’s domain name server, thereby decrypting the signature.
- It then checks the decrypted hash value. If the hash value calculated by the receiver matches the decrypted one, everything is fine.
TXT record on the name server
In order for inbound mail servers to retrieve the sender's public key, it must be published as a TXT resource record in the domain's DNS zone.
The DKIM record contains the following elements:
- The version, often encoded with v=DKIM1
- The encryption algorithm, which is always RSA (k=rsa).
- The public key (p=); which is a long string.
- The selector, which differs according to provider. Example: default._domainkey or k1._domainkey
The DKIM record can usually only be retrieved using the email header. Both the domain name and the selector are required for the lookup. The selector is usually not known or is too time-consuming to find.
Creating a DKIM record
To create a DKIM record, you have to create an RSA key pair and place it in the correct location on the server. Most email providers will do this for you.
See our help section to learn how to configure a DKIM record for your IONOS email account.
To better understand how DKIM works, you can create a record manually. Various tools are available free of charge on the Internet, such as the DKIM Record Generator by EasyDMARC. At the top of the screen, enter a selector of your choice (such as k1) on the left and a domain on the right. The generator displays a private and a public key. The private key must be stored on the mail server (this can only be done by your email provider), and the public key is entered in the DKIM record.
Checking the DKIM record
You can check whether the DKIM record is actually publicly available by using a DKIM checker such as DKIM Record Lookup by EasyDMARC.
But the easiest way to check is by sending yourself an email and then looking at the header, where you’ll see the entry “DKIM-Signature:”
You can copy the header to a header analyser tool to view clearer, more detailed information about the email header.