DKIM Record Examples
DKIM records are TXT records published under a selector subdomain, for example selector1._domainkey.example.com. The value contains the version, key type, and public key. This page shows realistic examples for Google Workspace, Microsoft 365, and custom selectors, and explains how to read each field. Use these as reference when validating or troubleshooting DKIM.
One-Minute Fix
Publish the exact DKIM TXT record your provider supplies. Ensure the selector hostname matches what the sender uses, and that the p= value contains the full public key without truncation.
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."The hostname is selector._domainkey.yourdomain. The value starts with v=DKIM1, includes k=rsa (or ed25519), and p= holds the base64 public key. Replace the ellipsis with the full key from your provider.
Re-checkWrong vs correct setup
Truncated or partial record
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN"The p= value is truncated. DKIM verification fails when the public key is incomplete. The key must be the full base64 string from the provider.
Complete DKIM record
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."The full public key is present. Receivers can verify signatures that use this selector. Copy the entire p= value from your provider without shortening it.
Why examples help
Teams often truncate the public key during copy-paste, publish under the wrong hostname, or confuse the selector. Working examples show the correct structure and reduce setup errors.
Why incorrect record structure causes problems
- Truncated keys cause verification failures.
- Wrong selector hostname means receivers cannot find the key.
- Missing k= or p= fields make the record invalid.
- Publishing under the wrong domain breaks alignment.
How correct DKIM records affect deliverability
Valid DKIM records allow receivers to verify signatures. That strengthens authentication, supports DMARC alignment, and improves trust. Malformed or truncated records break verification and weaken deliverability.
Common record mistakes
- The public key was truncated when pasting into DNS.
- The selector hostname did not match the sender's selector.
- The record was published at the wrong domain or subdomain.
- An old record was left in place after a key rotation.
What we checked
We validated DKIM record structure: version, key type, and completeness of the public key. We also check that the selector hostname matches common patterns.
Live DNS lookup. No login. No saved domains. No tracking.
FAQ
What does k=rsa mean?
k=rsa indicates the key algorithm. RSA is common; some providers use k=ed25519. The receiver uses this to verify the signature.
Can the p= value be split across multiple strings?
Yes. DNS TXT allows multiple strings that are concatenated. Ensure the full key is present when combined; truncation causes failure.
How long should the public key be?
RSA keys are typically several hundred characters in base64. Ed25519 keys are shorter. Use the full key from your provider.
Next steps
- Obtain the full DKIM record from your provider.
- Publish it at the exact selector._domainkey hostname.
- Ensure the p= value is complete and not truncated.
- Send a test email and verify DKIM passes in headers.
- Re-check after key rotation or provider changes.
- Review the full troubleshooting guidance in the DKIM Hub.
- Explore sender authorization issues in the SPF Hub.
- Review alignment and policy issues in the DMARC Hub.