What the signature associates with the message
A sending system uses a private key to create the signature. Verification uses the corresponding public key and the signed parts of the message. The signing domain can belong to the business, a service provider or another authorized signer; it is a distinct identity from the human name shown to the recipient.
A meaningful explanation names the signer and the covered-message result rather than calling the entire message safe. A compromised legitimate account or an authorized application can send signed mail. The technical signature therefore does not replace account investigation or independent verification of a sensitive business request.
What the selector and DNS key do
The DKIM-Signature field identifies a signing domain through d= and a selector through s=. These values identify the DNS location used to obtain the verification key. A selector is a key identifier within that domain's configuration; it is not a password or a score and should not be guessed from a different provider's example.
Providers can use different publication arrangements, including delegated CNAME records and TXT key records. The DNS record, active signing setting and actual received-message result are three separate checks. A public key being visible does not prove that a particular application is signing its outgoing mail or using the key you inspected.
Separate a verified signature from broader conclusions
A passing result supports the verification claim for the identified signature and covered content. It does not state that every header or every future message from the domain was checked. Some messages contain multiple signatures, so identify which domain and selector supplied each result.
Read the result recorded by the trusted receiving system. An arbitrary Authentication-Results field carried inside a message is not automatically authoritative. For troubleshooting, keep a redacted received-message example, the relevant identities and the observation time, with private content stored only through an appropriate authorized process.
| Evidence | What it supports | What remains separate |
|---|---|---|
| Public key in DNS | The queried location published a key at the observation time. | Whether the sending source used it. |
| DKIM pass for a signing domain | The receiver verified that signature under the applied rules. | Sender honesty, account security and inbox placement. |
| Pass for a provider domain | A provider-domain signature verified. | Alignment with the visible business From domain. |
| DKIM failure | The observed signature did not verify as expected. | The exact cause and whether other signatures passed. |
| New key published | A rotation preparation step is visible. | That signing switched successfully and old traffic is accounted for. |
Why forwarding, changes and rotation need context
A signature can survive a forwarding route when the relevant signed content remains compatible with verification. Changes to signed material can affect the result. The route, signing rules and actual modifications matter; a blanket claim that forwarding always preserves or always breaks DKIM is not useful.
Key rotation also needs coordination. The sending service and published key must correspond, and delayed or in-transit messages can matter when retiring an old selector. Follow the provider's supported sequence and verify actual messages before removing an earlier key. Do not paste a private signing key into DNS or a support enquiry.
How DKIM fits with SPF and DMARC
SPF evaluates an SMTP sending identity and route; DKIM verifies a domain-associated signature. DMARC checks alignment between an authenticated identity and the visible From domain. A passing aligned DKIM result can satisfy DMARC even if SPF is not the passing aligned route.
Alignment and delivery remain different questions. A legitimate signed message can be filtered, and a signed fraudulent payment request can come from an abused authorized account. Record which signature passed, whether its domain aligned and what the receiving environment actually did. These observations support different business decisions.
Use the definition to agree evidence and ownership
Ask which business systems sign mail, who owns their keys and DNS, how the provider rotates selectors and which controlled message demonstrates the intended result. Keep third-party platforms such as invoicing and website notifications in the inventory. A successful staff-mail example does not validate every other source.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with email and digital-infrastructure services. Our Israeli technical knowledge supports provider-specific checks and clear handover. This definition explains the mechanism; the selector guide supplies a diagnostic workflow and the authentication service separately defines implementation work.