DNS Record Explainer

v=DKIM1
Version tag. Always "DKIM1" for current spec. Tells validators this is DKIM, not some other key format.

k=rsa
Key type. RSA is standard. (ed25519 exists in draft but not widely deployed yet.)

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
The actual public key in base64. This is the truncated portion you pasted—validators need the full key to work. Typically 1024-bit (weak, legacy) or 2048-bit (current standard). Key length directly affects signature verification; too short = easy to brute-force.

• Incomplete input: You've shown only the start of the base64 key. The full p= value is required for deployment. A real DKIM public key is ~340 chars (2048-bit RSA).

• No algorithm tag (a=): Modern DKIM records should include a=rsa-sha256 to specify signature algorithm. If absent, validators default to rsa-sha256, but explicit is clearer. rsa-sha1 is deprecated; don't use it.

• No flags tag (t=): Optional, but t=y (testing mode) or t=s (sign-only) are useful during rollout. Missing means full enforcement.

• No service type tag (s=): s=email is default and correct. s=* means all services can use this key. Not including it works but is less explicit.

DKIM records live in DNS as TXT records under the selector subdomain (e.g., `default._domainkey.example.com`). Mail receivers fetch this to verify signatures on your outgoing emails. If the key is malformed, incomplete, or unreachable, SPF/DKIM/DMARC checks fail and your mail lands in spam or bounces. The p= value must be exactly correct—any typo breaks verification.

**Action: Paste the complete p= value to validate fully. Add a=rsa-sha256 and t= tags for clarity.**