Choose the source and preserve a usable message example
Select a controlled message from the actual business route: staff mail, a website notification, an invoice or another platform. Record the sending application, approximate time with timezone and receiving environment. Testing a staff mailbox does not establish what a separate invoicing or form service does, even if the visible sender names look similar.
Use the receiving system's view of the original headers and redact private content before sharing evidence. A screenshot of the From line is insufficient for this check. Keep the original message available to the authorized reviewer, but do not publish complete private mail threads, session information or credentials in a support form.
Read the selector and signing domain together
In a DKIM-Signature field, s= identifies the selector and d= identifies the signing domain. Together they identify the DNS lookup location in the form selector._domainkey.signing-domain. A message may contain multiple signatures. Record each relevant pair rather than mixing the selector from one signature with the domain from another.
Use the values in the message and the provider's current configuration. A provider may generate tenant-specific names or change its publication arrangement, so a familiar selector from an online tutorial is not proof that the business uses it. The domain after d= may also differ from the visible From domain.
Inspect the published key through the supported DNS route
Check the location derived from the selected signature. Some services publish a TXT key directly; others use a CNAME arrangement that leads to provider-managed data. Record the observed answer, any relevant delegation and the lookup time. Resolve the intended chain rather than copying a destination into the wrong place or creating competing record types.
Compare the answer with what the responsible provider currently specifies for this domain. If it is missing or inconsistent, preserve the original values and agree an authorized correction. Public key material belongs in the supported publication process; private signing keys do not belong in DNS or an enquiry. Do not remove an old selector solely because a newer one now appears.
| Check | Evidence to retain | What the check cannot establish |
|---|---|---|
| Message identity | Source, received time and the chosen signature | That every sending platform uses the same configuration. |
| Selector/domain pair | s= and d= from that signature | That the key is available now or was available earlier. |
| DNS publication | Observed TXT/CNAME route and provider expectation | That the source is actively signing with this key. |
| Receiver verification | Trusted result for the matching signature | That the message reached the inbox or was honest. |
| Domain alignment | Signing domain compared with visible From under DMARC rules | That all other business sources are ready for enforcement. |
Compare actual signing and the trusted verification result
Confirm that the source is configured to sign for the intended domain, not only that its DNS record exists. Then inspect the receiving environment's trusted Authentication-Results and match the reported result to the relevant signature. An authentication field inserted elsewhere in a message is not automatically trustworthy evidence.
If verification fails, investigate the reported reason, the key and signature relationship and any changes along the route. A successful DNS lookup alone does not explain a failed signature. If a signature passes for a provider's own domain, check alignment separately before treating it as the business-domain result needed for DMARC.
Handle corrections and rotation as a controlled change
Identify the change owner and the provider-supported sequence for publication, signing activation or rotation. Preserve the original DNS values and decide how an unsuccessful change will be reversed. Consider in-transit or delayed messages and the provider's instructions before retiring an old selector. There is no universal wait time that fits every mail route and rotation process.
After the change, create a fresh controlled message from the affected source and repeat the selector/domain, DNS, receiver-result and alignment checks. If there are several independent platforms, verify each relevant one. A clean result on the new test is useful evidence for that route; keep any remaining source or historical uncertainty explicit.
Hand over a result that the next owner can repeat
Record the source, message time, observed selector/domain, DNS arrangement, trusted result and alignment decision. Separate a current passing test from a claim about all historical mail. Document who owns the provider setting and DNS so a later migration or key rotation does not leave the route unmanaged.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with business-email and digital-infrastructure work. Our Israeli technical knowledge connects message evidence to provider configuration and a practical handover. Share the sending platform and symptom first so we can agree the scope without collecting passwords or private signing material.
