How to Set Up a DKIM Record

If you want stronger email authentication, DKIM is one of the most important controls to configure correctly. It helps prove that an email message came from the claimed domain and was not altered in transit, which supports trust, deliverability, and protection against email spoofing. 

What is DKIM and how it works

DKIM, or Domain Keys Identified Mail, is an authentication method used to verify that a message was authorized by the sending domain and was not tampered with after it was sent. It does not encrypt the message. Instead, it adds a DKIM signature to the email header.

DKIM has four key components:

• Signature: added to the message header
• Public key: published in DNS as a TXT record or, in some platforms, via a delegated CNAME record
• Verification: the receiving system checks the signature against the DNS-published key
• Result: the message passes DKIM authentication

Once those pieces are in place, the next step is making sure they are configured correctly in your own environment. Setting up a DKIM record typically follows the steps below.

1. Assess Your Email Environment Before Creating a DKIM Record

Before making any DNS changes, audit your outbound mail flow. Many organizations send email from more than one system, such as Microsoft 365, Google Workspace, a CRM, a ticketing platform, or another email service provider. Some also route mail through a secure gateway or relay. 

In practice, configuration can vary by platform, so it helps to account for differences early. especially if your environment includes DKIM setup in Office 365 or needs to configure DKIM in Google Workspace as part of the rollout.

The first goal is to identify which system should sign outbound mail. In most cases, the DKIM signer should be the platform that actually sends the message to the recipient. If another mail server or secure gateway modifies the message after signing, the signature can fail even when the DNS is correct. 

This is one of the most common causes of broken DKIM setup in larger environments. If you manage multiple domains or a custom domain with several sending services, document all of them before you begin.

2. Gather the Prerequisites for DKIM Configuration

Before you configure DKIM, confirm access to the systems involved. You will typically need:

• Administrator access to the sending platform that manages the DKIM key
• Access to the DNS provider or domain registrar hosting the domain’s DNS
• The sending domain
• The DKIM selector
• The record type and value the platform provides

Some providers ask you to generate DKIM keys in the admin console. Others automatically create the key pair and simply ask you to publish the DNS value. Either way, capture the hostname and value exactly as shown. A small typo in the selector, host, or key value can break the entire DKIM configuration. 

It also helps to document your current SPF record and DMARC record status, since DKIM works best when all three authentication layers are aligned. See how Mimecast DMARC Analyzer can simplify monitoring, reporting, and enforcement across your domains.

3. Generate the DKIM Key Pair in Your Email Platform

Next, create or retrieve the DKIM values in your sending platform. The exact screens vary, but most platforms expose this in mail admin, security, or authentication settings.

At this stage, focus on two details: the DKIM selector and the public key or delegated host value. The selector becomes part of the DNS hostname, often in a format like:

selector1._domainkey.example.com

That selector must match the value the platform expects during DKIM signing. If it doesn’t, the receiving system won’t find the right key during lookup.

This is also where organizations may decide whether they need multiple DKIM records. That is valid as long as each sender uses a different selector and the records are managed cleanly.

4. Publish the DKIM Record in DNS

Now add the DNS record at the domain’s DNS host. In many cases, this is a TXT record containing the public key. In other cases, the platform may require a CNAME record that delegates DKIM to the provider. Follow the exact format your platform gives you.

A valid host usually includes the selector plus ._domainkey, and the value contains the DKIM parameters and key information. Before saving, check carefully for:

• Extra spaces
• Broken strings
• Incorrect quotation marks
• Publishing the record in the wrong DNS zone
• Using the wrong record type

Most providers let you keep the default TTL unless your organization has a specific DNS policy. Also expect some delay while the record propagates through the domain name system.

5. Enable DKIM Signing in the Sending Platform

Publishing the DNS entry does not complete the process. You must also enable DKIM in the sending platform so it starts signing outbound email.

Most platforms require you to return to the admin console after DNS is live and turn on signing for that domain. Without this step, the DKIM record may exist in DNS while real messages remain unsigned.

This is also the point where routing and policy matter. If a relay, secure gateway, or transport rule changes the body or key headers after signing, the signature may fail. That’s why it is important to align the signer with the real final sending point. 

6. Test and Verify That DKIM Is Working Correctly

After activation, verify both DNS and live message behavior. First, use a DNS lookup or DKIM record checker to confirm the selector resolves correctly. 

Second, send a test message to an external mailbox and inspect the message headers. Look for a DKIM-Signature in the email header and an authentication result showing DKIM pass. This distinction matters: a record existing in DNS does not guarantee that real mail is actually passing DKIM.

7. Troubleshoot Common DKIM Setup Issues

If DKIM is not working, start by checking the most common configuration problems:

• The wrong selector
• Incomplete or malformed key
• Record published in the wrong DNS zone
• Wrong record type
• DNS propagation has not fully completed

Compare the live DNS entry against the exact values generated by the sending platform. If the DNS side is correct, move on to mail flow. Failures at that stage are often caused by multiple outbound senders using the same domain without coordinated selectors. 

These can also be due to third-party tools sending mail without authorization, forwarding or security appliances rewriting the message after signing, or routing changes that bypass the intended signer.

These are usually operational issues rather than simple DNS mistakes, which is why setup DKIM should be treated as part of a broader governance and mail-flow management process.

8. Strengthen DKIM With SPF, DMARC, and Ongoing Governance

DKIM works best as one layer in a broader anti-spoofing strategy. DKIM signs the message, SPF   validates approved sending sources, and DMARC applies policy and reporting when authentication fails. Together, they support stronger sender validation and better email deliverability.

Ongoing governance matters too. Good hygiene includes:

• Monitoring authentication failures
• Reviewing unauthorized senders
• Updating documentation when senders change
• Rotating keys periodically
• Reviewing policies across multiple domains

As environments grow more complex, DKIM should be managed as an ongoing control, not a one-time task.

Correct DKIM setup supports trust and authentication

To understand how to set up DKIM, focus on the essentials: identify the right signer, gather the correct selector and key details, publish the DNS entry accurately, enable signing in the platform, and verify that real messages pass. Done correctly, DKIM helps protect message integrity, strengthen domain trust, and improve overall email authentication.

For organizations that want easier validation and better visibility into DKIM, SPF, and DMARC, Mimecast offers tools and services to simplify management.