DKIM, short for DomainKeys Identified Mail, is an email authentication method that adds a digital signature to outgoing email. That signature allows the receiving server to check whether the message is really associated with the sending domain and whether its important parts were changed on the way. In practical terms, DKIM works like a technical seal placed on an email. If the signature verifies correctly, the recipient’s system gets a stronger signal that the message is legitimate and that its content has not been altered in transit.

At first glance, DKIM can look like just another obscure DNS setting. In reality, it is one of the key building blocks of modern email trust. If a company sends newsletters, transactional messages, automated emails or normal business mail from its own domain, DKIM quickly becomes important. It helps receiving systems decide whether a message is technically trustworthy, and it also plays a major role in broader email policies such as DMARC.

What DKIM actually does in practice

When a mail server sends a DKIM-signed message, it creates a cryptographic signature based on selected parts of the email, such as specific headers and the body hash. That signature is then inserted into the message header as DKIM-Signature.

When the email reaches the receiving side, the receiving server uses information from that signature to find the correct public key in DNS. It then checks whether the signature matches the message it received. If it does, that means the message is technically tied to the signing domain and that the signed parts were not changed in transit.

This is important because DKIM does not only say “this mail came from somewhere allowed”. It also helps prove that the message has kept its expected signed form on the way to the recipient.

Why DKIM matters

In modern email infrastructure, it is not enough to say “this message is from us”. That claim needs technical support. DKIM provides one of the main ways to do that.

Its practical value is easiest to see in four areas:

• trust – a valid signature makes the message more credible to receiving systems,
• integrity – if important parts of the message are changed in transit, the signature can fail,
• deliverability support – mailbox providers often use DKIM as one of several trust signals,
• DMARC readiness – DKIM is one of the core authentication methods DMARC builds on.

That does not mean DKIM alone guarantees inbox placement. It does not. But in practice, it is one of the core signals that serious senders are expected to have in place.

How DKIM works at a technical level

DKIM uses a key pair:

• a private key kept on the sending side, used to create the signature,
• a public key published in DNS, used by recipients to verify that signature.

The sending server signs the message with the private key. The recipient never sees that private key. Instead, the recipient queries DNS for the public key and uses it to verify the signature.

This is why DKIM is tightly linked to DNS. Without the correct DNS record, the recipient cannot retrieve the key needed for verification.

What a DKIM DNS record usually looks like

In many setups, DKIM is published as a TXT record in DNS. A typical example might look like this:

google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

Even though it may look confusing at first, the structure is fairly logical:

• google – this is the selector, the identifier of the key,
• ._domainkey – the standard DKIM namespace in DNS,
• example.com – the domain associated with the signature,
• TXT – the DNS record type,
• v=DKIM1 – the DKIM version,
• k=rsa – the type of key,
• p=… – the public key used for verification.

This is one of the reasons DKIM can look more intimidating than SPF at first. It is not just a list of authorised servers. It is a cryptographic verification record.

What a selector is and why it matters

The selector is one of the most important DKIM concepts because it identifies which exact key should be used to verify the message.

A single domain can use more than one selector at the same time. That is useful for key rotation, migration between providers or separating different sending systems.

Examples might look like this:

s1._domainkey.example.com
newsletter._domainkey.example.com
google._domainkey.example.com

In simple terms, the selector is the name of the specific key. If the message header says s=google, the receiving system knows it should look for the public key under google._domainkey.yourdomain.com.

What the DKIM-Signature header means

When DKIM is working, the delivered email usually contains a header similar to this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; h=from:date:subject:message-id:content-type; bh=abc123...; b=xyz456...

This is not the DNS record itself. It is the actual signature added to the email message. Some of the most useful parts are:

• v=1 – version of the signature format,
• a=rsa-sha256 – signing algorithm,
• d=example.com – the domain that signed the message,
• s=google – the selector used to find the key in DNS,
• h= – the headers included in the signature,
• bh= – the hash of the message body,
• b= – the signature value itself.

For practical debugging, three values are especially useful:

