Zombie DKIM Keys: How to Audit and Prune Your DNS Graveyard

You’re sifting through a fresh DMARC aggregate report when you spot it: a DKIM signature from a selector you don’t recognize, passing authentication for your domain. Your heart rate ticks up. A quick DNS query reveals a TXT record for `zylker-2018._domainkey.yourdomain.com`. Zylker? The marketing platform you trialed four years ago and abandoned after a month. The key is still live. This is the zombie DKIM key problem, and your DNS is likely full of them.

These records accumulate innocently. Every time a new service needs to send email on your behalf—a CRM, an HR platform, a customer support tool—the setup guide tells you to publish a new DKIM key in your public DNS. You copy, you paste, and you move on. But what about when you migrate to a new ESP? Or when a department cancels a SaaS subscription? The offboarding checklist rarely includes, "Remove the vendor's DKIM key from our DNS."

So they sit there. Forgotten, but not gone. These digital ghosts clutter your zone file and, more importantly, represent a latent and unnecessary security risk. It’s operational debt, and it’s time to pay it down.

Your DNS is a Graveyard of Good Intentions

No one sets out to create a messy DNS zone. These orphaned records are the byproduct of business as usual. They are digital scars from past projects, vendor relationships, and technology stacks.

The Vendor Onboarding/Offboarding Gap

Think about the last time you integrated a third-party service that sends email. The process is standardized: they provide a DKIM selector and a public key, and you create a TXT record. This grants them the authority to sign messages as you. When the contract ends, however, the process is rarely reversed. The vendor deactivates your account on their side, but the public key remains in your DNS. It's an operational loose end. You've revoked their access to your building, but you left their ID card in the global directory.

This gap exists because the teams that manage DNS (IT, DevOps) are often different from the teams that manage vendor relationships (Marketing, Sales, HR). The marketing team that canceled their MailChimp account doesn't send a ticket to IT to remove `k1._domainkey` and `k2._domainkey` from the zone file. This communication breakdown is the primary source of zombie keys.

Migrations and 'Just-in-Case' Records

Another major contributor is platform migration. When you move from, say, Office 365 to Google Workspace, you configure new DKIM keys (`selector1` and `selector2` for Microsoft, `google` for Google). But what happens to the old keys? Often, they're left in place "just in case" a few mailboxes were missed or some forwarding rule depends on them. This temporary fallback becomes a permanent fixture. Years later, no one can say with certainty whether `selector1._domainkey` is safe to delete. It's easier to leave it alone than risk breaking something.

The Latent Threat of 1024-bit Keys and Test Flags

So they’re just unused DNS records. What’s the harm? The risk lies in the possibility of misuse. If an attacker ever compromises the corresponding private key from that old, forgotten vendor's infrastructure, they can craft emails that pass DKIM authentication for your domain. Your DMARC policy, which relies on that DKIM alignment, will see a valid signature and pass the message.

Weak Keys Are Brittle Keys

Many of these older, forgotten keys are 1024-bit RSA keys. The current best practice, as stated by NIST, is to use 2048-bit keys. While factoring a 1024-bit key is still computationally expensive and not something a script kiddie can pull off, it's considered within the reach of well-funded adversaries or nation-state actors. It's a brittle defense. Why leave a weaker lock on a door you don't even use anymore? The existence of a 1024-bit key in your DNS is a clear signal that your security hygiene needs attention. It's an easy win to remove them and reduce this theoretical attack surface.

The 't=y' Flag: A Test Mode Left On

Digging through old keys, you'll inevitably find some with a `t=y` tag. According to RFC 6376, this signifies that the key is in 'test mode' and that receivers should not treat a failing signature from this key as a definitive failure. The intent was to let domains test their DKIM setup without impacting mail flow. The problem is, enforcement is wildly inconsistent. Many mail receivers ignore the `t=y` flag entirely. They see a passing signature and they pass it; they see a failing signature and they might still deliver it.

sendgrid._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD...[old 1024-bit key]...AQAB"

An attacker compromising a key marked for testing might be able to get their email signed and delivered, bypassing scrutiny because the operator assumed the 'test' flag was a safety shield. It is not. A `t=y` flag on a production domain is a misconfiguration.

A Playbook for Auditing Signatures vs. Published Keys

Theoretical risks are one thing; a tactical plan is another. To audit your DKIM keys, you need to answer one question: Which keys published in our DNS are actually being used to sign our legitimate email?

The process involves creating two lists. The first is a complete inventory of every DKIM selector published in your DNS. The second is a list of every DKIM selector observed signing mail from your domain in the wild. The zombies are the keys on the first list but not the second.

Step 1: Enumerate All Published Keys

This is harder than it sounds. There is no standard way to ask a DNS server, "Show me all `_domainkey` records." Your best source of truth is your own DNS zone file or management console. Log into your DNS provider (e.g., Route 53, Cloudflare, Infoblox) and search for all TXT records under `_domainkey.yourdomain.com` and its subdomains. This is your master list of declared keys.

If you don't have direct access, you can try to guess common selectors. Scripts and online tools can brute-force queries for `google._domainkey`, `s1._domainkey`, `mandrill._domainkey`, etc. This is imperfect but can uncover obvious ones you've forgotten.

