- How to change the PowerShell prompt - Wed, Mar 22 2023
- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
Mechanisms such as the Sender Policy Framework (SPF) or DKIM are used to verify the authenticity of a message and thus help to limit the misuse of email. If you take advantage of these techniques, they reduce the risk of your mail ending up in the recipient's spam folder.
Configuration depending on the mail system
Online services such as Gmail or Mailchimp usually take care of the DKIM configuration. The situation is different, however, if you use Microsoft 365. In this case, it is up to the customer to generate and store the DKIM keys.
To confirm the authenticity of an email, the sender (mail server, newsletter system, etc.) signs the message with the private key that is stored in the respective system. The recipient verifies the signature with the help of the public key, which he takes from the DNS entry of the sender domain.
Choosing the key generation tool
Some online tools simplify the process of generating the keys and compiling the required text strings for the DNS record. You just enter the name of your domain, and they will spit out the necessary data.
However, their use is not advisable for business environments because the operators of these services have access to the private key and its misuse cannot be ruled out.
Instead, it is possible to generate the keys yourself using OpenSSL. If you are working under Windows, however, you would have to install OpenSSL there first. You can avoid this if you have set up the Linux subsystem (WSL). For admins and web developers, the WSL is one of the best new Windows features in recent years and should not be missing on your workstations.
Invoking OpenSSL
If you choose Ubuntu as the Linux distribution, then it already contains a current version of OpenSSL. To generate the private key, enter the following command on the shell:
openssl genrsa -out contoso.private.key 2048
The key length of 2048 is common, but not mandatory.
Then generate the public key using:
openssl rsa -in contoso.private.key -pubout -out contoso.public.key
In our example, the contoso.public.key file contains the public key, encoded as Base64. For the DNS entry, however, you need it without the start and end markers and without line breaks.
If you don't want to remove them manually, you can send the file through the stream editor on the Linux shell and filter out the line feeds with tr:
sed 's/---.*---//' dkim.pub.key | tr -d '\n' | paste -d ' '
While you are entering the private key into the mail system, you will need the public key for the DNS.
Creating a TXT record in DNS
There, you create a TXT entry, the name of which is composed as follows:
Selector._domainkey.domain.tld
You can choose any selector (lower- and upper-case letters, numbers, and hyphens), but it makes sense to find a meaningful name for it. It could contain, for example, the year or the program that uses the key. Several such entries may be stored per domain, and they are distinguished from one another by the selector. An example could be:
newsletter2021._domainkey.contoso.com
Besides the name, you now need the value for the TXT record. It usually starts with the optional DKIM version, followed by the key type and value of the public key:
v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…
After saving the TXT record, you can test it with various online tools. One of them can be found, for example, at MXToolbox. However, these programs only check the existence and syntactical correctness of the DNS record.
The only way to find out whether the signing actually works is to send an email. If you send it to an address at Gmail or Outlook.com, for example, you can display the raw content of the message there. There should be a dkim = pass in the header.
Proof of a valid DKIM signature in the header of the received message
Subscribe to 4sysops newsletter!
A problem could arise when, for example, the messages go out via PHP mail. The order of the email header entries cannot be determined there; hence, the DKIM entry does not always come first, as recommended by the RFC.
nice post.. thankyou for write.