DKIM Configuration Guide
Set up DomainKeys Identified Mail (DKIM) to add cryptographic signatures to your emails.
Quick Overview
What is DKIM?
DomainKeys Identified Mail (DKIM, RFC 6376) attaches a cryptographic signature to outgoing email so that receivers can verify two things:
1. The message was authorized by the owner of the signing domain (the d= domain). 2. The signed parts of the message — selected headers and the body — were not altered in transit.
DKIM uses asymmetric (public-key) cryptography. Your mail server holds a private key and signs each outgoing message; the matching public key is published in DNS for anyone to fetch and verify against. Unlike SPF, which only checks the connecting IP, a DKIM signature is bound to the message itself and survives most relaying — which is why DKIM is the more durable of the two DMARC inputs, especially across mailing lists and forwarders.
How DKIM Works
1. When sending, your mail server canonicalizes a defined set of headers (From, To, Subject, Date, and others) plus the body, then computes a hash and signs it with the private key. 2. The result is added as a DKIM-Signature: header that records the signing domain (d=), the selector (s=), the signed header list (h=), the body hash (bh=), and the signature (b=). 3. The matching public key is published as a DNS TXT record at <selector>._domainkey.<d-domain>. 4. The receiver reads d= and s= from the header, fetches the public key from DNS, recomputes the body hash and header hash, and verifies the signature. 5. If the recomputed hashes match the signed values, DKIM passes (dkim=pass) and the result is recorded in Authentication-Results for DMARC to use.
Because the signature covers specific headers and the body, any modification to those parts after signing — for example a mailing list appending a footer — invalidates the signature.
DKIM Record Format & Tag Reference
The DKIM public key is a TXT record published at a selector-specific name. The selector lets one domain host multiple independent keys (per provider, or for key rotation):
| Tag | Meaning |
|---|---|
| v | Version, must be DKIM1 (recommended, first tag) |
| k | Key type: rsa (default) or ed25519 |
| p | Public key, base64-encoded (required; empty p= revokes the key) |
| t | Flags: t=y testing mode, t=s no subdomain delegation |
| h | Allowed hash algorithms, e.g. sha256 |
| s | Service type, * for all (default) or email |
# DNS name:
<selector>._domainkey.yourdomain.com
# Example TXT value:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...The selector is a name you choose (e.g. "google", "k1", "2026a"). Publishing each key under its own selector lets you rotate keys with zero downtime — add the new selector, switch signing, then remove the old one.
Generate Keys in Your Browser (No Server Sees Your Private Key)
Most DKIM guides assume your provider hands you a key. But when you run your own mail server (Postfix + OpenDKIM, exim, rspamd, Maddy, etc.) you must generate the RSA key pair yourself — and many online "DKIM generators" do this on their server, meaning your private signing key is transmitted to and seen by a third party.
IntoDNS.ai's DKIM Generator is different: it generates the 2048-bit RSA key pair entirely in your browser using the native Web Crypto API. The private key is created on your machine and never leaves it — nothing is sent to our servers. You get the private key to install on your mail server and the formatted public-key TXT record to publish in DNS. For a signing key, this in-browser, zero-transmission approach is the only safe way to use an online generator.
# What the generator produces:
# 1. Private key (PEM) — install on your mail server, keep secret
# 2. Public-key TXT record for DNS, e.g.:
mail._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF..."If a DKIM key generator runs server-side, assume the private key is compromised. Use in-browser (Web Crypto) generation, or generate locally with openssl, for any key your server will actually sign with.
Setting Up DKIM for Google Workspace
Google generates and manages the key for you — you only publish the public record:
1. Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email. 2. Select your domain and click "Generate new record". 3. Choose 2048-bit key length. 4. Copy the DNS host name (the selector, by default "google._domainkey"). 5. Copy the TXT record value. 6. Add the TXT record to your DNS. 7. After propagation, return and click "Start Authentication".
Google uses the selector "google" by default. If you regenerate the key, the selector changes (google2, etc.) — publish the new selector before switching, then verify dkim=pass.
Setting Up DKIM for Microsoft 365
Microsoft 365 uses CNAME records that point to Microsoft-managed keys, so the key material rotates on Microsoft's side without you touching DNS again:
1. Microsoft 365 Defender / admin center → Email & collaboration → Policies → DKIM (or Settings → Domains). 2. Select your domain and reveal the two CNAME targets. 3. Publish both CNAME records, then enable DKIM signing for the domain.
# CNAME record 1
selector1._domainkey.yourdomain.com -> selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
# CNAME record 2
selector2._domainkey.yourdomain.com -> selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.comVerify and Next Step
After publishing:
1. Allow DNS propagation (usually minutes to a few hours; up to 48h). 2. Send a test message and inspect Authentication-Results for dkim=pass, or use a tool like mail-tester.com. 3. Confirm the published record resolves and parses with our free DKIM Checker, which discovers common selectors and validates the record shape. 4. If you run your own server, generate and install your key with the in-browser DKIM Generator.
Common failures and causes: • Record not found — wrong selector name, or DNS not yet propagated. • Body hash mismatch (bh) — a forwarder or content filter modified the message after signing. • Key too short — 1024-bit keys are deprecated and increasingly rejected; use 2048-bit. • Duplicate/stale selector — an old key left in DNS can cause inconsistent verification; remove retired selectors after rotation.
With SPF and DKIM both passing and aligned, you are ready to layer DMARC on top to set policy and collect reports. For a deeper operational walkthrough with provider-specific selectors, key storage notes, and message-header verification, use the DKIM setup guide.
DKIM is what lets DMARC survive forwarding. Because the signature travels with the message, dkim=pass often holds where SPF breaks (e.g. mailing lists that change the envelope sender).
Common Pitfalls to Avoid
- Key not found in DNS
Check that the selector name and domain are correct. DNS propagation can take up to 48 hours.
- Using weak 1024-bit keys
Upgrade to 2048-bit keys. 1024-bit keys are considered insecure and may be rejected.
- Body hash mismatch
Content filters or forwarding servers may modify the message after signing.
- Not rotating keys
Rotate DKIM keys annually. Use a new selector to avoid downtime during rotation.
Related tools & guides
Frequently asked questions
What is DKIM and how does it work?
DKIM (DomainKeys Identified Mail) adds a digital signature to your emails using public-key cryptography. Your mail server signs outgoing emails with a private key, and the public key is published in DNS. Receiving servers verify the signature to confirm the email came from your domain and was not modified in transit.
How do I set up DKIM for Google Workspace?
In Google Admin Console, go to Apps > Google Workspace > Gmail > Authenticate email. Select your domain, generate a new record (2048-bit recommended), copy the DNS host name and TXT record value, add the TXT record to your DNS, wait for propagation, then click Start Authentication.
What is a DKIM selector?
A DKIM selector is a name that identifies the DKIM key (like "google", "mail", or "s1"). It allows you to have multiple DKIM keys for the same domain. The full DKIM record is stored at selector._domainkey.yourdomain.com.