--- title: "How to Set Up DKIM: Selectors, Keys & Records (2026)" description: "Set up DKIM the right way: how signing works, choosing 2048-bit keys, finding your selector, and publishing the record. A 2026 guide — check yours free." publishedAt: 2026-07-09 tags: ["dkim", "dkim-record", "selector", "key-rotation", "setup", "email-authentication"] faq: - question: "What key length should a DKIM key be — 1024 or 2048?" answer: "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." - question: "How often should I rotate DKIM keys?" answer: "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." - question: "Can I have more than one DKIM record on a domain?" answer: "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." - question: "Why does my DKIM show dkim=none or 'not signing' in Microsoft 365?" answer: "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." - question: "My DKIM passes but DMARC still fails — why?" answer: "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." - question: "How do I find my DKIM selector?" answer: "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." --- # 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: `._domainkey.` (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](/learn/dkim/), 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. 1. **Generate a 2048-bit RSA key pair.** Use your mail platform's console, your ESP's domain-authentication screen, or `openssl` for a self-hosted server. The private key stays on the signing server; the public key goes into DNS. 2. **Choose your selector.** Accept the provider default (`google`, `selector1`, `s1`) or set your own short label. The selector is what lets one domain run several DKIM keys at once. 3. **Publish the public key in DNS** at `selector._domainkey.yourdomain.com` — a **TXT** record if you hold the key, or a **CNAME** if your provider hosts and rotates it (Microsoft 365, Amazon SES Easy DKIM, SendGrid, Mailchimp). 4. **Enable signing at your platform.** Flip the toggle: enable DKIM in Microsoft Defender, click **Start authentication** in Google Workspace, or authenticate the domain in your ESP. 5. **Verify.** Send a test message, read `Authentication-Results` for `dkim=pass`, and confirm the `d=` domain aligns with your `From:` domain. 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: If you would rather not touch the command line, [generate your key pair and record](/tools/dkim-generator/) 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.` 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. | Provider | Default selector(s) | Record type | Who rotates | | ----------------- | ---------------------------- | ----------- | ----------------------------- | | Google Workspace | `google` (custom prefix ok) | TXT | Admin (manual) | | Microsoft 365 | `selector1`, `selector2` | CNAME | Microsoft (96-hour switch) | | Amazon SES (Easy) | 3 SES-generated CNAME tokens | CNAME | Amazon SES (transparent) | | SendGrid | `s1`, `s2` | CNAME | SendGrid (Automated Security) | | Mailchimp | `k1` / `k2` / `k3` | CNAME | Mailchimp (managed) | ## 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: 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**](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) 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](https://www.m3aawg.org/DKIMKeyRotation) (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`. 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: Microsoft 365 only DKIM-signs mail routed through Exchange Online. If a CRM or app sends mail directly, enabling DKIM in Defender is not enough — route that stream through `smtp.office365.com` so it picks up the signature. A `dkim=none` in the `Authentication-Results-Original` header is also normal for non-forwarded mail; check the real DKIM result before assuming signing is broken. Prefer the browser? [Check your DKIM record](/tools/dkim-checker/) 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](/learn/spf/) and DKIM passing first, then publish [DMARC](/learn/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](/blog/bimi-record-setup/) 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 `you@yourdomain.com`, 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](/blog/dkim-alignment-failure-fix/). ## 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.