Why common DKIM selectors attract unwanted attention

A domain with a DKIM signature using a common selector is easy for attackers to discover because the selector is exposed during normal email delivery. DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages and identifies the public key through a DNS record such as selector1._domainkey.example.com. Receiving mail systems use that information to verify that the message was authorised by the sending domain.

The signature improves email authentication, but it does not make the selector secret. Attackers can inspect message headers, query DNS, analyse public datasets and test predictable names at scale. A common selector is therefore a useful starting point for reconnaissance, particularly when it is connected to an old key, a weak configuration or several unrelated services.

How DKIM selectors become visible

Every signed email normally includes a DKIM-Signature header. Its s= value identifies the selector, while the d= value identifies the signing domain. Someone examining a legitimate message sent by a business in Sydney, Melbourne or Brisbane can often see both values without accessing the organisation’s systems.

DNS makes the next step straightforward. A selector such as default, google, k1, s1 or selector1 can be queried at the domain’s _domainkey namespace. Automated tools can test common selector dictionaries across thousands of Australian business domains, including .com.au and .au addresses. Reviewing sender trust metrics can help place DKIM findings alongside domain reputation and other authentication signals.

Why predictable names help reconnaissance

A common selector does not automatically mean that a domain has been breached. The main weakness is predictability: attackers can identify the likely DNS location without needing to guess a long random value. They may then catalogue the public key, key length, record age, associated providers and whether multiple selectors appear to point to the same infrastructure.

This information supports phishing and impersonation campaigns. An attacker might copy the visible structure of a company’s mail system, search for forgotten selectors or look for services that still sign with a retired key. If a private key has been exposed through a compromised vendor, backup, source repository or poorly protected server, knowledge of the matching selector can make forged messages easier to construct and troubleshoot.

The risks of reused and neglected keys

Some organisations reuse one selector across Microsoft 365, marketing platforms, ticketing systems and local email gateways. That arrangement can create an unnecessarily broad blast radius. A flaw in one service may expose a key used elsewhere, while a change to one provider’s configuration can leave confusing or conflicting DNS records behind.

Key rotation is another common weakness. An old selector may remain published for years because removing it feels risky, even though the related private key is no longer needed. Attackers routinely study abandoned infrastructure, and an outdated DKIM record can reveal past providers, former hosting arrangements or a signing identity that has not been reviewed since a business moved platforms.

How Australian organisations can reduce exposure

A stronger approach uses unique, high-entropy selector names for each sending service, rather than relying on familiar labels. Use DKIM keys of at least 2048 bits where supported, protect private keys in the provider’s secure system, and rotate them on a documented schedule. When a service is retired, remove its signing capability and delete the corresponding DNS record after allowing for normal mail flow and DNS caching.

DKIM should operate with SPF and DMARC, including appropriate alignment between the visible From domain and the authenticated domain. DMARC reporting can reveal unauthorised sources and configuration drift. This is particularly relevant for Australian firms handling customer information under the Privacy Act 1988 and the Notifiable Data Breaches scheme, where an email compromise may become part of a broader privacy incident.

Monitoring matters more than obscurity

Hiding a selector is not a realistic defence because legitimate recipients need to discover the public key, and every signed message can disclose the selector. The useful objective is to limit what an attacker can do with that information: use separate keys for separate services, remove stale records and monitor unexpected signing activity.

Security teams can combine DNS reviews, DMARC aggregate reports, mail-header analysis and reputation checks. A retailer sending promotions before the morning commute, a council communicating with residents or a Perth professional firm exchanging invoices may all use several outbound platforms without realising that each adds an authentication record. Regular inventory reviews help identify those services and support a reliable sender profile. Guidance on checking an unknown sender can add context when a suspicious message appears.

A common DKIM selector is therefore a discovery shortcut, not a standalone vulnerability. The real exposure comes from predictable naming combined with weak key protection, excessive reuse, missing rotation or poor visibility across the organisation’s email supply chain.