Modees"DKIM is set up" is one of those statements that can be true and useless at the same time. A key pair can exist, the DNS record can be published, and every message can still fail authentication because the selector in the signature does not match the record anyone checked.
The selector is the part of DKIM that makes the lookup possible. It is a short label — google, selector1, s1, resend — that points to a DNS name. Without the right one, the public key is invisible.
Where the selector lives
A DKIM key record sits at:
<selector>._domainkey.<domain>
The signature in the message names the selector in s= and the signing domain in d=. The receiver takes those two values, builds the DNS name, fetches the public key and verifies the hash.
So three things have to agree:
- the
s=in the message, - the DNS record at
<s>._domainkey.<d>, - and the
d=domain, which should align with theFrom:address.
A provider dashboard showing "DKIM verified" usually means the provider checked its own default selector. It does not prove the selector on the message your client actually sends.
Find the selector in a real message
Ask for the raw source of a recent message, then look at two headers:
DKIM-Signature: v=1; a=rsa-sha256; d=client.example; s=selector1; ...
Authentication-Results: ... dkim=pass header.d=client.example header.s=selector1
The s= value is the selector. The d= value is the domain that signed. If the message has several DKIM-Signature headers — common when a platform signs with its own domain and the customer's — read every one. A pass on the platform's domain does not help your client's From domain.
If you cannot get a raw message, query the domain for likely selectors. Start with what the provider documents; then check the provider's DNS setup page. Do not guess a dozen names and call the first hit "the" selector, because an old key can still be published after a migration.