TXT
TXT Record: DKIM
DKIM public keys are published as TXT records at selector._domainkey.example.com. Learn the format, key rotation, and how to verify your DKIM setup.
Published · Last verified · Maintained by TamingDNS
TXT
Authentication (TXT)
RFC 6376
Yes
TXT "v=DKIM1; k=rsa; p=<base64-public-key>"
TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
3600-86400 s; shorten to 300 s before rotating keys
💬 What This Record Does
DomainKeys Identified Mail (DKIM) uses public-key cryptography. Your mail server signs outgoing messages with a private key, and the public key is published in DNS as a TXT record at a selector subdomain (e.g., google._domainkey.example.com). Receiving servers retrieve this public key, verify the signature in the email's DKIM-Signature header, and confirm the message wasn't tampered with in transit. Unlike SPF, DKIM survives email forwarding.
Common Uses
- Publishing a DKIM key for your own mail server's selector
- Verifying that your ESP (Google, Mailchimp, SendGrid) has set up DKIM for your domain
- Key rotation: setting a new selector's TXT record before switching signing to the new key
⚠️ Watch Out For
- The selector subdomain format is always: <selector>._domainkey.<yourdomain>
- RSA keys must be at least 1024 bits; 2048 bits is strongly recommended for new setups.
- An empty public key (p=) signals that the selector is revoked. All messages signed with it will fail.
🔧 Related Tools
📋 Complete Example Records
Whole records in zone-file form: name, TTL, class, type, then the data. Most DNS panels ask for the pieces separately. Look them up live with the DNS Lookup tool.
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
A published key, and note the name. It always carries the selector plus the literal _domainkey label, and v=DKIM1 MUST be the first tag.
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p="
RFC 6376 §3.6.1 says an empty p= means the key is revoked, and verifiers SHOULD return an error for a signature naming a revoked key. The same section notes there is no defined semantic difference between revoking a key and removing the record.
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
The t=y flag puts the key in testing. Verifiers MUST treat a failing signature from it no differently from unsigned mail, so take the flag off once you trust the setup.
selector2._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA" "rest-of-the-2048-bit-key-continues-here"
A 2048-bit key split across two strings. The base64 runs past the 255-octet limit for a single string, and the halves are joined with nothing between them.
selector1._domainkey.example.com. 3600 IN CNAME selector1-example-com._domainkey.provider.example.net.
This delegates the selector instead of publishing it. Several providers hand you a CNAME so they can rotate the key without you touching your zone.