DKIM glossary
What does v=DKIM1 mean in a DKIM record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
v=DKIM1 is the version tag at the start of a DKIM public-key record in DNS — the TXT record a receiver fetches to verify a signature, as in v=DKIM1; k=rsa; p=.... It declares the record uses DKIM version 1. RFC 6376 makes it optional, but when present it must come first.
v=DKIM1 at a glance | |
|---|---|
| Tag | v (version, key record) |
| Valid values | DKIM1 — the only defined value |
| Default | Optional; if present it MUST be the first tag. A record with no v= is still read as DKIM1. |
| Where it goes | First tag of the _domainkey TXT record, before k= and p=. |
How v=DKIM1 works
v=DKIM1 lives in DNS, on the public-key record at <selector>._domainkey.<domain>. It's the opening tag of that TXT record — v=DKIM1; k=rsa; p=<base64 key> — and it simply states the record follows DKIM version 1. RFC 6376 makes the tag optional, but if you include it, it has to come first.
Here's what trips people up: this is not the same v you see in the DKIM-Signature header. The signature header carries v=1; the DNS key record carries v=DKIM1. Two separate records, two different version tags, the same idea written two ways. If you're looking at v=1, you're reading a message header — v=DKIM1 means you're reading the DNS key.
Because the tag is optional, some published keys leave it out and still verify. Including it is good hygiene and what every key generator produces, so keep it in — and keep it first.
Correct record vs common mistake
Correct
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...Version tag first, then key type, then the public key — the conventional, well-formed order for a DKIM key record in DNS.
Common mistake
k=rsa; p=MIGfMA0GCSqGSIb3DQEB...; v=DKIM1If v=DKIM1 is present it must be the first tag. Tucked at the end, strict verifiers may ignore or reject the record — put it first, or leave it out entirely.
Troubleshooting v=DKIM1
| Issue | Likely cause | Fix |
|---|---|---|
| Verifier rejects the key record | v=DKIM1 is present but isn't the first tag | Reorder the record so v=DKIM1 comes first, then k=, then p= |
| Unsure which v tag to edit | The header's v=1 and the DNS v=DKIM1 look alike | Edit v=DKIM1 only in the _domainkey TXT record; v=1 is set by the signer, never in DNS |
| Pasted record won't parse | The provider split the long TXT value and broke it across quoted strings | Rejoin the quoted strings into one continuous value that starts with v=DKIM1 |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
When you're reading DKIM records across a fleet of tenants, confusing the DNS key's v=DKIM1 with the header's v=1 sends techs editing the wrong record. Standardise where each version tag lives, so a junior tech debugging one client doesn't 'fix' the wrong thing on fifty.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna — CEO, gaiia (YC 2021)Read the case study →
Enforce it — don't just monitor it
Palisade validates every client's published DKIM key records — v=DKIM1 first, key present and intact — as part of confirming each sender is aligned before it advances the domain to reject.
Free 15-day trial · No credit card · Your own domain free forever (NFR)