Set up DKIM and verify the signature actually being used

Define the decision

A DKIM record in DNS is only one part of the setup. The sending service must use the matching private key and place a signature on the message. A scanner can find a record even when the live sender uses another selector.

Work through the procedure

1. Generate or retrieve DKIM settings from the sending service you actually use.
2. Publish its exact TXT or CNAME record at the specified selector name.
3. Query the resulting public DNS and enable signing through the provider.
4. Send a fresh controlled message and compare its s= and d= values with the configured record.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Published name: launch._domainkey.example.com
Received signature: s=legacy; d=example.com
Diagnosis: the test used the legacy selector
Next step: verify provider activation, not another edit to the launch record

Read the result

Treat a passing received signature as stronger evidence than a dashboard’s record-found indicator. When multiple services sign, test each service independently; enabling DKIM for one does not configure the others.

Check before moving on

1. Keep private keys out of DNS and support tickets.
2. Check that the DNS editor did not append the domain twice.

Limits and next action

Use the provider’s supported key management process. Do not manufacture a public key or copy sample cryptographic material into production.

Source: RFC 6376: DKIM signatures and selectors