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 |
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
“Palisade made it so easy for us to get our blue verified checkmark and achieve our BIMI compliance”
Max LeRoy , VP Product, PoliticoRead the case study →
DMARC software that does the work
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.
1 domain free up to 1,000 emails/month
Questions readers ask
Frequently asked questions
Is v=DKIM1 required?
No. RFC 6376 makes it optional, and a key record without it still verifies. But if you include it, it must be the first tag, and every generator adds it, so it's the safe convention.
What's the difference between v=DKIM1 and v=1?
v=DKIM1 is in the DNS public-key record; v=1 is in the DKIM-Signature message header. Different records, different tags. Seeing v=1 means you're reading a header; v=DKIM1 means the DNS key.
Where does v=DKIM1 go in the record?
First, before k= and p=. If it appears anywhere else, strict verifiers can reject the record, so keep it at the very start.
Can I publish a key without v=DKIM1?
Yes: the version tag is optional. The record only truly needs a p= public key to work; v= and k= are conventional additions that generators include by default.