Should I change my DKIM records for DKIM2?
Published 9 Jul 2026
Updated 9 Jul 2026
11 min read
Summarize with
No, do not change working DKIM records just because a DKIM generator, checker, or setup screen mentions DKIM2. In most current setups, DKIM2 means a second DKIM selector, a second provider-managed key slot, or a label used by a platform during domain verification. It is not a universal instruction to replace your existing DKIM TXT or CNAME records.
Change DNS only when the system that signs your mail gives you exact record names and values. That means the provider has a private key ready, has configured its signer to use that selector, and expects your public key or CNAME to exist at a specific DNS name. Without that signer-side change, editing DNS does nothing useful. In the worst case, it breaks authentication for mail that was already passing.
Treat DKIM2 as a provider-specific label until proven otherwise. If a provider tells you to add two records, add both. If a checker simply displays DKIM2 because it found a draft, template, or second selector option, leave DNS alone until your mail platform tells you exactly what to publish.
What DKIM2 usually means
DKIM works by adding a signature header to each message. The receiver reads the signing domain and selector from that header, then queries DNS for the public key. The selector is the part that lets one domain publish more than one DKIM key at the same time. A second selector is normal. It is how providers rotate keys, keep backup keys ready, or separate different sending systems.
A four-step DKIM selector lookup flow: sender signs, selector named, DNS key, receiver verifies.
This is why DKIM2 does not automatically mean a new protocol. A record named by a provider as DKIM2 usually points to the second key for the same signing service. Microsoft 365 commonly uses two selectors, while other platforms use names such as DKIM1 and DKIM2. The names matter less than the exact host and value the provider gives you.
- No action: A checker mentions DKIM2, but your current mail passes DKIM and DMARC.
- Add a record: Your provider gives a second selector with an exact TXT or CNAME value.
- Rotate a key: Your provider or mail server is ready to sign with a new selector.
- Replace nothing: A second DKIM record is usually additive, not a replacement for the first key.
The newer DKIM2 standards work is separate from these everyday selector labels. It is worth tracking if you run mail infrastructure, write milter integrations, or own signing software. It does not mean every domain owner needs to edit DNS today. For background on the draft work, see the DKIM2 draft.
Provider examples
The safest answer depends on who signs the message. The DNS record is only the public half of the key setup. The private key lives with Google Workspace, Microsoft 365, an ESP, a SaaS sender, or your own mail server. If the signer is not changed, the receiver never asks for the new selector.
Google Admin console DKIM authentication screen with selector and record generation controls.
|
|
|
|---|---|---|
 Google Workspace | New selector or key | Use Admin console value |
 Microsoft 365 | Second selector | Publish CNAME pair |
