DKIM

DKIM stands for DomainKeys Identified Mail. It is a method for email authentication. It allows a domain owner to take responsibility for a message by using cryptographic signatures. The sending mail server signs the message headers with a private key. The receiving mail server checks the signature using a public key published in DNS.

The purpose of DKIM is to verify that an email message was not changed after it left the sender and that the message truly comes from the claimed domain. It helps fight email spoofing and phishing attacks.

History and Background

The idea behind DKIM (DomainKeys Identified Mail) evolved from two earlier initiatives:

• Yahoo’s DomainKeys
• Cisco’s Identified Internet Mail

These efforts were merged and standardized by the Internet Engineering Task Force (IETF). The result was the first official version of DKIM, published as RFC 4871 in May 2007.

Before DKIM, email systems relied on simple protocols such as SMTP. They lacked several important features we now take for granted:

• Built-in message integrity checks
• Any way to confirm a message’s true origin

This left email vulnerable to abuse:

• Header forgery
• User impersonation
• Spam sent from fake domains

DKIM introduced cryptographic signing to email:

• It allows senders to sign their messages using a domain-associated private key
• Receivers can verify the message using a public key in DNS
• It doesn’t block spam directly but helps identify forged messages and aids spam filtering systems

In 2011, the IETF released RFC 6376, which:

• Replaced RFC 4871 as the current DKIM specification
• Clarified the signing process
• Enhanced protocol flexibility
• Improved interoperability with other email authentication standards like SPF and DMARC

DKIM remains a foundational tool in securing modern email communication and protecting domain reputation.

How DKIM works

The DKIM system uses a public and private key pair. The private key stays on the sending mail server. The public key is placed in the domain’s DNS records.

When a mail server sends an email:

• It creates a hash of certain header fields and the message body.
• It signs that hash with its private key.
• It adds the signature in a header called DKIM-Signature.

When the receiving mail server gets the email:

• It reads the DKIM-Signature header.
• It fetches the public key from the sending domain’s DNS.
• It verifies the signature using the public key.
• If the message was changed, the hash will not match, and the check fails.

The receiving server can then decide how to treat the message. It might mark it as spam, reject it, or accept it depending on the result and other factors.

DKIM header fields

The DKIM-Signature header includes several tags:

• v=: Version, usually set to 1.
• a=: Algorithm, usually RSA with SHA256.
• d=: Domain that signed the message.
• s=: Selector that points to the DNS record.
• h=: List of signed headers.
• bh=: Body hash.
• b=: The actual signature.

An example DKIM header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025;

h=from:subject:date:to;

bh=F0Y2...Xw=;

b=MEUCIQDX...IDAQAB

Selectors and DNS records

The selector is a string that helps locate the public key. It allows domain owners to rotate or manage keys without changing the domain.

For example, if the selector is mail2025, the public key DNS record would be at:

mail2025._domainkey.example.com

That DNS record contains a text entry with the public key:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...

The v=DKIM1 confirms the DKIM version. The k=rsa tells the algorithm. The p= field holds the public key itself.

DKIM and message Integrity

DKIM protects only the parts of the message it signs. Usually, this includes headers like From, To, Subject, and Date. It may or may not include the message body, depending on configuration.

If a mail transfer agent modifies a message after signing, the DKIM check will fail. For example, some mailing lists add footers or change subject lines. These changes break the signature unless the system is configured to ignore those fields or use relaxed canonicalization.

Comparison with SPF

DKIM and SPF (Sender Policy Framework) both help verify email. They work in different ways.

Feature	DKIM	SPF
Based on	Message contents	IP address of sending server
Uses DNS	Yes	Yes
Signs content	Yes	No
Can survive forwarding	Yes	No
Affects body	Yes	No
Common failures	Header changes, body edits	Email forwarding

DKIM stays valid through forwarding as long as the body and headers do not change. SPF usually fails if the message passes through an unapproved server.

DKIM and DMARC

DKIM becomes more useful when used with DMARC (Domain-based Message Authentication Reporting and Conformance). DMARC checks that the DKIM signature is valid and that the domain in the From header matches the domain in the DKIM signature.

Without DMARC, DKIM gives a pass or fail result. With DMARC, the domain owner can publish a policy that tells receivers what to do with failed messages. It can also request reports that help monitor spoofing attempts.

A valid DKIM signature that aligns with the From domain contributes to a pass under DMARC.

Advantages

• Authentication - DKIM adds a way to prove that an email really comes from the claimed sender.
• Message Integrity - If anyone changes the email, the signature breaks. This helps detect tampering.
• Domain Reputation - DKIM helps build a good reputation for sending domains. It shows that the domain takes security seriously.
• Survives Forwarding - Unlike SPF, DKIM can still work if the message is forwarded, as long as the content remains the same.
• Works With Filters - Many spam filters check DKIM results. A valid signature can improve deliverability.

Limitations

DKIM does not stop spam. A spammer can sign messages with their own domain. DKIM only proves who sent it, not whether it is wanted.

DKIM also fails if the email content changes. Some legitimate servers change subject lines or footers. These changes break the signature unless the configuration accounts for it.

DNS records must be public. This can expose key management details. Keys must be rotated and protected like any other security asset.

Key management

Keys must be long enough to resist attacks. Most domains now use 2048-bit RSA keys. Shorter keys, like 512-bit or 1024-bit, are no longer safe.

Domains should rotate keys often. This helps limit damage if a key leaks. Rotating keys involves publishing a new selector and updating the sending system.

It is common to use a separate selector for each mail system. This makes it easier to manage keys and isolate systems.

Common problems

• Missing DNS record: If the public key is missing or misconfigured, DKIM fails.
• Mismatched selector: If the selector in the email does not match any DNS entry, verification fails.
• Corrupted headers: Some email clients change header formatting. These changes can break signatures.
• Large emails: Some systems truncate large messages. If the truncated content affects signed parts, DKIM fails.

Use cases

DKIM is used by:

• Email providers like Gmail, Yahoo, and Outlook
• Online shops to prevent spoofing
• Banks and financial services to protect users
• Mailing list managers that preserve message content
• Any domain that sends transactional or marketing email

Adoption

Most large providers now check DKIM. Gmail shows a "signed by" line in its interface if the check passes. Many services reject unsigned or failed messages if DMARC is in place.

DKIM is also required by some security programs. Starting in 2024, Gmail and Yahoo began requiring DKIM or SPF for bulk senders. This change aims to reduce fraud and phishing.

DKIM support with NTC Hosting

NTC Hosting supports DKIM across its range of Hepsia Panel-powered hosting services - web hosting, VPS, semi-dedicated servers, and dedicated servers. This support enables users to enhance their email security by implementing DKIM signatures for outgoing emails.

By utilizing DKIM, users can ensure that their emails are authenticated and trusted by recipients, thereby improving deliverability and protecting their domain reputation.