What Is DKIM? Email Signing Explained Simply

What problem does DKIM solve for a sending domain?

DKIM, or DomainKeys Identified Mail, is an email authentication standard that stamps each outgoing message with a digital signature. Receiving servers check that signature against a public key published in your DNS, which shows the message came from your domain and that nobody altered it on the way.

Without a signature, anyone who knows your address can put your domain in the From line and send a fake invoice or a payment request. DKIM gives the receiver a way to tell a real message from a forgery, and to see that the body did not change after it left your server.

It does not encrypt mail and it does not stop every spam message. It proves two narrower things: the domain that signed the message authorised that signature, and the signed content arrived intact.

• A forged From address fails when the receiving server cannot match the signature to your published key.
• Content edited in transit produces a different body hash, so verification fails.
• Mail that passes DKIM is treated as more trustworthy than mail from an unauthenticated domain.

How DKIM signing and verification work

The sending mail server hashes the headers it selects and the body, signs that digest with a private key, and adds the result as a DKIM-Signature header. The matching public key sits in DNS, and the receiver fetches it by selector before rerunning the same hashes.

1. The sending server builds a body hash (bh) and a header hash over the fields it lists.
2. It signs both with the private key and writes the signature (b), the signing domain (d=), the selector (s=), the header list (h=) and the algorithm (a=) into the DKIM-Signature header.
3. The receiver reads d= and s=, queries s._domainkey.d in DNS, and retrieves the public key.
4. It recomputes the hashes and compares them. A match returns dkim=pass; any mismatch returns dkim=fail.

What a DKIM DNS record looks like

A DKIM record is a TXT record at selector._domainkey.yourdomain, for example default._domainkey.example.com. It publishes the public key only; the private key stays on the sending server and is never written to DNS.

The record itself is short, and the key is the long part:

default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

• v=DKIM1 is the record version and is always present.
• k=rsa names the key type; rsa is near-universal, while ed25519 is supported by some providers.
• p= holds the base64 public key, so a 2048-bit key gives a much longer string than a 1024-bit key.
• t=y marks a test record, and t=s tells receivers the domain must match exactly.

The DKIM-Signature header on the message is separate from this DNS record. It carries v=1, a=rsa-sha256, d= for the signing domain, s= for the selector, h= for the signed headers, bh= for the body hash and b= for the signature itself.

How DKIM aligns with SPF and DMARC

SPF checks the IP address that connected to deliver the mail; DKIM checks the signature inside the message. DMARC passes when at least one of them aligns with the domain in the visible From line, and its policy tells receivers what to do when neither does.

Alignment is the part most setups miss. If a message is signed with d=mail.provider.com while the From line says yourdomain.com, DKIM itself passes but is not aligned, so it does not satisfy DMARC until you sign with your own domain or use relaxed alignment.

• SPF authorises sending IPs in one TXT record at the domain root.
• DKIM signs the message content, so it can survive forwarding that breaks the sending IP check.
• DMARC publishes p=none, p=quarantine or p=reject at _dmarc.yourdomain and sends aggregate reports.

Publish them in that order and start DMARC at p=none so you can read the reports before you enforce anything. Our SPF and DMARC setup guide covers the record syntax and the reporting addresses.

How to enable DKIM on cPanel and Google Workspace

In cPanel, Email Deliverability installs the suggested DKIM record for the domain and turns signing on. In Google Workspace, the Admin console generates the key, your DNS host publishes the TXT record, and authentication starts only after the record resolves.

On cPanel:

1. Open Email Deliverability from the Email section.
2. Find the domain, check the DKIM status, and choose Install the suggested record if it is missing or invalid.
3. Note the selector (often default) and confirm the TXT record resolves before you send a test.

On Google Workspace or Microsoft 365:

1. In the Google Admin console, go to Apps, Google Workspace, Gmail, then Authenticate email.
2. Pick a 2048-bit key and a selector prefix such as google, then generate the record.
3. Add the TXT record at your DNS host, wait for the TTL, then click Start authentication.

If your DNS is managed for you, the support desk can add the record and confirm it resolves.

How to test whether DKIM passes

Send a message to a Gmail account you control, open it, choose Show original, and look for dkim=pass with header.d set to your own domain. A pass on your domain, not the provider's domain, is the result you want.

You can also query the record directly. Running dig TXT default._domainkey.example.com +short should return the v=DKIM1 string; an empty answer means the record is missing, at the wrong hostname, or still behind the old TTL.

• dkim=pass with your domain: the signature and the DNS record both work.
• dkim=pass with a provider domain: signed, but not aligned for DMARC.
• dkim=none: the message carries no signature at all.
• dkim=fail: key mismatch, an edited message, or a second TXT record at the same selector.

Two TXT records at one selector break verification because receivers may read the wrong key. Delete the stale record instead of adding a second one.

Why DKIM fails on forwarded and mailing-list email

Forwarding often rewrites the subject or adds a header, and any change to a signed field invalidates the signature. Mailing lists that edit the body or add a footer cause the same failure, even when the original sender configured everything correctly.

The practical fixes are a separate selector for each sending stream, relaxed canonicalisation (c=relaxed/relaxed) so small whitespace changes do not break the hash, and DMARC reporting so the failing path becomes visible. ARC seals help with some forwarders, but receiver support is uneven.

On WebJi® business email hosting, DKIM is generated inside cPanel and signed with your own domain, so mail sent through the server aligns with your From address.