An Attacker's View of DKIM: Forging Trust with Test Mode and Weak Keys

An analyst sees the header: `Authentication-Results: ... dkim=pass`. They mentally check a box and move to the next alert. But the email is a perfect phish, and the attacker just slipped past the first line of defense. The analyst made a critical mistake—they assumed all 'pass' verdicts are created equal.

They aren't. DomainKeys Identified Mail (DKIM), defined in RFC 6376, is a pillar of modern email authentication. It provides a cryptographic signature that verifies a message hasn't been altered in transit and was sent by the claimed domain. When it works, it's brilliant. When it's misconfigured, it’s not just broken; it’s an active security liability.

From an offensive perspective, these misconfigurations are footholds. We're not talking about breaking RSA; we're talking about exploiting lazy administration and a fundamental misunderstanding of what DKIM guarantees. Let's walk through how an attacker finds and abuses these gaps.

Reconnaissance: Mapping the DKIM Landscape

Every attack starts with recon. Before forging a signature, you need to know what you're signing against. DKIM public keys aren't hidden; they live in public DNS as TXT records. The trick is finding the right one. An attacker needs the selector, a simple string used to differentiate between multiple potential keys for the same domain.

Selectors are specified in the `s=` tag of the `DKIM-Signature` header of any legitimate email sent by the target. An attacker can find them by simply receiving an email from the target organization or by guessing common patterns like `default`, `google`, `selector1`, or date-based selectors like `20230601`.

Enumerating Public Keys and Their Properties

Once a selector is found, say `s1`, the public key is queried via DNS. The query is for a TXT record at `s1._domainkey.example.com`. A simple `dig` command reveals everything:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

This DNS record is a goldmine. The `v=DKIM1` tag is standard. The `k=rsa` tag tells us the key type. The `p=` tag contains the Base64-encoded public key. But the most interesting tag for an attacker is `t=y`. This innocent-looking flag stands for 'test mode', and it's a gift.

Exploiting the `t=y` Flag: A Backdoor for Bad Policy

The `t=y` flag is meant for administrators to test a new DKIM implementation without affecting mail delivery if something goes wrong. RFC 6376 is clear on this: receivers who see this flag should not treat the signature as a secure assertion. The domain is explicitly telling the world, "I'm testing something here, don't trust this signature."

The Gap Between Specification and Reality

The reality is dangerously different. A surprising number of mail transfer agents (MTAs) and secure email gateways see a cryptographically valid signature, see the `t=y` flag, and still record a `dkim=pass` in the `Authentication-Results` header. They might append a `(test mode)` notice, but the core verdict is 'pass'. This is the DKIM test mode vulnerability in a nutshell.

Why does this happen? A mix of reasons. It could be a default configuration that prioritizes leniency. It could be a developer's interpretation that any signature, even a test one, is better than none. Or it could be a simple failure to parse and act on the `t` tag correctly. For an attacker, the 'why' doesn't matter. The result is an open door.

With `t=y` set, an attacker doesn't need to steal the private key. They don't need to crack anything. They can generate their own public/private key pair, craft a malicious email, sign it with their own private key, and point to the target's `t=y` enabled selector in the `DKIM-Signature` header. The receiving server fetches the public key from the target’s DNS, sees `t=y`, and may still grant a reputational boost. The signature is mathematically valid for the attacker's key, and the server is too lenient to care that the domain itself has disavowed it.

The Slow Decay of 1024-bit RSA

While test mode is a logic flaw, weak cryptography is a ticking time bomb. For years, 1024-bit RSA keys were the standard for DKIM. Today, they are a significant liability. While factoring a single, random 1024-bit key is still out of reach for the average cybercriminal, it's dangerously within the realm of possibility for well-funded academic research or state-sponsored actors.

The threat isn't a script kiddie running a tool on their laptop. The threat is a motivated attacker who sees a high-value target using a 1024-bit key and decides to invest the resources. With the advent of cloud computing, the cost of massive computation has plummeted. An attacker could rent enough GPU or CPU time to crack a key, or worse, a pre-computation attack could become feasible, breaking many keys at once.

From Infeasible to Inadvisable

NIST deprecated 1024-bit RSA for all new digital signature generation back in 2013. That was over a decade ago. Any domain still using them for DKIM is operating on borrowed time. The problem is that factoring the public key allows an attacker to derive the private key.

