The 1024-bit DKIM Key Retirement Playbook

Somewhere in your DNS, a ghost is signing your email. It's a 1024-bit RSA key, created years ago by a marketing team for a third-party sender you forgot you even used. And every day, it gives threat actors a practical, albeit computationally expensive, path to forging your domain's identity.

This isn't a theoretical exercise. The security community, via RFC 8301, has deprecated SHA-1 for signatures, and the same logic applies to key length. While factoring a 1024-bit key isn't a weekend project for a script kiddie, it is considered feasible for a well-resourced attacker—like those behind sophisticated Business Email Compromise (BEC) campaigns. Allowing these weak keys to persist is an active acceptance of risk.

This playbook provides a methodical process for identifying every service signing email on your behalf, validating their DKIM key strength, coordinating upgrades, and safely decommissioning the old keys without disrupting mail flow. It's time to hunt some ghosts.

Why 1024-bit DKIM Is a Ticking Time Bomb

DKIM's (DomainKeys Identified Mail, RFC 6376) entire purpose is to provide an unforgeable, cryptographic link between an email and a domain. The public key lives in your DNS, and the corresponding private key signs the headers and body of your outbound mail. When a receiver's mail server gets the email, it fetches your public key, verifies the signature, and checks the result against your DMARC policy (RFC 7489).

A 'pass' verdict tells the world, 'Yes, the owner of this domain authorized this message.' But the strength of that statement is only as strong as the cryptography behind it. If an attacker can reverse-engineer your private key by factoring your public key, they can generate valid DKIM signatures for any malicious email they want. They can impersonate your CEO, send fake invoices to your customers, and bypass all the expensive email security infrastructure you’ve put in place. Their emails will show a dkim=pass in the Authentication-Results header, and DMARC alignment will pass.

Authentication-Results: mta.receiver.com; dkim=pass (2048-bit key) header.d=yoursender.com header.s=s1 header.b=abcdef12 — A Healthy Header

The industry consensus, reflected in NIST recommendations and vendor best practices, is that 2048-bit RSA keys provide the minimum acceptable level of security for today's computational landscape. Anything less, particularly 1024-bit, is a legacy vulnerability. Your job is to treat it as one.

The Audit: Uncovering Every Last Sender

You can't upgrade what you don't know exists. Your biggest challenge isn't technical; it's organizational archeology. You need to find every single service, platform, and appliance that sends email using your domain. Your primary source of truth is your DMARC aggregate (RUA) report data.

Parsing DMARC Aggregate Data

These XML reports, sent by receivers, contain a wealth of information about how your domain is seen in the wild. For this project, you're focused on the records that show a DKIM authentication result. You need to parse these reports and extract every unique combination of signing domain (d=) and selector (s=) that appears. A simple script can iterate through the XML files and build a list.

Pay close attention to sources that are passing SPF but failing DKIM, or vice-versa. This often points to complex mail flows, like forwarders, which can break SPF (as described in RFC 7208). DKIM is designed to survive forwarding, but only if the key is strong. Also, don't ignore results that show `temperror` or `permerror`; they often point to misconfigurations that can hide underlying security weaknesses.

Don't Forget the Long Tail

Your DMARC data will quickly pinpoint the big senders: Google Workspace, Microsoft 365, Mailchimp, SendGrid. The real work is finding the long tail. Think about your HR platform that sends offer letters, your finance software that sends payment reminders, your building's visitor management system, or even network appliances that send alert emails. Cross-reference your DMARC findings with DNS records and procurement records. This phase is about exhaustive discovery.

Validation: Finding the Weak Keys

With your list of selectors and domains from the audit, you now need to check the length of each public key. The DKIM public key is stored in a TXT record in your DNS, following a standard format.

[selector]._domainkey.[domain]

Manual Checks Using `dig`

