The Unseen Surface: A Guide to Finding All DKIM Selectors

A penetration tester checks a target's DNS. They see the standard SPF record, a DMARC policy, and query for `selector1._domainkey.example.com`. It resolves. They check `google._domainkey.example.com`. It resolves, too. Both are strong 2048-bit keys. The tester marks DKIM as 'secure' and moves on. This is a critical mistake.

That same domain has another record: `mktg-2019._domainkey.example.com`. It points to a 1024-bit RSA key for a marketing platform the company churned from three years ago. The DNS record was never deleted. That forgotten key is the foothold. It represents a cryptographic liability that most reconnaissance scans will miss entirely.

Finding every DKIM selector for a domain is not just an academic exercise. It's a vital piece of offensive reconnaissance that maps a hidden attack surface. The defaults are just the beginning.

Default Selectors Are Just the Warm-Up

Every time you onboard a new service that sends email on your behalf—be it a marketing platform, a CRM, a helpdesk, or a transactional email API—you create a new DKIM key pair. The public key gets published in your DNS at a unique location specified by a 'selector'. This selector is just an arbitrary string, defined by the sending service, that tells receiving mail servers which public key to use to verify a signature.

The result is selector proliferation. You might have `sendgrid._domainkey` for SendGrid, `zdesk1._domainkey` for Zendesk, and `sfmc._domainkey` for Salesforce Marketing Cloud. This segmentation is good practice; it isolates signing keys so a compromise of one vendor doesn't invalidate signatures from all others. But it also creates a sprawling, often un-audited, set of DNS records.

The operational risk is stale records. Teams move fast. Vendors are swapped out, projects are decommissioned. But the offboarding checklist rarely includes 'Delete the old vendor's DKIM record from DNS'. These forgotten selectors are cryptographic deadweight, and sometimes, they point to dangerously weak keys.

Technique 1: Let DMARC Reports Do the Spying for You

If you can get your hands on them, DMARC aggregate reports are the single best source for discovering active DKIM selectors. As defined in RFC 7489, a domain owner can publish a DMARC record with a `rua=mailto:address@example.com` tag. This requests that major mailbox providers like Google and Microsoft send daily XML reports summarizing all the mail they saw claiming to be from that domain.

Parsing the Report for Selectors

These reports are a goldmine. For every email received, they detail the sending IP, the SPF result, and, most importantly for our purposes, the DKIM signature results. Each DKIM authentication attempt is logged, including the exact selector that was used.

<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>1</count>
<policy_evaluated>
...
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>google.com</domain>
<selector>20230601</selector>
<result>pass</result>
</dkim>
</auth_results>
</record>

An attacker who gains access to the mailbox receiving these reports—or finds a DMARC service dashboard with a leaked API key—can parse a few days' worth of XML and build a near-perfect list of every selector actively signing mail for that domain. This isn't theoretical; it's a standard post-compromise intelligence gathering step. It tells you exactly which vendors and systems are in use, as seen by the rest of the world.

Technique 2: Brute-Forcing with an Educated Dictionary

When you don't have insider access to DMARC reports, the next best thing is intelligent brute-forcing. This isn't a blind, random assault on DNS. It's a targeted query process using a wordlist curated from common vendor practices and naming conventions.

Building the Wordlist

Your wordlist should be built in layers. Start with the basics: `selector1`, `selector2`, `default`, `dkim`, `dkim1`. Then, add common service providers and platforms: `google`, `mandrill`, `mailchimp`, `sendgrid`, `sparkpost`, `aws`, `ses`, `amazonses`, `zendesk`, `salesforce`, `sfmc`, `mta`, `smtp`. Finally, include patterns based on dates and quarters, which are common for key rotation schemes: `q12023`, `q22023`, `mar2024`, `20240101`.

With this wordlist, a simple shell script can iterate through each potential selector and perform a DNS query. For example: `for s in $(cat selectors.txt); do host -t TXT $s._domainkey.example.com; done`. You're looking for any response that isn't `NXDOMAIN`. A `NOERROR` response with a TXT record is a confirmed hit.

Technique 3: Scouring Public Mailing List Archives

One of the most effective, purely OSINT-based methods is to find emails sent by someone at your target company to a public mailing list. Archives for open-source projects, community forums, and academic lists often store the full, raw source of every email sent, including all headers. This is a treasure trove of metadata.

The header we care about is `DKIM-Signature`, specified in RFC 6376. It contains all the information about the signature applied by the outbound mail server, including the selector used in the `s=` tag.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=pm-2023q4; h=...; bh=...; b=...

By finding just one of these archived emails, you can extract a confirmed, in-use selector (`pm-2023q4` in the example above) without sending a single packet to the target's infrastructure. Using search engine dorks like `site:lists.someproject.org from:example.com` can quickly reveal these archives. Once you find one, you can often scrape it for multiple selectors from different employees who might be using different mail systems.

The Payoff: Analyzing Discovered Keys for Weaknesses

So you have a list of selectors. The reconnaissance phase is over; now analysis begins. Each discovered TXT record needs to be inspected for two primary weaknesses.

Weak Key Lengths (1024-bit RSA)

The number one finding is a weak public key. The DKIM standard was written when 1024-bit RSA keys were common. Today, they are considered breakable by well-resourced adversaries. Most major receivers, including Google, have stopped treating 1024-bit signatures as secure. When you find a DKIM record, extract the base64-encoded string from the `p=` tag and check its cryptographic strength. Finding a 1024-bit key means that any email signed with that key—even if the signature passes validation—is cryptographically weak. It's often a sign of an old, forgotten integration.

The Test Mode Flag (t=y)

A more subtle but equally important finding is the 'test mode' flag: `t=y`. According to RFC 6376, this tag signifies that the domain is in a testing phase for DKIM. The RFC states that verifiers "MUST NOT treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify." An attacker could potentially send a forged email that fails DKIM validation, knowing that the receiving server might ignore the failure because of the test flag. It's a misconfiguration that neuters the security benefit of the signature.

The Defensive Play: Auditing Your Own Domain

The good news is that every offensive technique described here is also a powerful defensive tool. The best way to secure your domain is to think like an attacker trying to find its weak points.

First, use DMARC aggregate reports as your ground truth. Systematically parse them to build a definitive inventory of all selectors observed signing mail for your domain. Anything in that list you don't recognize is an immediate incident for investigation.

Second, run the same dictionary-based brute-force scans against your own domains. This helps find selectors that are published in DNS but may no longer be in active use—the most dangerous kind of stale record. Any discovered key that isn't on your master inventory of active senders should be investigated and removed.

Finally, establish a process. DKIM management can't be a one-time cleanup. It requires a regular audit cycle, tied to your vendor onboarding and offboarding processes. When a service is decommissioned, removing its DKIM record must be part of the standard operating procedure.

The takeaway

DKIM selectors are more than just DNS trivia. They are a distributed, often-forgotten map of a company's entire email-sending architecture and vendor history. The proliferation of SaaS tools ensures that this attack surface is constantly growing, and manual audits rarely keep pace.

A complete DNS inventory isn't just your A, MX, and root TXT records. It's every `_domainkey` subdomain you've ever created. Continuous monitoring, whether through manual scripting or automated platforms like MailSleuth.AI, is the only way to ensure old keys don't become future footholds. Go check your selectors. You might be surprised what you find.