Once an attacker has the private key, it's game over for DKIM on that selector. They can sign any email with a perfect, valid signature. There's no `(test mode)` warning. The `Authentication-Results` header will show a clean `dkim=pass`. This signature will pass DMARC alignment checks under RFC 7489, effectively laundering a malicious email with the target's own cryptographic identity. This is the holy grail for a Business Email Compromise (BEC) attack.

Scenario: Forging a Signature on a Phishing Email

Let's put this together into a credible attack against `bigcorp.com`.

First, the attacker performs recon. They find two DKIM selectors in DNS: `test._domainkey.bigcorp.com` which has `t=y`, and `prod._domainkey.bigcorp.com` which uses a 1024-bit RSA key. The attacker now has two potential attack paths.

Path 1: The `t=y` Spoof

This is the path of least resistance. The attacker drafts a phishing email pretending to be from `accounting@bigcorp.com` with a malicious PDF invoice. They generate a fresh 2048-bit RSA key pair. They construct the `DKIM-Signature` header, making sure to set `d=bigcorp.com` and `s=test`. They calculate the body hash and sign the canonicalized headers and body with their *own* private key. They then send the email.

The victim's mail server receives the email. It extracts the selector `test` and domain `bigcorp.com` and queries `test._domainkey.bigcorp.com`. It gets the public key and the `t=y` flag. The server validates that the signature in the header matches the email content using the fetched public key. It matches. Because the email gateway is misconfigured to be lenient, it marks the email `dkim=pass (test mode)` and lets it through to the user's inbox, carrying a false aura of legitimacy.

Path 2: The 1024-bit Key Crack (High-Effort, High-Reward)

If `bigcorp.com` is a high-value target, a determined attacker might take this route. They dedicate significant computational resources to factoring the 1024-bit public key from the `prod` selector. After weeks or months, they succeed and derive the corresponding private key.

Now, they can impersonate `bigcorp.com` perfectly. They can send emails from the CEO (`ceo@bigcorp.com`) authorizing a wire transfer. They sign the email using the *stolen* private key. The receiving server validates the signature and finds a perfect match. The result is a clean `dkim=pass`. This passes DMARC, neuters spam filters, and lands a cryptographically-verified malicious email directly in the CFO's inbox. There is no indicator of foul play in the authentication headers.

Defensive Auditing: Finding These Attack Vectors First

The good news is that these vulnerabilities are easy to find and fix. It just requires proactive auditing. You need to look at your domains the way an attacker would.

Auditing Your Own DKIM Records

First, inventory all your DKIM selectors. You can't secure what you don't know you have. Go through your DNS zones and list every `_domainkey` record. For each record, check for two things: the `t=` flag and the key size.

If you find `t=y` on any record used by production mail flow, remove it immediately. If it's a dormant or true test record, consider deleting it entirely to reduce your attack surface. There is no reason for a production key to be in test mode.

Next, check the key strength. You don't need to be a cryptographer. A simple heuristic is to check the length of the Base64 string in the `p=` field. A 1024-bit RSA public key will be approximately 172 characters long. A 2048-bit key will be around 344 characters. If you find any short keys, plan to rotate them to 2048 bits immediately. This involves generating a new key pair, publishing the new public key with a new selector, and updating your sending service to use it.

Hardening Your Inbound Mail Flow

As a receiver, you have power. Configure your mail gateway to treat a DKIM signature with `t=y` as if it has no signature at all. It should not contribute to a `pass` verdict for DMARC evaluation. Better yet, increase the spam score or flag these messages for closer inspection. An email whose sender has to signal 'don't trust this' is inherently suspicious.

SOC analysts and IT admins must train themselves to read the full `Authentication-Results` header. A `pass` is not a `pass` is not a `pass`. Look for the details. A `pass (test mode)` is a red flag, not an all-clear.

The takeaway

DKIM is not a set-it-and-forget-it protocol. Its effectiveness depends entirely on correct, secure implementation. From an attacker's point of view, a domain littered with test flags and legacy 1024-bit keys is a soft target. They won't bother with complex exploits when you've left the side door unlocked for them.

The operational imperative is simple: audit your DNS, eradicate `t=y` from production, and standardize on 2048-bit (or stronger) keys for all selectors. This isn't just about RFC compliance; it's about closing an exploitable gap that threat actors are actively looking for. Continuous monitoring platforms like MailSleuth.AI can automate this discovery process, but the responsibility to act on the findings remains with the domain owner. Don't let a 'pass' verdict fool you into becoming the next victim.