The v=DKIM1 Tag Is a Lie (Mostly)

Stare at enough raw email headers and you start to see patterns in the noise. The cascade of `Received` headers tells a story of the email's journey across the internet. The `Authentication-Results` header gives you the final verdict from the receiving mail server. And then there's the `DKIM-Signature` header itself, a cryptographic blob that feels both complex and routine.

We glance at `v=1;` in the signature and `v=DKIM1` in the corresponding DNS record and move on. It's the standard. It's always there. But what if it isn't? What if it's missing, or worse, claims to be a version that doesn't exist?

This seemingly innocuous tag is a critical component defined in RFC 6376. Its handling by major mail providers is not as uniform as you'd hope, and the gap between the specification and real-world implementation is exactly where security vulnerabilities are born. This isn't just academic; it has direct operational consequences for deliverability and threat detection.

The Ubiquitous `v=DKIM1` Tag Isn't What You Think

First, let's clear up a common point of confusion. The DKIM 'version' appears in two distinct places: the `DKIM-Signature` header added to the email, and the public key record published in your domain's DNS. They are not the same thing.

The signature header contains `v=1;`. This specifies the version of the signature's format itself. It tells the verifier which algorithms were used and how the signature was constructed. RFC 6376 only defines version 1, so this is all you'll ever see in practice.

DNS Records: A Namespace, Not a Version

The DNS record, on the other hand, uses `v=DKIM1`. This looks like a version, but it functions more like a namespace or a type declaration. It’s the very first piece of information a verifier looks for. When a mail server sees `v=DKIM1`, it knows how to interpret the rest of the TXT record — it knows to look for a public key in the `p=` tag, a key type in the `k=` tag, and so on. Without this initial declaration, the rest of the string is just a meaningless jumble of characters.

The RFC is explicit about the role of this tag. It isn't optional metadata; it's the foundational instruction for the entire record.

Reading Between the Lines of RFC 6376

When you're triaging an incident, the RFC isn't just a document; it's the rulebook. Understanding what it mandates versus what it suggests is the key to spotting deviations that attackers exploit. So what does RFC 6376 actually say about the version tag?

A DKIM key record, when retrieved from the DNS, is a list of tag=value pairs... The `v=` tag is mandatory and MUST be the first tag in the record. The value of this tag MUST be `DKIM1`. Records that do not start with this tag and value MUST be ignored by Verifiers. — RFC 6376, Section 3.6.1

The language here is unambiguous. 'Mandatory.' 'MUST be the first tag.' 'MUST be `DKIM1`.' 'MUST be ignored' otherwise. According to the spec, any DKIM record that fails these three conditions is invalid. Period. A verifier that encounters such a record should produce a `permerror` (permanent error) for the DKIM evaluation.

The Real World's Messy Interpretation

But we don't operate in an RFC-perfect world. Mail Exchange (MX) servers are notoriously lenient. Their primary directive has always been to deliver mail, not to be pedantic standards enforcers. A forwarded calendar invite that gets its body slightly rewritten by an intermediary MTA can break a DKIM signature. If every minor infraction resulted in rejection, a significant portion of legitimate mail would never arrive.

This tension between strict adherence and permissive mail flow creates a gray area. While the RFC says a malformed record 'MUST be ignored,' how does a receiving mail server actually behave? Does 'ignore' mean it treats the signature as if it weren't there, leading to a DKIM result of `none`? Or does it correctly flag it as a `permerror`? That distinction has massive implications for DMARC, which treats `none` and `permerror` very differently.

How Major Mailboxes Handle Malformed Versions

Let's put this to the test with the two biggest players: Google Workspace and Microsoft 365. How do their verifiers react when confronted with a non-compliant DKIM record? While their internal logic is a black box, we can observe the results in the `Authentication-Results` header they stamp on inbound mail.

Scenario 1: Missing `v=` Tag Entirely

If you publish a DKIM record like `k=rsa; p=...` without the leading `v=DKIM1;`, you've created a structurally invalid record. A verifier fetches this record, sees that it doesn't start with the mandatory version tag, and should immediately stop processing. In our testing, both Google and Microsoft correctly identify this as a permanent error. The `Authentication-Results` header will show a result like `dkim=permerror (key query failed: bad key syntax)`. This is the correct behavior. The DMARC evaluation will then proceed without a passing DKIM result.

Scenario 2: Invalid `v=` Tag Value

