DNS Record Explainer

v=DKIM1
Version tag. Always "DKIM1". Tells receivers this is a DKIM public key record.

k=rsa
Key type. RSA is the standard and only widely supported algorithm in production. (ed25519 exists in the spec but has minimal real-world support.)

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
The actual public key in base64. This is truncated in your input—a real RSA-2048 key is ~392 characters, RSA-4096 is ~800+. Receivers use this to verify the cryptographic signature on your outbound mail headers.

The record is incomplete as shown (key data truncated). You need the full base64 string, no spaces or line breaks within the value. Common mistake: pasting from email headers that wrapped the key—must be continuous.

Missing optional tags that are sometimes added:
• t= (flags like "y" for testing, "s" for strict signing)
• n= (notes, rarely used)

These don't break anything if absent—defaults are fine for normal deployment.

No issues with k=rsa or v=DKIM1 itself. If your key is RSA-1024, that's outdated; use RSA-2048 minimum (preferably 4096, though DNS record size may be a constraint—split across multiple TXT records if needed).

DKIM records live in DNS as TXT records at a subdomain: `._domainkey.` (e.g., `default._domainkey.example.com`). Your mail server signs outgoing messages with the private key; receivers fetch this public key and verify the signature. Without a valid DKIM record, receivers can't authenticate your mail—impacts deliverability, especially to Gmail, Microsoft, Yahoo.

If the record is malformed (bad base64, truncated, typos in v= or k=), signature verification fails silently—mail still sends but looks unsigned to receivers.

→ /tools/dkim-checker run the live checker on a real domain → /blog/dkim-key-not-found