DKIM lets a domain take responsibility for a message through a cryptographic signature. To understand what that means for a specific email, start with the received original rather than a DNS checker. The useful evidence chain is message signature, signing domain and selector, public key, receiver verification result, then any DMARC alignment decision.
Read the identity that was signed
Locate each DKIM-Signature header in the original message. The d= value identifies the signing domain and s= identifies its selector. For DNS-based key retrieval, combine them as selector._domainkey.signing-domain. The signing domain may belong to the author's organisation, a relay or a service acting for it. DKIM deliberately separates signing responsibility from the apparent author. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
Illustrative example: From is accounts@example.com and a signature contains d=example.com; s=mail2026. The verifier looks up mail2026._domainkey.example.com. That DNS record supplies public verification material. The private signing key stays with the authorised signer and must not be published. This example explains the lookup; it is not a real signature or a tested message.
Separate presence from successful verification
A DKIM-Signature header can be present and invalid. A DNS key can exist while the application sends no signatures at all. Verification checks the signature structure, key, selected headers and body representation. Changes after signing may break it, depending on what changed and the canonicalisation used. A digest-looking string is not evidence that these checks passed. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
Inspect the receiving system's trusted Authentication-Results or equivalent logs. Understand which authentication service added that result and where untrusted inbound result headers are removed or ignored. A sender can insert plausible-looking pass text into a message, so arbitrary Authentication-Results content is not proof. RFC 8601 §1.2, RFC 8601 §7.1.
Connect the result to the visible author
For DMARC, compare a successfully verified d= domain with the Author Domain from From. Strict DKIM alignment requires an exact match under RFC 9989 §3.2.10; relaxed alignment uses the organisational-domain discovery in RFC 9989 §4.10.2. The selector and optional i= value are not the domains used for this DMARC comparison. If several DKIM signatures are present, one passing aligned signature can supply the DKIM path to DMARC pass. RFC 9989 §4.4.1.
In the example, d=example.com matches the From domain. If instead d=service.example.net verifies, raw DKIM passes but that unrelated domain does not establish alignment with example.com. Do not “fix” this by editing a received header: configure the legitimate signer to use an appropriate supported identity.
Build a useful investigation record
Record message time, route, From domain, each d/s pair, trusted DKIM result and reason, DNS observation time and alignment outcome. Protect the original message because it may contain personal or confidential information. Redacting a copy can invalidate its signature; retain an access-controlled original when re-verification is needed.
If verification fails, investigate whether signing was enabled, the correct key is available, the algorithm is supported and the message changed in transit. Current cryptographic guidance supersedes obsolete defaults: RFC 8301 §3.1 prohibits rsa-sha1 for signing and verification; RFC 8301 §3.2 updates RSA key guidance. Do not use an old tutorial's cryptographic choices merely because its syntax still looks valid. Finish with evidence of the received result, not just evidence that DNS contains a key.
Apply the distinction
For a hypothetical message, write one row for each signature: d, s, lookup owner, trusted verification result and alignment. If the example.com signature fails while an unrelated service.example.net signature passes, do not combine the first domain with the second result. Investigate the failed signature and evaluate SPF separately before assigning DMARC. No message verification was executed for this article.