• d= tells you which domain signed the message,
• s= tells you which selector was used,
• p= in DNS contains the public key used to verify the signature.

Why some providers use TXT and others use CNAME

This is a common source of confusion. Many DKIM setups publish the public key directly in a TXT record. But some providers use a CNAME instead, so your domain points to a DKIM record managed on the provider’s side.

In practical terms, this means one provider may ask you to add a TXT record containing the public key directly, while another may ask you to add a CNAME that points to their managed DKIM endpoint.

Both approaches can be technically valid. The difference is mainly operational. With TXT, the key is published directly in your DNS. With CNAME, your DNS delegates that lookup to the provider’s DKIM infrastructure.

This is why DKIM setups can look different across services even when they are solving the same authentication problem.

Why 2048-bit keys and key rotation matter

In current mainstream practice, 2048-bit DKIM keys are generally preferred where the DNS provider supports them, because they provide stronger cryptographic protection than shorter keys. Some providers still allow 1024-bit keys in environments where DNS limitations make larger keys impractical, but the broader direction is clearly towards stronger key sizes.

Key rotation matters as well. Over time, organisations may need to replace DKIM keys for security, migration or operational reasons. This is another reason selectors are so useful. They allow one key to be introduced while another is still present, which makes the transition easier and safer.

How DKIM relates to SPF and DMARC

DKIM is often mentioned together with SPF and DMARC because the three belong to the same wider email authentication picture, but they do different jobs.

• SPF says which servers are allowed to send mail for a domain.
• DKIM adds a digital signature so the recipient can verify the message against a public key in DNS.
• DMARC builds on SPF and DKIM and adds policy and alignment rules around the visible sender domain.

In simple terms, SPF helps answer “was this server allowed to send?”, DKIM helps answer “was this message signed correctly and kept intact?”, and DMARC helps answer “does this all match the sender identity shown to the user?”

What can cause DKIM to fail

DKIM can fail for several reasons. A message may be modified in transit in a way that breaks the signature. The DNS record may be missing or published incorrectly. The wrong selector may be used. The sending system may sign with one domain while the published key is expected somewhere else.

In more complex email environments, failures can also appear during migrations, after DNS changes or when multiple sending platforms are involved and not all of them are configured consistently.

That is why DKIM issues are not always obvious from the sender’s side. A message may appear to have been sent normally, while the receiving system sees a signature problem that affects trust or DMARC alignment.

What DKIM does not guarantee

DKIM is valuable, but it does not prove everything. It does not confirm that a human sender is “honest” in a broader sense. It does not guarantee inbox placement. It does not solve list quality problems. And it does not replace SPF or DMARC.

It is best understood as a technical authenticity and integrity layer for email. That is already very important, but it is still only one part of the wider email setup.

Why this term is worth understanding even outside technical roles

DKIM is a good example of the fact that modern email is not only about writing a message and clicking send. Behind the scenes, there is also authentication, identity and technical trust.

If you understand what DKIM does, it becomes much easier to see why a message can look normal in the inbox and still fail technical checks, why email migrations sometimes create authentication issues, or why large providers put so much emphasis on properly signed mail.

That is why DKIM matters not only to mail administrators, but also to marketers, founders, e-commerce operators and anyone sending important email from their own domain. It is one of the main technical signals that separates a professionally authenticated sending setup from a weak one.

Related terms

• DNS – DKIM depends on DNS because the public key used for verification is published there.
• TXT record – the most common DNS record type used to publish a DKIM public key.
• CNAME – some email providers use a CNAME-based DKIM setup instead of publishing the key directly in TXT.
• Selector – the identifier that tells the receiving system which DKIM key it should use.
• SPF – another email authentication method that checks which servers are allowed to send mail for the domain.
• DMARC – the policy layer that builds on SPF and DKIM and checks alignment with the visible sender domain.
• Hostname – important in DKIM because the selector and _domainkey namespace create the DNS name under which the key is published.
• Public key – the key stored in DNS and used by recipients to verify the signature.
• Private key – the signing key kept on the sending side and never published in DNS.