When DKIM `pass` Is a Lie: Anatomy of a 1024-bit Key Compromise

The alert landed on a Tuesday. A classic Business Email Compromise (BEC) attempt: a very convincing wire transfer request, seemingly from the CFO. The user who reported it was sharp; the sender's tone was just slightly off. But when the initial analyst pulled the headers, something was wrong. The email, which should have been flagged as a blatant forgery, sailed right through.

The `Authentication-Results` header was unambiguous: `dkim=pass`. The DMARC check also passed. For all intents and purposes, the receiving mail server saw a legitimate, cryptographically signed message from the CFO's real domain. It was an impossible email.

This is the postmortem of that investigation. It's a story about how a forgotten, legacy email security setting became an attacker's skeleton key. The cryptographic assurances we've been taught to trust are only as strong as their weakest implementation, and it turns out 1024-bit RSA keys are no longer strong enough.

An Impossible Email

The initial triage was confusing. Everything looked right, which was exactly what was wrong. SPF failed, as expected. The attacker sent the email from their own infrastructure, not the company's authorized mail servers. A typical `Received-SPF: fail` was present. But that’s common, especially with forwarded mail, which is why DMARC allows for DKIM to provide authentication alignment instead.

And the DKIM signature was valid. Not just valid, but aligned. The domain in the `d=` tag of the DKIM-Signature header matched the domain in the `From:` header. According to RFC 7489, this is the textbook definition of a DMARC pass. The system worked as designed. The problem was, the signature itself was generated by the attacker.

This wasn't a lookalike domain attack. This wasn't a display name spoof. The attacker sent an email from `cfo@legitcorp.com`, and the world's mail servers saw a valid signature from `legitcorp.com`. How?

Forensic Deep Dive: The Telltale Header

The breakthrough came from a non-standard but incredibly helpful annotation in the `Authentication-Results` header provided by the inbound mail gateway. It wasn’t just the verdict; it was the metadata about the verdict.

Authentication-Results: mta.example.net; dkim=pass (1024-bit key) header.d=legitcorp.com header.s=legacy2015 header.b=abc123de

Unpacking the `Authentication-Results`

That small parenthetical—`(1024-bit key)`—was the smoking gun. While not a required part of the RFC 6376 standard, some modern MTAs will perform the key lookup, evaluate its length, and add it for forensic context. The DKIM signature was valid, yes, but it was generated with a key length that is now considered dangerously weak.

The `s=` tag in the header points to the DKIM selector: `legacy2015`. A selector is just a label that lets a domain publish multiple DKIM public keys in DNS. This is often used to grant sending permissions to different third-party services, like your CRM or your HR platform, without giving them all the same key.

From Selector to DNS Record

With the selector in hand, anyone can query the public key. A simple DNS query for the TXT record at `legacy2015._domainkey.legitcorp.com` reveals the public key data. Inside that TXT record is the `p=` tag, which contains the Base64-encoded public key. By decoding this and analyzing the ASN.1 structure of the public key, you can determine its length. In this case, the key was created in 2015 and was indeed 1024 bits. It was probably set up for some long-forgotten service and never rotated.

Factoring-as-a-Service: The Attacker's New Playbook

For years, the idea of cracking a 1024-bit RSA key was a theoretical concern, something reserved for nation-state adversaries with access to supercomputers. That assumption is now dangerously outdated. The economics of cloud computing have changed the game completely.

An attacker's playbook now looks like this: First, find a valuable target. Then, enumerate all of their public DKIM selectors in DNS. This is trivial. You check for common selectors (`google`, `selector1`, `m1`) or use tools to find them. Once you find a weak 1024-bit key, the attack begins.

The Economics of the Crack

Factoring a 1024-bit RSA modulus—the mathematical operation required to derive the private key from the public key—is a computationally intensive task. But

But 'intensive' doesn't mean 'impossible'. With the ability to rent tens of thousands of CPU or GPU cores for pennies on the hour from cloud providers, a well-funded criminal group can bring a massive amount of computing power to bear on the problem for a relatively low cost. The financial barrier to entry has collapsed. The successful public factoring of a 795-bit number was completed over a decade ago; 1024 bits is the next logical step for motivated attackers with a financial incentive.

The Payoff: A Perfect Forgery

Once the attacker factors the public key and calculates the corresponding private key, they effectively *become* the legitimate sender. They can now sign any email they want with a valid DKIM signature for that selector. Since the signature is mathematically correct and aligns with the domain, it passes DMARC with flying colors. A DMARC policy of `p=reject` becomes useless. The very mechanism designed to prevent forgery is now used to legitimize it.

Is Your Domain Exposed? Auditing Your Keys

This incident should be a wake-up call. You need to know the strength of every single DKIM key associated with your domain. Not just the one for your primary mail gateway, but for every third-party service that sends email on your behalf.

Discovering these keys is the hard part. A large organization might have dozens of selectors for marketing platforms, customer support systems, financial software, and developer tools. Many of these were set up years ago by people who may no longer be at the company. There often isn't a central registry.

You can start by manually checking known services. Log into your Microsoft 365 or Google Workspace admin panels. Check the DKIM settings. Go to Salesforce, Zendesk, Mailchimp, and any other platform you use. For each one, identify the selector and use a command-line tool like `openssl` or an online checker to parse the public key from DNS and verify its length. Anything less than 2048 bits is a liability.

This manual process is tedious and prone to error. You will inevitably miss a selector for a forgotten service, and that's the one attackers will find. Automated and continuous auditing is the only reliable way to manage this risk at scale.

The Zero-Downtime Key Rotation Playbook

Once you discover a weak 1024-bit key, you must replace it. But you can't just delete it. Doing so could cause legitimate emails from that service to suddenly fail DMARC checks, disrupting business operations. The key is to perform a controlled, zero-downtime rotation. Follow the 'make-before-break' principle.

Generate and Publish the New Key

First, go to the sending service's admin console and generate a new DKIM key. Ensure it's 2048 bits. The service will give you a new selector and a new TXT record value. For example, if your old selector was `legacy2015`, your new one might be `q12024`. Publish this new TXT record in your DNS.

Activate, Monitor, and Decommission

Next, instruct the sending service to start using the new key to sign outgoing emails. Crucially, do not remove the old key from your DNS yet. For a transitional period, you may have two valid keys for that service. Monitor the headers of emails sent from that service to confirm that receiving MTAs are seeing and passing the new signature.

After a safe period—typically 48-72 hours to account for DNS caching and mail queue delays—you can decommission the old key. First, remove the old `legacy2015._domainkey` TXT record from your DNS. Then, if the sending platform allows it, delete the old key from its configuration. This severs the connection to the weak key for good, without ever breaking mail flow.

The takeaway

The trust we grant a `dkim=pass` verdict is conditional. We are trusting the sender's key management practices as much as we are trusting the cryptography itself. When a 1024-bit key is in play, that trust is broken. It is no longer a theoretical vulnerability; it's a practical attack vector that bypasses our most fundamental email authentication control, DMARC.

Go audit your selectors. All of them. The attacker who just spent a weekend factoring your public key isn't going to send you a warning. Continuously monitoring all your DKIM selectors is a daunting task, but tools like MailSleuth.AI can automate the discovery and health-checking of every key across your entire sending infrastructure.