DKIM Explained: How Email Signing Works

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to every email your domain sends, and any receiver can verify that signature against a public key you publish in DNS. A valid signature proves two things at once: the message really came from your domain, and nobody changed the signed parts along the way. For how this sits alongside SPF and DMARC, read Email authentication explained first.

The trick behind DKIM is asymmetric cryptography. Your mail server holds a private key that no one else has; the matching public key lives in a DNS TXT record for anyone to fetch. The standard is defined in RFC 6376, and since the public key is published as a TXT record, it depends on the DNS format from RFC 1035. The wider context lives in Email authentication explained.

The signing process

When your server sends a message, it runs a hash over selected headers and the body, then encrypts that hash with the private key. The result becomes a new header called DKIM-Signature, which the server inserts into the message. Inside that header you will find the domain that signed (d=), the selector (s=), the list of signed headers (h=), and the signature itself (b=).

Here is a trimmed example of what that header carries:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; h=from:to:subject:date; b=...

Nothing here is secret. The signature is meaningful only because it can be reproduced with the matching public key and not forged without the private key.

Selectors and where the key lives

A domain can run several keys at once, so DKIM uses a selector to say which one signed a given message. The receiver takes the selector from the header, prepends it to _domainkey, and queries DNS. For a message signed with selector mail2026 from example.com, the lookup is:

mail2026._domainkey.example.com

That record returns the public key. Selectors let you rotate keys and run multiple sending platforms without collisions, since each platform gets its own selector and its own record.

How verification works

The receiving server reads the DKIM-Signature header, fetches the public key at the selector's location, and recomputes the hash over the same headers and body the sender signed. If its computed hash matches the decrypted signature, the message passes. If a single signed byte changed in transit, the hashes diverge and verification fails.

Part	Where it lives	Who holds it	Job
Private key	On the sending mail server, kept secret	Sender only	Signs outgoing messages
Public key	DNS TXT record at selector._domainkey.domain	Published openly	Lets receivers verify the signature
Selector	The s= tag in the DKIM-Signature header	Travels with the message	Points to the right public key record
DKIM-Signature header	Added to the message itself	Travels with the message	Carries the signature and signing details

Why DKIM survives forwarding

This is where DKIM pulls ahead of SPF. SPF checks the IP address of the server making the connection, so the moment a message is forwarded through a new server, the check tends to fail. DKIM does not care which server relays the message. The signature lives inside the message and is verified against the original signing domain, so a forwarded email usually still passes, provided the signed headers and body were not rewritten. Some mailing lists do alter content (appending footers, for instance), which can break the signature, but plain forwarding generally leaves it intact. See SPF records explained for the contrast.

Key rotation

Keys should not live forever. Because each key has its own selector, rotating is straightforward: publish a new public key under a fresh selector, switch your server to sign with the new private key, leave the old selector in place for a while so in-flight mail still verifies, then retire it. Doing this on a schedule limits the damage if a private key is ever exposed.

A short checklist when you set DKIM up:

• One private key per sending platform, never shared by email.
• A public key published at the matching selector._domainkey record.
• Signed headers that include from, so the visible sender is covered.
• A rotation plan with overlapping selectors during the switch.

DKIM is strong on its own, but it reaches full value only when DMARC ties it to the visible From address. Read DMARC explained next, and check any domain's DKIM, SPF, and DMARC records free at domainintel.app.