What a signature tells you
DKIM uses a cryptographic signature and a DNS-published public key to associate a signing domain with a message. The signature identifies a selector and domain and covers specified headers and body content. It does not certify the human author’s identity or make the contents safe. [IETF RFC 6376: DKIM]
Why the route matters
Changes to signed content can invalidate the signature. Check where a footer, subject or body change was introduced. A valid signature can also use a different domain from the visible From domain; see DMARC alignment. [IETF RFC 6376: DKIM]
How we approach it
- Capture signing details from actual messages from every application in scope.
- Identify who controls the key and DNS record, and who owns renewal or rotation.
- Test the final route, including security gateways, relays and forwarding.
- Agree key changes with the service owner, preserve required overlap and verify new messages after deployment.
A test from the employee mail platform does not stand in for a test from finance or CRM. Each sender belongs in the estate record. Our delivery framework makes that ownership explicit.
Primary sources
Provider requirements and product capabilities can change. Check the linked source before a production change.