Ghost Keys: Weaponizing Abandoned DKIM Records for Phishing

There's a unique satisfaction in finding a server that's been forgotten but not buried. It’s a ghost in the machine—a lingering presence that exposes a company’s past decisions. For a red teamer, these digital ghosts are more than just curiosities. They are footholds.

Nowhere is this more true than in a target's public DNS zone. We often talk about SPF and DMARC, but the real historical artifacts lie within DomainKeys Identified Mail (DKIM) records. Defined in RFC 6376, DKIM provides a cryptographic signature to prove an email's integrity. To do this, senders publish public keys in DNS at a specific location called a 'selector'. While most of these are active and legitimate, some are relics of services long since abandoned.

And those relics are abusable.

Sifting Through the Digital Dust: DKIM Selector Enumeration

Every DKIM-signed email contains a `DKIM-Signature` header with a selector tag (`s=`). The receiving mail server uses this selector to find the public key via DNS. The lookup query is simple: `s-value._domainkey.d-value`. If your email claims to be from `example.com` and uses the selector `mta1`, the receiver queries `mta1._domainkey.example.com` for a TXT record containing the key.

Our first step in DKIM record reconnaissance is to find *all* published selectors for a target domain, not just the ones in active use. We can't rely on passively receiving emails. We need to proactively enumerate them. While there's no standard mechanism to list all selectors, we can make highly educated guesses based on common patterns.

This isn't subtle. It's a brute-force dictionary attack against a domain's `_domainkey` subdomain. We check for common platform defaults (`google`, `s1`, `s2`, `mandrill`, `sf`, `em`), sequential numbers, date formats, and service names. A simple shell script iterating `dig txt [selector]._domainkey.target.com` against a wordlist will often uncover a surprising number of valid records. Some will be live. Some will be dead. Both are interesting.

Connecting the Dots, Finding the Gaps

Once we have a list of published DKIM selectors, the next step is correlation. We need to map each selector to the service that uses it. This is investigative work, connecting digital artifacts to real-world vendor relationships.

Mapping Selectors to Services

Sometimes the selector name itself is a dead giveaway: `salesforce._domainkey` or `zendesk1._domainkey`. Other times, the record type provides the clue. Many SaaS platforms instruct their customers to create a `CNAME` record pointing back to their own infrastructure. This allows the vendor to manage key rotation without requiring the customer to update their DNS records constantly.

selector123._domainkey.target.com. 3600 IN CNAME selector123._domainkey.some-esp.net.

Following these CNAME chains tells us exactly which third-party service is, or was, authorized to send email on behalf of our target. Even a TXT record's `p=` value (the public key) can sometimes be fingerprinted back to a specific provider. We are building a map of the target's email ecosystem.

Cross-Referencing with SPF

This is where we find the ghosts. The map of DKIM-authorized senders must be compared against the map of SPF-authorized senders. An SPF record (RFC 7208) lists all IPs and services permitted to send mail. When a company offboards a marketing platform or CRM, the diligent admin removes the `include:sendgrid.net` or `ip4:x.x.x.x` from the SPF record. This immediately stops those servers from passing SPF checks.

But what they often forget to do is remove the corresponding DKIM records. They cut off one authentication path but leave the other dangling. When we find a DKIM selector pointing to `some-esp.net`, but `some-esp.net` is no longer referenced anywhere in the target's SPF record, we have likely found an abandoned selector. This is our signal. The trust relationship was terminated, but the evidence of it—the public key—was left behind.

Forging the Ghost Key: Attack Payloads

Finding an abandoned DKIM record is one thing; weaponizing it is another. The goal is to send an email from an infrastructure we control, which nonetheless passes a DKIM check against the target's domain. A successful DKIM pass is a powerful trust signal to receiving mail servers, especially if the target has a DMARC policy (RFC 7489) that requires alignment.

Vector 1: Subdomain Takeover

The most potent attack vector arises when the abandoned DKIM record is a CNAME pointing to a domain or subdomain that is now available for registration. This is a classic subdomain takeover vulnerability, but targeted specifically at email authentication.

