A DKIM signature is the authenticated header added to an email by the sending domain’s mail system, allowing receivers to verify that the message was signed and not altered in transit. In practice, security teams check that the signature aligns with the sending domain, verifies against the published public key, and survives normal mail routing changes.
What a DKIM signature looks like in a real email
A dkim signature usually appears as a long DKIM-Signature header in the raw email source. It contains the signing domain, selector, canonicalization settings, signed header list, timestamp, and the cryptographic signature itself. A practical example is an outbound message from a company domain where the mail server signs the headers before delivery, and the recipient verifies the signature against the domain’s public key.
For a security reviewer, the important point is not the exact string length but the structure. The signature should identify which domain signed the message, which headers were protected, and which selector points to the public key published in DNS. That is what lets a receiving system confirm the message is associated with the expected sending domain rather than a lookalike or forged source.
What practitioners check when validating DKIM
In practice, validation is a three-part check: the signature must parse correctly, the receiving system must find the matching public key, and the computed hash must match the signed content after normal transport handling. If the signature breaks only because a mailing system rewrote headers or body content, the result may still be a legitimate delivery issue rather than a forgery.
That is why teams look at more than a simple pass or fail. They confirm whether the selector is current, whether the signing domain is expected, and whether the message changed in transit in a way that should have been covered by the signed header set. If the signature survives routing, mailing list handling, and forwarding behaviour, it is doing its job.
For a complete operational view of SPF, DKIM and DMARC together, see the DMARC, SPF and DKIM Guide. It helps place the signature in the wider sender-authentication chain rather than treating DKIM as a standalone check.
Why DKIM examples matter for spoofing and delivery trust
DKIM is valuable because it proves the message was signed by a domain that controls the private key at send time, not because it proves the sender is automatically trustworthy. A message can pass DKIM and still be unwanted, so practitioners treat it as one signal alongside alignment and policy enforcement. For this reason, Email Identity and BEC Guide is useful when you want to connect DKIM with impersonation risk and policy decisions.
A realistic example is a business email with a valid DKIM-Signature header from the expected domain, but the security team still checks whether the visible From address aligns and whether the message path matches the organisation’s approved sending infrastructure. That distinction matters because DKIM helps verify integrity and domain control, while policy layers decide whether the message should be trusted for user delivery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DKIM depends on the lifecycle of signing keys and selectors. |
| SC-12 — Cryptographic Key Establishment and Management | DKIM signatures rely on protected key generation, distribution, and storage. | |
| Recommendation — Manage DKIM keys and selectors with controlled rotation and revocation. Protect DKIM private keys with controlled generation, storage, and rotation. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | DKIM is a cryptographic control for message integrity and sender-domain assurance. |
| Recommendation — Define and operate DKIM cryptographic controls for outbound email integrity. | ||
Practitioner Guidance
What to verify: When you inspect a live message, review the raw header, not the mail client summary. Confirm the signing domain, selector, and signed header list before you rely on the result, because a valid-looking message can still fail alignment or come from an unexpected sender path.
Common mistake: Do not treat a DKIM pass as proof that the email is safe. It only says the message was signed by a domain that controlled the key and that the signed content still matches; it does not validate intent, sender legitimacy, or whether the content is socially engineered.
Practitioner takeaway: The most useful DKIM example is one that shows both integrity and limits, a valid signature helps prove message continuity, but you still need alignment and policy checks before you trust the mail.
Related resources from NHI Mgmt Group
- Where do digital signature certificate programmes fail in practice?
- How should organisations control access to Digital Signature Certificates in practice?
- How do digital signature certificates differ from a simple scanned signature in practice?
- How should healthcare organisations evaluate e-signature platforms for HIPAA use in practice?