What many DKIM selectors on one domain mean

A large number of DKIM signatures from different selectors on one domain is usually a signal to investigate, not automatic evidence of phishing. A selector is the label in the s= field; its public key is published under selector._domainkey in DNS.

One distinction matters: a message may contain several DKIM-Signature headers, while DNS may expose many selector records that no current message uses. Both can be normal for a busy sending architecture, so the count should be assessed alongside alignment, key ownership and recent mail flow.

Across Sydney, Melbourne, Brisbane and Perth, many small businesses send through Microsoft 365, Google Workspace, online stores, CRMs and accounting platforms while also using a dedicated email provider. Each service can preserve or add a signature, producing an unexpectedly broad selector inventory.

The practical question is whether every signing path is authorised and whether the visible From address is protected by SPF or DKIM alignment. A tool such as Trusted Sender Score can add reputation and configuration context, but it cannot replace message-level validation.

Why selector counts grow

DKIM signing normally happens when a mail platform signs outgoing content with a private key. The matching public key sits in DNS, and the selector tells recipients where to retrieve it. Separate platforms use separate labels even when they all send mail on behalf of one organisation.

Selectors also appear during routine key rotation, departmental delegation and service migrations. A retained record may support old mail, testing or disaster recovery. Shared sending platforms can add further keys, so identical visible domains do not necessarily identify a single operator.

How to read each signature

Each DKIM-Signature header identifies a signing domain in d= and a selector in s=. The s= value selects a key from DNS; the d= value tells the verifier whose key was used. Multiple signatures should therefore be grouped by both values rather than counted as a single undifferentiated number.

A valid signature proves that the signed content matches a key the verifier could retrieve. It does not alone prove that the visible From domain is authorised. DMARC requires an aligned valid DKIM signature or aligned SPF result, and the DMARC alignment guidance gives a practical way to distinguish those conditions. Invalid signatures mixed into otherwise sound mail are not automatically evidence of compromise.

Common legitimate causes

Many organisations run marketing, transactional, support and internal systems that each publish their own DKIM key. A retailer’s storefront may sign receipt emails while its ticketing platform signs event notices, even though both appear from the same .com.au domain.

Key lifecycle activity is another common source. Administrators may create a new selector before retiring an old one, especially during phased rollouts. Delegated sending subdomains, service-provider arrangements and acquired brands can also increase the count without indicating unauthorised activity.

Signs worth investigating

Warning signs include selectors associated with unknown vendors, keys that appeared without a corresponding business change, or several services able to sign as the same protected domain. Unexplained changes to DNS hosting, abrupt shifts in signing providers and long-retired keys with unusual traffic deserve review.

Conversely, a large number of published keys is not proof that an attacker can impersonate a sender. Public DNS keys do not by themselves enable forged signatures without the corresponding private key. Risk depends on whether that key is exposed, compromised, still authorised or tied to a provider outside the organisation’s expected chain.

Australian operating context

Australian organisations commonly use .com.au and direct .au registrations, and domain ownership can involve agencies, resellers or internal IT teams. This matters because several parties may administer DNS during an acquisition or migration. The Australian Signals Directorate’s email security guidance treats SPF, DKIM and DMARC as complementary controls rather than interchangeable checks.

Commercial senders must also comply with the Spam Act 2003, which governs consent, sender identification and unsubscribe mechanisms for marketing messages. Separately, teams that retain message headers, IP addresses or recipient data may need to consider the Privacy Act 1988. Using an external checking service should be assessed against applicable handling terms, including the sender verification terms supplied with the platform.

A disciplined review process

Begin with a representative set of outbound and inbound message headers, then map each selector to its DNS key, provider, signing domain and DMARC alignment status. Confirm that legitimate keys are intended, note which are dormant and check whether revoked keys have actually been removed. Deleting a record too early can cause legitimate mail to fail authentication.

For larger estates, bulk domain checks and an API are more reliable than manual sampling. Trusted Sender Score offers a free trust checker, while its reputation, DKIM, DMARC and anti-spoofing views help teams compare configuration with observed sender trust. Findings should be recorded with dates and ownership so later DNS changes can be traced.

What the count really tells you

A high selector count is best treated as an inventory signal. When every key maps to an approved provider, alignment is enforced and obsolete records are controlled, the volume may simply reflect a mature multi-platform mail setup. It is not, by itself, a phishing verdict.

The count becomes meaningful when paired with evidence of unauthorised signing, weak DMARC enforcement or unexplained provider changes. Separating the harmless artefacts of scale from those substantive failures turns a noisy selector list into a defensible view of sender risk.