How to Set Up DKIM: From Key Generation to a Passing DMARC Report

To set up DKIM, you generate a public/private key pair, publish the public key as a DNS record at selector._domainkey.yourdomain.com, and enable signing at your mail platform. The private key signs each outgoing message; receivers fetch the public key from DNS to verify it. That is the whole loop.

This guide is the single-page version of how to set up DKIM end to end — the part most guides scatter across a dozen URLs or lock to one vendor. It is for IT admins and founder-operators standing up DKIM, often under the Google and Yahoo bulk-sender rules in force since February 2024. You will get the 60-second mechanics, a five-step setup, a clear key-length decision, vendor-neutral rotation, verification, and the reason a published DKIM record can still fail DMARC.

How DKIM Works: Signing and Verification

DKIM (RFC 6376) lets a sending server attach a cryptographic signature to each message; the receiver fetches the matching public key from DNS and verifies that signature, proving the message was not altered in transit and came from a domain that authorized the signing.

The mechanics are short. Your private key signs a hash of the message body (bh=) and a set of chosen headers (h=), and writes the result into a DKIM-Signature header (b=). The d= tag names the signing domain and the s= tag names the selector, which together tell the receiver exactly where to look: <selector>._domainkey.<domain> (RFC 6376 §6). The receiver pulls the public key from that DNS host, recomputes the hashes, and confirms the signature. The point of all this is two guarantees — integrity (the signed content was not changed) and origin (a key-holder for d= signed it).

That is enough to set DKIM up. If you want the full conceptual model — how the hashing, canonicalization, and key model fit together — read what DKIM is and why it works, which is our canonical reference for the protocol.

How to Set Up DKIM in 5 Steps

DKIM setup is the same five steps everywhere: generate a key pair, choose a selector, publish the public key in DNS, turn signing on, and verify. Only the console you click through changes between providers.

For a self-hosted MTA, steps 1 and 3 are two openssl commands — generate the key, then export the public half as the single Base64 line DNS wants:

# 1. Generate a 2048-bit RSA private key — keep this secret, never publish it
openssl genrsa -out dkim-private.pem 2048

# 2. Derive the public key and strip it to the single Base64 line DNS needs
openssl rsa -in dkim-private.pem -pubout -outform DER 2>/dev/null \
  | openssl base64 -A

If you would rather not touch the command line, generate your key pair and record in the browser — free, no signup — and paste the output straight into DNS.

DKIM Selectors: How to Find Yours

A DKIM selector is the label in selector._domainkey.<domain> that points a receiver to the right public key, letting one domain run several keys — one per sender — at the same time. To find yours, read the s= tag in the DKIM-Signature header of a message you have already sent.

Two operational facts trip people up. First, you will often see two selectors (selector1/selector2, s1/s2) — that is the rotation pair, and both records must stay published. Second, every sending service gets its own selector: your Microsoft 365 mail, your Amazon SES app mail, and your Mailchimp campaigns each sign under a different selector, so each needs its own DKIM record. The defaults below are current as of 2026-06-26.

How to Create a DKIM Record (TXT vs CNAME)

To create a DKIM record, publish the public key your key generator produced as a DNS record at selector._domainkey.yourdomain.com — a TXT record if you hold the key, or a CNAME if your provider hosts and rotates it for you.

The choice comes down to who holds the key: if you generated and hold the private key (self-hosted, Google Workspace, or Amazon SES BYODKIM), publish the public key as a TXT record. If your provider manages the key (Microsoft 365, SES Easy DKIM, SendGrid, Mailchimp), it gives you a CNAME that delegates the lookup into its own DNS — for Microsoft 365, the two CNAMEs point into your tenant’s *.onmicrosoft.com zone.

The DKIM record format — tags explained (v, k, p, t)

A DKIM TXT record is a short list of tag=value pairs. Here is a worked example:

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

Each tag does one job (RFC 6376 §3.6.1):

• v=DKIM1 — the version. Recommended first, though receivers tolerate its absence.
• k=rsa — the key type. rsa is the default; ed25519 marks an Ed25519 key.
• p= — the Base64-encoded public key itself. An empty p= means the key has been revoked.
• t=y — the testing flag. While it is set, receivers must treat a failed signature no differently from unsigned mail — useful while you confirm signing, but remove it once you go live, or DKIM gives you no protection.

