How DKIM works
DKIM, specified in RFC 6376, works like this: the sending server generates a hash of specified parts of the email (headers and body), encrypts that hash with a private key, and attaches it as a DKIM-Signature header. The receiving server looks up the corresponding public key at a DNS TXT record (selector._domainkey.yourdomain.com), decrypts the signature, and compares it against its own hash of the received message. A match confirms the message wasn’t tampered with and was signed by someone holding the private key for that domain.
What a DKIM selector is
The “selector” is an arbitrary label (commonly something like google, s1, or a provider-specific string) that lets a domain publish multiple DKIM public keys simultaneously — one per sending service — at different DNS record names. This is why DKIM setup instructions always ask you to add a record at a specific selector subdomain rather than a single fixed location like SPF.
DKIM vs SPF: what each actually proves
SPF proves “this IP is allowed to send for this domain.” DKIM proves “this specific message wasn’t altered and was signed by this domain’s key.” They check different things and commonly fail independently — a message can pass SPF and fail DKIM (e.g., forwarded mail that preserves the envelope sender but breaks the signature) or vice versa, which is exactly why DMARC exists to combine both into one policy decision.
Common DKIM misconfigurations
Line-wrapping or whitespace changes introduced by some ESPs or forwarding services can break a DKIM signature even though the “meaningful” content is unchanged, since the hash is computed over the raw bytes (unless relaxed canonicalization is used). Publishing a public key with a typo, or forgetting to rotate a selector after switching email providers, are the two most common real-world DKIM failures.