What DKIM proves
DKIM (DomainKeys Identified Mail) lets a domain take responsibility for a message by adding a DKIM-Signature header. Receivers fetch the public key from DNS (selector._domainkey.example.com) and verify the signature over canonicalized header/body content—integrity for selected headers and the body hash, independent of the client IP path.
Mechanics
Signing uses the domain’s private key; DNS publishes the matching public key in a TXT record. Canonicalization rules (c= relaxed/simple) define how whitespace and line wraps are normalized before hashing. Multiple selectors support key rotation: publish a new key, dual-sign, retire the old selector after receivers cache TTLs expire.
Important header tags (RFC 6376)
Operators should recognize: d= signing domain, s= selector, a= algorithm (rsa-sha256 or ed25519), c= canonicalization, h= signed header field list, bh= body hash, b= signature data, t=/x= signature timestamps/expiry, and l= body length limits (dangerous if abused to skip tail content). Mis-signed or duplicated DKIM-Signature headers often indicate misconfigured multi-hop relays.
Receiver validation outline
Validators hash the canonical body, compare to bh=, then verify the asymmetric signature over the header hash input. DNSSEC on the signing zone strengthens trust in the published key; without DNSSEC, downgrade to forged TXT remains a residual risk mitigated by caching and monitoring.
Enterprise context
Marketing clouds, ticket systems, and internal relays must all sign with aligned selectors or you risk DMARC failures downstream. Key material belongs in HSM/KMS where policy requires; rotation should be automated with rollback.
False positives
Mailing lists and some forwarders mutate content, breaking body hashes while headers still pass—expect DKIM fails on modified newsletters even when mail is legitimate.
Read SPF, DMARC, and the combined SPF/DKIM/DMARC setup guide.
Document egress IPs your ESP uses when populating SPF.