The body hash (bh=), signature (b=), and signed-header list (h=) live in the message’s DKIM-Signature header, not in this DNS record. Canonicalization (relaxed vs simple) controls how forgiving the hash is to whitespace changes — most setups never change it from the relaxed default.

DKIM Key Length: 1024 vs 2048 vs Ed25519

Use 2048-bit RSA. It is the cross-provider default and the NIST-backed baseline; 1024-bit is a compatibility floor to leave behind, and Ed25519 is promising but not yet safe to use on its own.

The standards are explicit. RFC 8301 §3.2 — the cryptographic update to DKIM — requires signers to use RSA keys of at least 1024 bits and recommends at least 2048, and bars verifiers from accepting anything under 1024. The broader crypto-policy authority goes further: NIST SP 800-131A Rev. 2 lists RSA as “disallowed if len(n) < 2048” and “acceptable if len(n) ≥ 2048.” The risk behind the rule is not theoretical — in a 2012 demonstration documented by M3AAWG (citing Wired), researcher Zachary Harris cracked a 512-bit DKIM key in roughly 72 hours for about $75 of cloud compute.

Ed25519 (RFC 8463) is real and worth adopting, but only as a second signature. Red Sift tested 19 mailbox providers and found only 9 of 19 (47%) validate Ed25519 signatures — and Gmail, Microsoft 365, and Yahoo are among those that do not (Red Sift, 2026-06-26). The standard accounts for this: RFC 8463 lets you dual-sign by publishing an RSA key and an Ed25519 key under separate selectors, so RSA-only receivers fall back cleanly. Note that Amazon SES documents RSA only, so SES is not a path to Ed25519 today.

DKIM Key Rotation: Why and How Often

Rotate DKIM keys about every six months — the M3AAWG consensus — using two overlapping selectors so verification never breaks. If your provider manages the keys, rotation is automatic, and your only job is to leave the selector records in place.

You rotate to limit the blast radius of a key that is ever exposed: a fresh key makes an old compromised one useless. The mechanics are the same two-selector overlap every time — publish the new selector’s key, switch signing to it, then retire the old selector once propagation completes. M3AAWG’s guidance (revised from quarterly to every six months in 2019, and still the operative best practice) keeps that cadence sane.

Match the work to your provider. Microsoft 365, SES Easy DKIM, SendGrid, and Mailchimp rotate for you — leave the records alone and they handle it (Microsoft’s rotation takes 96 hours to take effect once triggered). The two manual cases are Google Workspace and SES BYODKIM: put a six-month reminder on the calendar. Google Workspace is the sharper edge, because it holds one active key at a time, so a rotation there forces a brief, overlap-managed interruption rather than a clean hand-off.

Setting Up DKIM With Your Email Provider (Google Workspace, Microsoft 365)

Most providers generate the key for you — your job is to publish the records they hand you and turn signing on. The exception is Google Workspace, which makes you generate the key, publish a TXT record, and explicitly click Start authentication. The per-provider paths below were verified 2026-06-26.

• Google Workspace — Admin console → Apps → Google Workspace → Gmail → Authenticate email → Generate New Record (choose 2048-bit). Publish the google._domainkey TXT record at your DNS host, then click Start authentication. It is the manual outlier: Google does not auto-enable DKIM for a custom domain, so skipping that final click is the most common real-world gap.
• Microsoft 365 — outbound mail from your *.onmicrosoft.com address is signed automatically. For a custom domain, publish the two selector1 / selector2 CNAMEs (they point into your *.onmicrosoft.com zone), then turn DKIM on in the Defender portal under Email authentication settings. The default is 2048-bit.
• Amazon SES — Easy DKIM hands you three SES CNAME tokens, defaults to 2048-bit, and rotates transparently. BYODKIM lets you publish your own RSA key as a TXT record under a selector you choose, and rotate on your own schedule.
• SendGrid and Mailchimp — both use CNAME delegation (s1/s2, k1/k2/k3) with provider-managed keys and automatic rotation. One caveat for high-assurance domains: Mailchimp’s shared-key model means senders cannot manage or rotate their own private keys — Mailchimp’s infrastructure controls them.

How to Verify DKIM Is Working (Check Your DKIM Setup)

Verify DKIM by sending a test message and reading its Authentication-Results header for dkim=pass, or by querying the public key directly with dig +short TXT selector._domainkey.yourdomain.com.

