Microsoft 365 DKIM selector1 and selector2
Microsoft 365 DKIM selector1 selector2 · Office 365 DKIM · M365 DKIM CNAME
Why Microsoft 365 uses selector1 and selector2, how CNAME-based DKIM publishing works, and what to check when validation fails.
Por DN01 Network Team
Microsoft 365 normally publishes DKIM through selector1 and selector2 CNAME records that point to Microsoft-controlled names rather than a direct p= TXT key in your zone. DKIM prova que a mensagem foi assinada pelo remetente e que a chave pública está publicada no DNS.
A DKIM TXT validator may show no direct record at the vanity name if the CNAME chain is wrong, not followed, or published in the wrong DNS provider. Verifique o nome exato selector._domainkey.domínio: sem selector não há como saber qual chave o receptor deve usar.
Check selector1 and selector2 with /pt/dkim-validator, then inspect the CNAME and TXT chain in /pt/dns-checker if the result is missing. Confira o TXT, as tags v/k/p/h/s/t, o tamanho da chave, t=y e revoked; depois compare com DNS Checker.
What to verify first
Confirm that the selector is copied from the mail provider, not guessed from another domain or an old migration note.
Check whether the answer is a direct TXT record or a CNAME chain that eventually points at the DKIM TXT value.
Look at v=DKIM1, k=, p=, h=, s= and t= together. A record can exist but still be unusable when the public key is empty, malformed or too weak.
Common failure causes
The record was added to the wrong DNS provider, while the domain still delegates to another authoritative nameserver.
The selector changed during a provider migration, key rotation or domain re-verification, but an older selector is still being tested.
The TXT value was split or quoted incorrectly by a DNS editor, so receivers cannot reconstruct the base64 public key.
How to fix safely
Publish the new key first, wait for DNS visibility, then switch signing in the provider console. Do not delete the old selector until delayed mail has cleared.
Use t=y only during rollout. Once signed mail verifies consistently, remove testing mode so DKIM sends a stronger production signal.
Keep DKIM checks next to SPF and DMARC checks. A valid DKIM key is one part of deliverability, not the whole authentication policy.
| Tag | Why it matters |
|---|---|
| v=DKIM1 | Identifies the TXT value as a DKIM record. |
| p= | Carries the public key; an empty value revokes the key. |
| k= | Declares the key type, commonly rsa or ed25519. |
| h= | Limits allowed hash algorithms such as sha256. |
| t= | Flags testing mode (y) or strict subdomain behavior (s). |
Perguntas frequentes
- Can I check DKIM without a selector?
No. DKIM records are selector-specific, so you need the selector from your provider or from a DKIM-Signature header.
- Why is the DKIM record found but invalid?
The TXT record may have a wrong version tag, duplicate tags, missing p=, invalid base64, a revoked empty key or a weak/malformed public key.
- Should I keep the old selector during rotation?
Yes, keep it until TTLs and delayed mail queues clear. Removing it too early can break verification for messages already in transit.