Imagine `selector123._domainkey.target.com` points to `dkim.client-instance.defunct-saas.com`. If the client cancelled their DefunctSaaS account, that `client-instance` subdomain might be freed up. Or, if `defunct-saas.com` itself has expired, the entire domain might be for sale. By registering this dangling pointer, we gain control over the DNS for `dkim.client-instance.defunct-saas.com`. We can now publish our own TXT record with a new public key. We generate a new DKIM private key, configure our own mail server to sign with it using the `s=selector123` selector, and send an email.

When a receiver like Google or Microsoft gets our email, it sees the `s=selector123` selector for `d=target.com`. It queries `selector123._domainkey.target.com`, gets the CNAME, follows it to our controlled domain, retrieves our public key, and validates our signature. The result? A `dkim=pass` in the `Authentication-Results` header. If `target.com` has a DMARC policy of `p=reject`, our message sails right through because we achieved DKIM alignment. This is the holy grail for a phishing campaign.

Vector 2: Social Engineering Pretext

Even if a takeover isn't possible, the knowledge of the abandoned relationship is valuable intel. It provides a highly credible pretext for social engineering. Instead of a generic phishing email, you can craft a message that references the past. 'Hi, this is Bob from DefunctSaaS. I know you folks stopped using our platform last quarter, but our records show a final invoice was never processed.' This kind of detail immediately disarms a target. It doesn't feel random; it feels contextual and legitimate. The reconnaissance work fuels a more believable and effective phish, even without a technical exploit.

Exorcising the Ghosts: A Decommissioning Playbook

For blue teams and IT administrators, this isn't just about theory. It’s about operational hygiene. Every time a third-party service with send-on-behalf-of capabilities is decommissioned, a full cleanup is required. Leaving old DNS records behind is not just messy; it’s negligent.

Your offboarding checklist for any ESP, CRM, or support platform must include explicit DNS steps. It's not enough to just stop paying the bill. You're trying to revoke a trust relationship you previously advertised to the entire world.

It's simple: if you remove the `include:` from SPF, you must also remove the corresponding `_domainkey` TXT/CNAME record. — Every SOC Analyst

Treat your public DNS zone as part of your active attack surface. It requires periodic auditing, not just reactive changes. Look for your own ghost keys. Enumerate your own selectors and ask the hard questions. Do we still use this service? Who owns this integration? If you can't map a DKIM selector to an active, approved vendor, it needs to be investigated and likely removed. Indefinite trust is a liability.

Bonus: The ARC Complication

Email is never simple. Authenticated Received Chain (ARC), defined in RFC 8617, adds another layer. ARC is designed to preserve email authentication results across multiple hops, like mailing lists or complex forwarding arrangements, which are notorious for breaking SPF and sometimes DKIM. An intermediary adds an `ARC-Authentication-Results` header, and then cryptographically signs the new state with an `ARC-Seal`.

From an attacker's perspective, this means that even if our initial injection point is an obscure mail server, a `dkim=pass` can get 'stamped' into an ARC chain, lending it legitimacy as it traverses the mail ecosystem. A downstream filter might see the broken SPF from the final hop but trust the validated ARC chain that includes our original, pristine DKIM pass. Exploiting an abandoned DKIM key can have a ripple effect, laundered through legitimate but complex mail routing.

The takeaway

Public DNS records are not set-it-and-forget-it configurations. They are living declarations of trust. The half-life of these declarations can extend long past the life of the commercial relationships they represent, creating a persistent, low-hanging opportunity for attackers performing methodical DKIM record reconnaissance.

Auditing your own domain for these ghost keys should be a routine part of your security posture management. Don't wait for a red teamer to do it for you. Proactive analysis of your entire email sending surface, including all historic DKIM selectors, is the only way to ensure the ghosts of vendors past don't come back to haunt you. Platforms like MailSleuth.AI can automate this discovery, turning a week of manual `dig` commands into a continuous monitoring process.