DKIM Explained for Beginners

Overview

DKIM stands for DomainKeys Identified Mail. In practice, it is a way to add a digital signature to outgoing email so receiving mail systems can check that the message really came from the domain it claims to come from and has not been altered in transit.

That sounds technical, but the idea is simple. When your mail server sends a message, it adds a signature. The recipient looks up the public part of that signature in DNS and compares it with the message it received. If the numbers match, the message has a valid DKIM signature. If they do not match, the message may still be delivered, but the receiving system has a reason to trust it less.

DKIM is not a spam filter. It does not guarantee inbox placement. It is one signal among many that helps mailbox providers decide whether an email is legitimate. A valid DKIM signature only shows that the message was signed correctly and that the content has not been changed in a way that breaks the signature.

How DKIM works in plain English

Think of DKIM as a tamper-evident seal.

Your sending system creates a private key and a matching public key. The private key stays on the sending system. The public key is published in DNS as a TXT record. When an email is sent, the server signs selected parts of the message using the private key. The receiving server then uses the public key from DNS to verify the signature.

If the signature verifies, the receiving system learns two useful things:

• The message was signed by a system that knows the private key for that domain.
• The signed parts of the message have not been changed since the signature was created.

That does not mean every DKIM message is trustworthy. A compromised account, a misconfigured sending service, or a malicious sender with access to a valid signing setup can still produce a valid signature.

What the DKIM DNS record contains

Most DKIM setups use a TXT record in DNS. The record is usually published under a selector name, which helps the sending system find the right key. A selector is simply a label, such as default or a provider-specific name.

The record normally includes:

• the selector
• the domain name
• the key type
• the public key value

You do not need to memorise the exact syntax to understand the concept. The important part is that the receiving server can look up the public key in DNS using the selector and the domain, then use it to check the signature.

Different providers structure DKIM records slightly differently. Some give you one record to paste into DNS. Others ask you to create two selectors for rotation. Some platforms manage DKIM for you behind the scenes. If your provider’s setup page gives specific values, use those instead of trying to invent your own format.

Why DKIM matters for different business types

Why DKIM matters for business email

For a business, DKIM is useful because it helps large mailbox providers see your messages as more trustworthy. It is especially important if you send mail from a branded domain such as yourcompany.co.uk rather than from a free email address.

Without DKIM, messages can still be delivered, but they may have less authentication evidence. That can matter more if you send newsletters, invoices, notifications, password resets, or other messages where reliability matters. If your messages are important to your business, you want as many trust signals as practical.

DKIM also helps with alignment for DMARC. DMARC usually checks whether the domain in the visible From: address aligns with either SPF or DKIM. If you later want to publish a DMARC policy, having DKIM configured correctly makes that much easier.

Common beginner mistakes

The most common mistake is treating DKIM as a one-time checkbox. It is a setup and maintenance item. If you change email providers, migrate DNS, or rotate keys, DKIM may need to be updated.

Another common issue is copying the record into the wrong DNS zone. If your domain uses a separate DNS provider from your registrar, the DKIM record must be added in the active DNS zone, not just at the registrar dashboard.

People also sometimes assume a DKIM pass proves the message is safe. It does not. It only proves the signature was valid. Phishing mail can still be signed if a legitimate account or service is abused.

Finally, some organisations publish DKIM but then break it by using systems that modify messages after signing. Footers, disclaimers, list management tools, forwarding services, and some security gateways can alter content enough to invalidate the signature. Provider behaviour varies here, so if a signature stops passing, check whether something in the message path is rewriting the email.

DKIM and DNS changes

DKIM is tightly linked to DNS because the public key lives there. That means DNS changes can affect email authentication in ways that are not always obvious.

If you switch name servers, change DNS providers, or rebuild records from scratch, make sure the DKIM TXT record is recreated exactly. A small typo, the wrong selector, or a missing quote in the value can make validation fail. Most mail systems will not explain the problem clearly, so it helps to verify the record with a DNS lookup tool after changes.

If your email provider supports multiple selectors, keep the old one active until you are certain no mail is still being signed with it. This helps during migrations and reduces the risk of message failures.

What DKIM does not do

DKIM does not send email for you. It does not create a mailbox. It does not prevent spam by itself. It does not replace SPF or DMARC.

It is one of the authentication layers that make email more reliable and more defensible. Used properly, it helps receiving systems trust your messages a little more. Used alone, it is incomplete.