ESPs | Backup key | Add provider record |
SaaS senders | Sender-specific key | Do not reuse keys |
Custom mail | Your selector | Rotate with overlap |
Common DKIM2 interpretations by sender type.
For Google Workspace, I would not invent a DKIM2 record. Google signs with the selector configured in the Admin console. If Google tells you to generate a new record, publish that exact DNS value, wait for it to resolve, and then start authentication. If your existing selector is passing, leave it in place during any transition.
For Microsoft 365, two selectors are normal. Microsoft uses CNAME records so it can rotate the underlying public key without asking you to edit DNS each time. Some Microsoft setup flows and related services describe DKIM1 and DKIM2. Follow the values in the tenant or service portal, not a generic blog template. Microsoft has a useful example in its DKIM2 setup thread, but the portal value for your domain is the source of truth.
For ESPs and SaaS senders, add the DKIM records each sender provides. Do not point a SaaS sender at your Google or Microsoft selector. Each sender needs its own key material and its own signing configuration. A working setup can have many selectors under the same domain, as long as each selector has one correct record and the DKIM signing domain matches the visible From domain for DMARC.
Why provider instructions matter
A DKIM record is not a standalone switch. It has to match the selector in the DKIM-Signature header and the private key used by the signer. Provider instructions matter because they control both sides of that match. The DNS host name, record type, target, key length, selector name, and timing all come from the sending platform.
Change only DNS
- Missing signer: No outgoing server uses the new selector.
- Wrong key: DNS has a public key that matches no private key.
- Broken record: A CNAME or TXT record is added at the wrong host.
Change signer and DNS
- Matched selector: The header and DNS lookup use the same name.
- Matched keys: The public key verifies the private key signature.
- Clean rollout: Old and new selectors overlap long enough for delivery.
Example provider-managed DKIM CNAMEsDNS
s1._domainkey.example.com. CNAME s1-example._domainkey.provider.net. s2._domainkey.example.com. CNAME s2-example._domainkey.provider.net.
That example shows why copying someone else's DKIM2 value is risky. The visible shape is common, but the target belongs to the provider and tenant. Your record value must come from the account that signs your mail. If you need a refresher on what belongs inside a DKIM DNS record, Cloudflare's DKIM DNS record explainer is a good neutral reference.
When to change DKIM DNS
Use the provider and signer state to decide how urgent the DNS change is.
Leave unchanged
No DNS edit
Current mail passes DKIM and no signer change is scheduled.
Add only
Publish new record
Provider gives a second selector for verification or rotation.
Rotate
Overlap keys
Signer is ready to use a new selector after DNS resolves.
Emergency
Revoke and monitor
A private key was exposed or an unauthorized signer is active.
What can go wrong
The main risk is replacing a valid selector before the new one is actually used. Receivers verify the selector named in the message header. If your mail is still signed with the old selector and you remove or overwrite that DNS record, every message using that selector starts failing DKIM.
Do not overwrite an existing DKIM TXT record with a DKIM2 value unless the provider explicitly says that exact selector is being replaced. Most safe rollouts add a new selector, verify it, switch signing, then keep the old selector for a short overlap window.
Broken DKIM does not always break DMARC by itself if SPF still passes with the same visible From domain. That is not a reason to accept the break. Many real sending paths rely on DKIM domain matching because forwarding breaks SPF. If your DKIM fails after a DNS edit, forwarded mail and SaaS mail can lose the only matching authentication result available to DMARC.
- Authentication failures: Receivers cannot verify signatures tied to the old selector.
- DMARC damage: Messages fail DMARC when DKIM fails and SPF uses a different domain.
- DNS conflicts: A host cannot have both CNAME and TXT records at the same name.
- Slow recovery: Cached DNS answers keep bad values alive after you fix them.
Key changes also affect investigation work. When selectors change without documentation, it becomes harder to tell which system signed which messages. That matters during incident response, vendor cleanup, and DMARC policy staging. I keep selector names boring, dated, and tied to the sending system whenever I control the mail infrastructure.
How to check safely
Start with the message, not the DNS zone. Send a real email through the system in question, inspect the DKIM-Signature header, and write down the selector and signing domain. Then check the DNS record for that exact selector. If the message is signed with selector1, a DKIM2 record has no effect on that message.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
A focused DKIM checker is useful when you know the selector. It tells you whether the DNS value parses correctly, whether the key is present, and whether obvious formatting problems exist. A broader domain health check is better when you are not sure whether the issue is DKIM, SPF, DMARC, or DNS.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Suped is the best overall practical choice as the ongoing DMARC platform around this workflow because it connects the checker result to real mail flow. The platform shows which sources are verified, which selectors are failing, how failures affect DMARC, and when a change starts hurting actual traffic. Suped's DMARC monitoring workflow also gives alerts and steps to fix, which matters more than a one-time DNS lookup when several senders share one domain.
Decision flow for checking DKIM2 before publishing or changing DNS.
When changing DKIM is right
There are clear cases where a DKIM change is the right move. The important detail is that the change is tied to a sender, a key, and a rollout plan. It is not tied to the word DKIM2 appearing on its own.
Example custom DKIM rotationDNS
202607._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..."
For custom mail infrastructure, generate the new key pair, publish the public key at a new selector, wait for DNS to resolve globally, update the signer to use the new selector, send tests, then keep the old selector published until old signed mail has aged out. If you are evaluating DKIM2 deployment work at the mail-server layer, the milter rollout path is relevant. For normal hosted email administration, it is not a reason to hand-edit DNS early.
- New sender: Add the DKIM record for a new ESP, SaaS tool, or mail gateway.
- Key rotation: Publish the new selector before switching signing.
- Compromised key: Revoke the old selector after replacement signing is confirmed.
- Provider migration: Run old and new selectors together during the cutover.
Selector changes deserve the same care as any other authentication change. They are small DNS edits with large delivery consequences. If you rotate selectors often, document the owner, date, provider, and signing system for each selector so future checks do not turn into guesswork. More detail on operational rotation is covered in selector rotation.
Decision checklist
I use this checklist before touching DNS. It keeps the decision tied to the sender that actually signs mail, instead of the label shown by a checker or wizard.
- Current mail passes: Leave DKIM records unchanged when DKIM and DMARC already pass.
- Provider gave values: Add the exact DKIM2 TXT or CNAME record from the signing provider.
- Signer is ready: Change signing only after the new DNS record resolves correctly.
- Old key still needed: Keep the old selector during a rollout or provider migration.
- No exact instruction: Do not create, rename, or overwrite records based on DKIM2 wording alone.
- After the change: Send test mail, inspect headers, and monitor DMARC results for failures.