For any given selector, you can perform a DNS lookup to retrieve the key data. The `p=` tag in the TXT record contains the Base64-encoded public key. You can then decode this and check its length. Using a command-line tool like `dig` and `openssl` makes this straightforward.

First, you query the TXT record: `dig +short TXT s1._domainkey.example.com`. This will return a string like `"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."`. Copy the value after `p=`. Then, you can pipe it into OpenSSL to analyze it: `echo 'MIGfMA0GCSqGSIb3DQEBA...' | base64 --decode | openssl rsa -pubin -text -noout`. The output will explicitly state the key length, such as `RSA Public-Key: (1024 bit)`.

Automating the Scan

Performing this manually for dozens or hundreds of selectors is tedious and error-prone. This task is ripe for automation. A simple shell or Python script can take your list of selectors, perform the DNS lookups, extract the public key data, and use a cryptographic library to determine the key length. Your script should output a simple report: Selector, Domain, Key Length, Status (WEAK/OK). This becomes your remediation checklist.

The Vendor Coordination Playbook

Now you have your target list: every selector associated with a 1024-bit key. Getting them upgraded requires a diplomatic but firm approach with your third-party vendors. Most major SaaS providers (Salesforce, SendGrid, Marketo, etc.) have a documented process for rotating DKIM keys, but you might need to push them to do it.

Initiating the Request

Do not open a vague support ticket saying 'please update our security.' You need to be specific. Your ticket should state: 'We are performing a security audit and have identified that the DKIM key used for selector [selector-name] for our domain [your-domain.com] is a 1024-bit RSA key. In accordance with NIST recommendations and industry best practices, we require all our email signing to use a minimum 2048-bit RSA key. Please provide instructions to generate and enable a new 2048-bit key for your service.'

This language demonstrates you've done your homework and removes ambiguity. Reference their own documentation if you can find it. Often, the process involves you clicking a 'Rotate Key' or 'Generate New Key' button in their admin portal, which will give you a new CNAME or TXT record to publish.

Managing Multiple Selectors

Vendors often provide two new records: one for an active selector and one for a future selector. This allows for zero-downtime rotation. You'll add both new DNS records. The service will begin signing with the new active key, and receivers will immediately be able to validate it. The old key remains in DNS for a transition period to validate any in-flight or delayed emails.

Cutover & Cleanup: The Final Step

Adding the new 2048-bit key record to your DNS is the easy part. Removing the old 1024-bit key record is where people make mistakes. Delete it too soon, and you will cause legitimate email to fail DMARC, potentially leading to bounces or spam-folding.

You must wait for a full signing cycle. This means allowing enough time for the vendor's infrastructure to fully propagate the change and stop using the old private key. It also accounts for the longest possible delay in an email delivery chain. A marketing email might be queued for several days before being delivered; if it was signed with the old key, that key's public record must still be available for validation when it finally arrives.

Monitor, Then Delete

The safe waiting period is typically 7 to 14 days. During this time, your job reverts to monitoring your DMARC RUA reports. You are looking for one specific thing: the complete disappearance of the old 1024-bit selector from your reports. Once you have gone multiple days without seeing a single email authenticated with the old selector, you can be confident it is no longer in use.

Only then is it safe to log into your DNS provider and delete the old TXT record. Document the change in your change management system, and your mission is complete. Repeat this process for every weak key on your list until your entire email footprint is secured with 2048-bit keys.

The takeaway

Retiring weak DKIM keys is more than a compliance exercise; it's a fundamental practice of good digital hygiene. Every email your domain sends is a statement about your brand's trustworthiness, and the signature on that email must be unimpeachable. A weak key anywhere in your ecosystem is a threat to the reputation you've built everywhere.

The process is methodical: audit, validate, coordinate, and cut over. It requires diligence and precision. While you can automate much of the initial DMARC data analysis with platforms like MailSleuth.AI, the principles of vendor coordination and careful cutover remain essential human tasks. Don't let a forgotten key from 2015 become the entry point for a 2025 breach.