What if an attacker, or a misconfigured admin, publishes a record with `v=DKIM2;`? Since `DKIM2` is not defined by any standard, the verifier has no idea how to parse the rest of the record. Does `p=` still mean public key in this hypothetical future version? It can't know. The outcome is the same as a missing tag: a `permerror`. The verifier correctly refuses to guess and flags the record as invalid.

Scenario 3: The `v=` Tag is Not First

This is where things get interesting. What if the record is `k=rsa; v=DKIM1; p=...`? The mandatory tag is present, just not in the first position as required by the RFC. Modern, sophisticated parsers like those used by Google and Microsoft are often forgiving of tag order. They will likely still find the `v=DKIM1` tag, recognize the record type, and proceed to validate the signature. You might get a DKIM `pass` despite being non-compliant. A less forgiving parser on a security appliance or a log analysis tool, however, might fail where Google succeeds, creating a dangerous discrepancy in your security visibility.

Weaponizing Ambiguity for Evasion

From a red team perspective, the goal isn't always to get a green `pass` verdict. Sometimes, the goal is to create noise, confusion, and ambiguity to evade detection or break an analyst's workflow. Malforming the DKIM version tag is a subtle way to achieve this.

Bypassing Fragile Log Parsers

Think about the entire email analysis pipeline. The email hits the gateway, gets evaluated, and the results are logged to a SIEM. An analyst then uses queries and dashboards to hunt for threats. What if the SIEM's parser for DKIM logs is built on a simple regex that expects every record to start with `v=DKIM1`? A malformed record, even one that correctly results in a `permerror` from the mail server, might cause the log parser to fail. It might drop the key forensic data from the event, or misclassify it entirely. The evidence of the `permerror`—a strong signal of misconfiguration or malicious intent—is lost.

The attacker hasn't broken DKIM itself. They've broken your ability to analyze it. They are exploiting the weakest link in your detection chain, which is often not the primary mail server but the dozens of downstream systems that consume its output.

Creating Analytical Noise

Imagine an attacker setting up a lookalike domain for a Business Email Compromise (BEC) attack. They could publish multiple DKIM selectors. One selector, `s1`, could point to a record with a deliberately malformed `v=` tag. Another, `s2`, could be syntactically valid but contain the wrong public key. An email signed with the `s1` selector would produce a `permerror`. An email signed with `s2` would produce a `fail`. To an analyst sifting through logs, this creates a confusing picture. Why are there multiple DKIM failures of different types from the same domain? This noise can slow down triage and obscure the simple fact that the domain is fraudulent.

What a Hypothetical DKIMv2 Might Address

The fact that DKIM has remained at version 1 for over a decade is a testament to its design. But it's not perfect. If the IETF were to draft an RFC for `DKIM2`, what problems would it likely solve? This is purely speculative, but based on the current pain points, we can make some educated guesses.

First on the list would be cryptographic agility. DKIM is currently tied to RSA (SHA-1 and SHA-256). A new version would almost certainly incorporate more modern algorithms like Ed25519, which offers better performance and shorter keys. This is already happening with other standards and is a natural evolution.

Second, it would have to address the forwarding problem more directly. ARC (Authenticated Received Chain, RFC 8617) was created as a wrapper to preserve authentication results across hops, but it's an add-on, not a core fix. A `DKIM2` might include a mechanism to allow for sanctioned, limited modifications to the body or headers—like the addition of a `[EXTERNAL]` tag by a mail gateway—without invalidating the signature entirely. This would be complex but would solve one of the biggest sources of legitimate DKIM failures.

Finally, a new version could clarify some of the ambiguities that lead to inconsistent verifier behavior. It might define stricter error handling for malformed records or provide more granular error codes than the blunt `permerror` and `temperror`, giving administrators better diagnostic information.

The takeaway

The `v=DKIM1` tag is a perfect example of a foundational assumption—a detail so common it becomes invisible. But in security, invisible details are where risk accumulates. An email authentication stack is only as strong as the verifier's adherence to the specs and your ability to see the full, unfiltered results.

A simple pass/fail verdict isn't enough. The real story is in the nuances: the difference between a `fail` and a `permerror`, the order of tags in a DNS record, and the subtle ways attackers can break your analysis tools instead of the protocol itself. To defend properly, you need tooling that surfaces these structural anomalies and parser warnings. An analyst needs to see not just the final score, but how the score was calculated. Comprehensive platforms like MailSleuth.AI are built for this, exposing the raw evidence behind the verdict.

So, the next time you're investigating a failed authentication, don't stop at checking the key. Ask if the DNS record itself was even valid to begin with. The answer might surprise you.