What Is DKIM?

DKIM, short for DomainKeys Identified Mail, is an email authentication standard defined in RFC 6376. It lets a receiving mail server verify two things about a message: that it was genuinely authorized by the domain claiming to send it, and that the signed parts were not altered along the way. Your sending server signs each outgoing message with a private key it keeps secret, and receivers fetch the matching public key from your DNS to check that signature.

This article explains the concept end to end. If you want to act on it, see how to set up DKIM, and use the DKIM record checker to inspect any published key.

The Core Idea: A Signature You Cannot Forge

DKIM is built on public-key cryptography. A key pair has two halves that are mathematically linked. The private key stays on your sending infrastructure and never leaves it. The public key is published openly in DNS. Anything signed with the private key can be verified by anyone holding the public key, but only the holder of the private key can produce a valid signature. That asymmetry is what makes DKIM trustworthy: publishing the public half is completely safe, and the private key never appears in DNS.

For deliverability, DKIM is one of the strongest signals you control. Mailbox providers weigh it, together with SPF and DMARC, when deciding whether mail from your domain is trustworthy. It does not prove recipients want your mail, only that the message is authentic and unmodified, but it is effectively a prerequisite for landing in the inbox.

How the Signing Flow Works

When your mail server or email service provider sends a message, it adds a header called DKIM-Signature. The signer first normalizes the message, a step called canonicalization, so harmless changes such as whitespace adjustments do not break verification. It then performs the following:

• Computes a hash of the message body and stores it in the signature's bh= tag.
• Hashes a chosen set of headers together with the signature header itself.
• Signs that hash with your private key; the result becomes the b= tag.

The header also records which domain signed the message in d=, which selector to use in s=, and which headers were covered in h=. A simplified DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
  h=from:to:subject:date; bh=K7xQ...=; b=Z9rT...AB

What the Receiver Does

On arrival, the receiving server reads those tags, builds the DNS name by joining the selector, the literal label _domainkey, and the signing domain, and fetches the TXT record published there. With the public key in hand, the receiver recomputes the body hash and the header hash itself and checks them against the signed values.

If they match, DKIM passes. If anything covered by the signature changed in transit, or the DNS record is missing, malformed, or holds the wrong key, DKIM fails. This is why forwarding through a mailing list that appends a footer, or a gateway that rewrites links, can break an otherwise valid signature: the body no longer matches the body hash.

Selectors: Why They Exist

A selector is the label that tells receivers where in your DNS to find the right public key. It forms the first part of the record's hostname: in mail._domainkey.example.com, the selector is mail. Selectors exist so one domain can publish many keys at once. Without them, seamless key rotation would be impossible and only one service could ever sign for the domain.

Because each key lives under its own selector, a domain can run several services side by side, each signing with its own key. The one thing to avoid is two TXT records under the same selector hostname, which makes the lookup ambiguous and breaks verification.

Finding Your Selector

The most reliable way to find your selector is to inspect a real message. Send yourself an email from the system you want to test, open the full message headers (often called Show Original), locate the DKIM-Signature header, and read its s= tag. That selector, combined with the domain in the d= tag, is exactly what a checker needs. Provider conventions also help: Google Workspace uses the selector google by default, and Microsoft 365 uses selector1 and selector2.

The Public Key Record in DNS

The public key is published as a TXT record. A typical record, with the key shortened for readability, looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...IDAQAB

v=DKIM1 declares the record version; it is optional, but when present it must come first. k=rsa states the key type, which is the default. p= carries the public key itself as base64 text and is by far the longest part of the record. An empty p= value, defined in RFC 6376, is an explicit statement that the key has been revoked. Modern keys should be 2048-bit RSA per RFC 8301's recommendation, and modern signatures use rsa-sha256 since SHA-1 has been retired.

Alignment With the From Domain

A valid DKIM signature is not the whole story. DMARC requires alignment: the domain in the signature's d= tag must match your visible From domain, either exactly under strict alignment or by sharing the same organizational domain under the default relaxed mode. If your provider signs with its own domain rather than yours, the signature is perfectly valid but unaligned, and DMARC disregards it. This is the common cause of DKIM passing while DMARC fails. The fix is almost always enabling custom-domain signing with your provider so the d= value carries your domain.

Aligned DKIM is also what makes DMARC survive forwarding, where SPF frequently breaks. That resilience is why DKIM is worth getting right.

Where to Go Next

You now know what DKIM proves, how the signature and public key fit together, and why selectors and alignment matter. To publish your own key, follow how to set up DKIM, and confirm the result with the DKIM record checker.