Configuring DKIM within DNS

This blog post is about configuring DKIM within DNS. We need to set up DKIM within DNS because otherwise forged addresses and content can be easily created. I see many forged addresses appear in spam, phishing, and other email fraud. For example, a fraudster can send a message claiming to be from sender@example.com. The goal is to convince the recipient to accept and read the email. However, it is difficult for recipients to determine whether they can trust this message. System administrators also have to deal with complaints about malicious emails. These emails appear to have been sent from their systems but were not.

DKIM provides the ability to sign a message and allows the signer (such as the authoring organization) to communicate which email it considers legitimate. However, it does not directly prevent or reveal abuse.

In addition, DKIM provides a process for verifying a signed message. Verification modules typically act on behalf of the receiving organization, possibly at every step.

All of this is independent of the Simple Mail Transfer Protocol (SMTP) routing aspects, as it works on the RFC 5322 message—the header and body of the transported email—and not on the SMTP “envelope” defined in RFC 5321. Therefore, DKIM signatures survive basic relaying through multiple message transfer agents.

Technical details and operation of configuring DKIM within DNS

When a receiving SMTP server wants to verify, it uses the domain name and the selector to perform a DNS lookup. For example, the d-tag indicates the author’s domain that the server can verify, such as example.net. The s-tag indicates the selector, such as brisbane.

An example of a DKIM signature can be found below.

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
t=1117574938; x=1118006938; l=200;
h=from:to:subject:date:keywords:keywords;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR

Tags used for DKIM signature

v (required), version

a (required), signing algorithm

d (required), Signing Domain Identifier (SDID)

s (required), selector

c (optional), canonicalization algorithm(s) for header and body

q (optional), default query method

i (optional), Agent or User Identifier (AUID)

t (recommended), signing timestamp

x (recommended), expiration time

l (optional), body length

h (required), header fields – list of those that are signed

z (optional), header fields – copy of selected header fields and values

bh (required), body hash

b (required), signature of headers and body

The string _domainkey is a fixed part of the specification. This means that the TXT resource record must be looked up as brisbane._domainkey.example.net. It is important to note that the selector and domain name can be UTF-8 in internationalized email. In that case, the system must encode the label using IDNA before lookup. The data returned by querying this record is also a list of tag-value pairs. This list includes the domain’s public key, along with other key usage tokens and flags. For example, from a command line: nslookup -q=TXT brisbane._domainkey.example.net.

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

Available tags include

v (recommended), version (default DKIM1, must be the first tag if present)

h (optional), acceptable hash algorithms (default all)

k (optional), key type (default rsa)

n (optional), readable comments from the administrator

p (required), public key data (base64 encoded, or empty if the public key is revoked)

s (optional), service type (default *, otherwise email)

t (optional), toggle flags (colon-separated list, default none, may include y for testing DKIM without rejecting failed signature verifications, and/or s which is recommended for subdomain strictness as explained in the RFC)

A CNAME record may also be used to point to another TXT record, for example, when one organization sends email on behalf of another.

This way, DKIM ensures email authentication is accurate and reliable, using specific tags and methods to ensure the integrity of the message.

Steps configuring DKIM within DNS

Preparation

1. Check your email server: Make sure your email server supports DKIM. Most modern email servers, such as Postfix and Exim, have built-in DKIM support.
2. Generate a DKIM key: Use a tool like openssl to generate a public and private key pair. The public key is added to your DNS records, while the private key is used by your email server to sign emails.

Configure DNS records

1. Create a TXT record: Add a TXT record to your domain’s DNS zone. This record contains the public key you generated.
2. Publish the record: Ensure the TXT record is correctly published and accessible to email recipients.

Configure email server

1. Install DKIM software: Install a DKIM milter (mail filter) such as opendkim on your email server.
2. Configure the DKIM milter: Add the configuration to your email server to add DKIM signatures to outgoing emails.

Test the configuration

1. Send a test email and check whether the DKIM signature is correctly added.

Setting up DKIM for Office 365

Preparation

1. Log in to the Microsoft 365 admin center: Go to admin.microsoft.com and log in with your admin account.
2. Go to the Exchange admin center: Navigate to Admin centers > Exchange.

Generate DKIM keys

1. Open the DKIM page: Go to Mail flow > DKIM.
2. Select your domain: Choose the domain for which you want to enable DKIM.
3. Generate the DKIM keys: Click Enable to generate the DKIM keys.

Add DNS records

1. Log in to your DNS hosting provider: This could be Cloudflare, GoDaddy, or another provider.
2. Add CNAME records: Add the following CNAME records to your DNS settings:
   • Name: selector1._domainkey Value: selector1-<domain>._domainkey.<domain>.onmicrosoft.com
   • Name: selector2._domainkey Value: selector2-<domain>._domainkey.<domain>.onmicrosoft.com
3. Publish the records: Ensure the DNS records are correctly published.

Enable DKIM

Enable DKIM: Click Enable for the domain for which you added the CNAME records.

Return to the DKIM page: In the Exchange admin center.

In practice

For example, on the internet I find many posts from people who have become quite frustrated. In their view, Microsoft support does not solve it. What kinds of things are these people (and I myself) running into?

For example, on the internet I find many posts from people who have become quite frustrated. In their view, Microsoft support does not solve it. What kinds of things are these people (and I myself) running into?

More information about Microsoft Exchange Server can be found here. More information about the author of this blog post can be found here.