# Fetch the public key your provider or generator published for this selector
dig +short TXT selector1._domainkey.yourdomain.com

# Confirm it returns a valid DKIM record (begins with v=DKIM1 and carries p=)
dig +short TXT selector1._domainkey.yourdomain.com | grep "p="

Then send yourself a test message and open the raw headers. A passing result looks like this — note dkim=pass, the header.s= selector matching what you published, and header.i=/d= matching your domain:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1 header.b=Ab1Cd2Ef;
       spf=pass (google.com: domain of bounce@yourdomain.com
         designates 203.0.113.10 as permitted sender);
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Prefer the browser? Check your DKIM record and it returns the parsed key and any problems in seconds.

Setting Up DKIM Alongside SPF and DMARC

DKIM, SPF, and DMARC work together: SPF (RFC 7208) authorizes the sending IPs, DKIM signs the message, and DMARC (RFC 9989) ties either one to your visible From: domain and tells receivers what to do on failure. Publishing all three is the baseline for the Google and Yahoo bulk-sender rules in force since February 2024.

The order of operations is straightforward: get SPF and DKIM passing first, then publish DMARC at p=none to watch the reports before you enforce. Once DMARC reaches enforcement, you can also set up BIMI to show your brand logo in supporting inboxes.

Why DKIM can pass but DMARC still fails (alignment)

A DKIM signature can verify and still fail DMARC if the signing domain (d=) does not align with your From:-header domain — DMARC checks identifier alignment, not just a valid signature.

This is the gap most setup guides skip. If your ESP signs with its own domain (say d=sendgrid.net) while your From: is [email protected], DKIM passes but DMARC’s DKIM check fails, because the two domains do not align. Relaxed alignment accepts a subdomain match; strict alignment demands an exact one. Fixing it means getting the sender to sign with your domain — the exact diagnosis is in our guide to why DKIM passes but DMARC still fails.

Frequently Asked Questions

What key length should a DKIM key be — 1024 or 2048?

Use 2048-bit RSA. RFC 8301 §3.2 requires at least 1024 bits and recommends 2048, while NIST SP 800-131A Rev. 2 disallows RSA keys below 2048 bits. Every major provider now defaults to 2048. Drop to 1024 only if a DNS host genuinely cannot publish the longer record.

How often should I rotate DKIM keys?

About every six months — the M3AAWG consensus, revised down from quarterly in 2019. Use two overlapping selectors so verification never lapses. Microsoft 365, Amazon SES Easy DKIM, SendGrid, and Mailchimp rotate automatically; Google Workspace and SES BYODKIM need a manual calendar reminder.

Can I have more than one DKIM record on a domain?

Yes. Unlike DMARC, which allows one record per domain, DKIM is keyed per selector, so a domain can publish many keys at once — one for each sending service. Each lives at its own selector._domainkey host, which is how several providers can sign mail for you simultaneously.

Why does my DKIM show dkim=none or ‘not signing’ in Microsoft 365?

Microsoft 365 only DKIM-signs mail routed through Exchange Online. If a CRM or app sends directly, enable DKIM in Defender and route that mail through smtp.office365.com. A dkim=none in the Authentication-Results-Original header is also normal for non-forwarded mail — check the real DKIM result first.

My DKIM passes but DMARC still fails — why?

DMARC requires identifier alignment, not just a valid signature. If the DKIM signing domain (the d= tag) does not match your From:-header domain, DMARC fails even though DKIM verified. Relaxed alignment allows a subdomain match; strict requires an exact one. See our DKIM alignment fix guide for the full diagnosis.

How do I find my DKIM selector?

Read the s= tag in the DKIM-Signature header of a message you have already sent — that is your active selector. Or use the known provider default: google for Google Workspace, selector1 and selector2 for Microsoft 365, and s1 and s2 for SendGrid.

Conclusion

To set up DKIM correctly, the chain is short and durable:

• Generate a 2048-bit RSA key pair (add Ed25519 only as a second signature).
• Publish the public key at selector._domainkey.yourdomain.com — TXT if you hold the key, CNAME if your provider rotates it.
• Enable signing, then verify dkim=pass in Authentication-Results.
• Confirm the d= domain aligns with your From: domain, or DMARC still fails.

Get those right and DKIM stops being the weakest link in your authentication stack — the one only 22.7% of domains have bothered to publish.