DKIM is the part of email authentication that survives the trip. SPF breaks as soon as a message is forwarded. A DKIM signature travels inside the message and can still be checked at the final mailbox. If you send from your own domain through Google Workspace, Microsoft 365 or any marketing platform, DKIM is what lets receivers confirm the message really came from you and wasn't changed on the way. This guide explains how signing works, what a selector is, which key size to choose, how to rotate keys, and how to find the DKIM record for your domain.
Key takeaways
- DKIM signs each email with a private key, and receivers check it against a public key published in DNS under a selector.
- The d= signing domain must be your own, because a signature from the vendor's domain passes DKIM but does nothing for you under DMARC.
- Use 2048-bit keys, which RFC 8301 and Gmail both recommend over the 1024-bit minimum.
- Rotate DKIM keys at least every six months, and never delete the old record before the new key is signing.
How DKIM signing works
DKIM (DomainKeys Identified Mail, RFC 6376) uses a public/private key pair:
- Your sending service holds the private key. When it sends a message, it hashes the body and a chosen set of headers (From, Subject, Date, To and so on) and signs the result with the private key.
- It adds a
DKIM-Signatureheader containing the signature, the signing domain and a selector. - The receiving server reads the header, fetches the public key from DNS at
<selector>._domainkey.<domain>, and checks the signature. - If the body hash and the signature both verify, DKIM passes for that domain. If anyone changed the signed headers or the body, it fails.
Here is a real-world-style signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google;
t=1760263200; h=from:to:subject:date:message-id:mime-version;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=Kx3jL0...base64-signature...q9Q==
| Tag | Meaning |
|---|---|
v=1 |
DKIM version |
a=rsa-sha256 |
Signing algorithm. rsa-sha1 is no longer valid (RFC 8301) |
c=relaxed/relaxed |
Canonicalization for headers/body: how tolerant the check is of whitespace changes |
d=example.com |
The signing domain. This is what DMARC compares with your From: domain |
s=google |
The selector. Tells the receiver which key to look up |
h= |
The headers that were signed |
bh= |
Hash of the message body |
b= |
The signature itself |
t= / x= |
Optional signing time and expiry |
The d= value matters most. A message can carry a valid DKIM signature from d=sendgrid.net, which passes DKIM but does nothing for your domain under DMARC. You want signatures with d= set to your domain (or a subdomain of it). See DMARC explained for how alignment works.
What the DNS record looks like
The public key lives in a TXT record:
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy8...IDAQAB"
v=DKIM1: version (optional, but must come first if present).k=rsa: key type. RSA is the default.p=: the base64 public key. An emptyp=means the key has been revoked.t=y: optional testing flag. Receivers must treat mail as if it were unsigned. Remove it once you're live.
Many providers have you publish a CNAME instead, pointing to a record they host. Microsoft 365 uses two:
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
selector2._domainkey.example.com. CNAME selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
Copy the exact values from your Microsoft 365 Defender portal or from Get-DkimSigningConfig in Exchange Online PowerShell. The target format varies by tenant. The advantage of CNAMEs is that the provider can rotate keys without you touching DNS again.
Selectors: why there can be many keys
A selector is just a label that lets one domain publish many DKIM keys at once. Each service that sends for you should have its own:
| Service | Typical selector(s) |
|---|---|
| Google Workspace | google (default, can be changed) |
| Microsoft 365 | selector1, selector2 |
| ESPs and marketing tools | Vendor-specific, often several (e.g. k1, s1, s2, em) |
Selectors are also how rotation works: publish a new key under a new selector, switch signing over, then retire the old one.
Finding your DKIM record
There's no way to list all selectors for a domain from DNS. You need to know the selector name first. Two ways to find it:
1. Read a message you sent. In Gmail, open the message, choose Show original, and find the DKIM-Signature header. Take s= and d=, and look up s._domainkey.d:
dig +short TXT google._domainkey.example.com
On Windows:
nslookup -type=TXT google._domainkey.example.com
The Gmail summary at the top of Show original also says which domain DKIM passed for: DKIM: 'PASS' with domain example.com.
2. Check your provider's admin panel. Google Workspace shows the record under Apps > Google Workspace > Gmail > Authenticate email. Microsoft 365 shows it on the DKIM tab of Email authentication settings in the Defender portal. ESPs usually list it under "domain authentication" or "sender authentication."
A free audit checks your domain for DKIM records under common selectors and reports what it finds next to your SPF and DMARC results.
Choosing a key length
RFC 8301 sets the floor:
- Signers must use RSA keys of at least 1024 bits and should use at least 2048 bits.
- Verifiers must reject keys shorter than 1024 bits.
rsa-sha1must not be used for signing or verifying.
Gmail's sender guidelines also require at least 1024 bits and recommend 2048. Use 2048-bit keys unless your DNS host can't store them. A 2048-bit public key is longer than the 255-character limit for a single TXT string, so it has to be split into multiple strings within one record:
s1._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx..."
"...remainder-of-the-key...IDAQAB" )
Most modern DNS dashboards do this automatically when you paste the full value. If yours rejects the value, contact the host before falling back to 1024 bits. Microsoft 365's PowerShell cmdlets still default to 1024-bit keys for new configurations, so pass -KeySize 2048 explicitly or rotate to 2048 after setup.
Ed25519 signing (RFC 8463) produces much shorter keys, but receiver support is not universal. If you use it, sign with RSA as well, so receivers that don't understand Ed25519 still see a valid signature.
Rotating DKIM keys
Rotation limits the damage if a private key leaks and keeps your process practiced for emergencies. M3AAWG's DKIM key rotation best practices recommend rotating at least every six months.
With CNAME-based providers (Microsoft 365, many ESPs)
The provider holds both keys. In Microsoft 365, choose Rotate DKIM keys in the Defender portal or run:
Rotate-DkimSigningConfig -Identity example.com -KeySize 2048
Microsoft notes the new key takes four days (96 hours) to start signing. Until then, the old key is still used. Nothing changes in your DNS.
With TXT-based keys you manage yourself
- Generate a new key pair in your sending service, under a new selector (for example
s202610). - Publish the new public key in DNS. Wait for it to resolve from public resolvers.
- Switch signing to the new selector.
- Keep the old public key published for at least a few days, so messages still in transit or queued for retry can be verified.
- Revoke the old key by publishing an empty
p=or deleting the record.
s202604._domainkey.example.com. TXT "v=DKIM1; p="
Never delete the old record before the new key is signing. Messages signed with a selector that no longer resolves fail DKIM.
Common DKIM problems
- Signing with the vendor's domain. DKIM passes, DMARC fails. Fix it by completing the vendor's "authenticate your domain" or "custom DKIM" setup.
- Record pasted with extra quotes or line breaks. The key becomes invalid. Look it up with
digand compare it character by character with what your provider shows. body hash did not verify. Something changed the message after signing: a footer added by a gateway or mailing list, or a security appliance rewriting links. Sign as late as possible in your outbound path.- Key published but signing never enabled. Common in Microsoft 365 and Google Workspace. Both require you to turn signing on after the DNS record is in place. Google says it can take up to 48 hours for DKIM to start working after you add the record.
- Using
l=(body length). It leaves content appended after the signed portion unprotected. Avoid it.
Frequently asked questions
Do I need DKIM if I already have SPF?
Yes. SPF fails when mail is forwarded, and it checks the envelope domain rather than the From: address. DKIM survives forwarding and is the more reliable path to DMARC alignment. Gmail, Yahoo and Outlook.com all require both from bulk senders.
Can I have more than one DKIM record?
Yes, one per selector, and that's normal. Each service that sends for you should sign with its own selector. Unlike SPF, there's no limit on how many selectors you publish.
Is a 1024-bit DKIM key still acceptable?
It's the minimum allowed by RFC 8301 and Gmail, so it still works. But 2048 bits is recommended by both, and the only common reason not to use it is a DNS host that can't store long TXT values.
How do I know which selector a service uses?
Send a test message and read the s= tag in its DKIM-Signature header, or check the service's domain authentication settings. You can't discover selectors by querying DNS alone.
What to do next
Send a message from each service that emails as your domain and check that DKIM passes with d= set to your domain. Fix any that sign with the vendor's domain, move 1024-bit keys to 2048, and put a six-month rotation reminder in your calendar. Then use DMARC to turn those signatures into protection, and keep SPF tidy as the backup path.
Sources
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
- Microsoft Learn: How to use DKIM for email in your custom domain
- Google Workspace Admin Help: Set up DKIM
- M3AAWG: DKIM Key Rotation Best Common Practices
- Google: Email sender guidelines
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