Step 2: Collect Live Signature Data

This is where DMARC becomes your most powerful auditing tool. DMARC aggregate reports, sent by receivers back to you, contain detailed information about which DKIM keys they saw signing your email. Inside the XML data, you'll find records for every combination of sending IP, SPF result, and DKIM result.

Authentication-Results: mx.google.com; dkim=pass header.i=@yourdomain.com header.s=selector-2023 header.b=aBcDeFg; spf=pass (google.com: domain of support@yourdomain.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=support@yourdomain.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

The key is the `header.s=` field in the `Authentication-Results` header, which is reported in the DMARC XML. By parsing these reports over a period of 30 to 90 days, you can build a comprehensive list of all selectors that are actively being used. The longer the lookback period, the more confident you can be that you've caught even low-volume senders.

Correlating DMARC Data to Find the Zombies

Now you have your two lists: List A (all keys published in DNS) and List B (all keys seen in DMARC reports). The correlation process is simple subtraction: Any selector in List A that does not appear in List B is a candidate for removal. It's a zombie.

Parsing raw DMARC XML is tedious, so use a DMARC analysis tool. These platforms will ingest your reports and present this data clearly, often showing you a list of published keys and when each was last seen. This automates the most labor-intensive part of the audit.

For each zombie selector, perform a final sanity check. Is it possible the service is extremely low-volume, like an annual compliance notification system that hasn't sent mail in your 90-day window? The selector name (`everfi-compliance._domainkey`) might be a clue. This requires some institutional knowledge to track down. When in doubt, proceed with the cautious removal process described next, but for the majority of forgotten vendor keys, they will simply have zero traffic associated with them.

The Deprovisioning Checklist: Remove Keys Without Breaking Mailflow

Once you've identified a zombie key, don't just rush to delete it. A hasty deletion could, in a rare edge case, break a critical but low-volume mail flow. Instead, follow a phased approach to safely deprovision the key.

The 'Empty p=' Safety Net

Instead of immediately deleting the DNS record, first 'neuter' it. Edit the TXT record and remove the public key data, leaving the `p=` value empty. The record should look like `v=DKIM1; p=`. This effectively revokes the key.

Why do this? Because it creates a loud failure. If some forgotten system *was* still using that key, its signatures will immediately start failing DKIM validation. These failures will show up prominently in your DMARC failure reports. This is your safety net. By replacing the key instead of deleting it, you turn a silent, potential problem into a noisy, observable event. If you see no new failures related to that selector for a few weeks, you can be confident it's truly unused.

The Final Deletion and Documentation

After your observation period (14-30 days is usually sufficient) with the empty `p=` value, and with no new fires to put out, you can now safely delete the TXT record from your DNS. The final, crucial step is to document what you did. Add an entry to your internal knowledge base or change management system: "Decommissioned DKIM key `zylker-2018._domainkey` on [date]. It belonged to the Zylker marketing platform, which was offboarded in 2018. Key was confirmed unused via DMARC analysis over 90 days."

This documentation prevents the next engineer from wondering what that key was and saves your future self from repeating the same investigation.

The Final Deprovisioning Checklist

Once you've identified a zombie key, don't just rush to delete it. A hasty deletion could, in a rare edge case, break a critical but low-volume mail flow. Instead, follow a phased approach to safely deprovision the key.

Step 1: The 'Empty p=' Safety Net

Instead of immediately deleting the DNS record, first 'neuter' it. Edit the TXT record and remove the public key data from the `p=` tag, leaving it empty. The record should look like `v=DKIM1; k=rsa; p=`. This effectively revokes the key.

Why do this? Because it creates a loud failure. If some forgotten system *was* still using that key, its signatures will immediately start failing DKIM validation. These failures will show up prominently in your DMARC failure reports. This is your safety net. By replacing the key instead of deleting it, you turn a silent, potential problem into a noisy, observable event. If you see no new failures related to that selector after a few weeks, you can be confident it's truly unused.

Step 2: The Final Deletion and Documentation

After your observation period (14-30 days is usually sufficient) with the empty `p=` value, and with no new fires to put out, you can now safely delete the TXT record from your DNS. The final, crucial step is to document what you did. Add an entry to your internal knowledge base or change management system: "Decommissioned DKIM key `zylker-2018._domainkey` on [date]. It belonged to the Zylker marketing platform, which was offboarded in 2018. Key was confirmed unused via DMARC analysis over 90 days."

This documentation prevents the next engineer from wondering what that key was and saves your future self from repeating the same investigation.

The takeaway

Auditing your DKIM keys isn't a one-time project; it's a recurring hygiene practice that should be part of your security program. Schedule a review quarterly or semi-annually. The process gets faster each time as your DNS becomes cleaner and your documentation gets better. Parsing raw DMARC XML to identify unused selectors is the biggest hurdle, which is why services like MailSleuth.AI exist to automate that correlation for you.

Cleaning up your DNS zone isn't just about tidiness. It's about reducing your attack surface and removing ambiguity from your mail authentication posture. Every zombie key is a door you left unlocked to a building you no longer own. It's time to go change the locks.