DKIM explained: cryptographic proof that your email is really yours
Where SPF asks "is this server allowed to send?", DKIM asks a better question: "was this exact message really produced by the domain it claims, and has it been tampered with since?" It answers with public-key cryptography, and it survives forwarding — which SPF does not. Here is how it works and how to run it well.
How a DKIM signature works
When your mail server or email provider sends a message, it computes two hashes: one over the message body and one over a chosen set of headers (From, Subject, Date and others). It signs the result with a private key only it holds, and attaches the outcome as a DKIM-Signature header. That header names the signing domain (d=), a selector (s=), the algorithm, and the list of headers covered.
The receiving server takes the selector and domain from the signature and fetches a TXT record from <selector>._domainkey.<domain> — that record contains the public key. It recomputes both hashes and verifies the signature. If everything matches, the receiver has cryptographic proof of two things: the message was authorized by the DNS owner of that domain, and the signed content was not modified in transit.
Crucially, this proof travels with the message. A forwarded email keeps its DKIM signature intact (as long as the forwarder does not rewrite the content), which is why DKIM passes where SPF fails — the forwarding server's IP is not in your SPF record, but the signature still verifies.
Selectors: why there can be many keys
The selector exists so a domain can publish multiple keys at once. Google Workspace signs with selector "google", Microsoft 365 with "selector1"/"selector2", Mailchimp with "k1" — each service you authorize gets its own key under its own selector, and none of them needs access to the others' private keys.
This is also why "checking DKIM" from the outside is not straightforward: there is no way to list a domain's selectors via DNS. Tools like our DKIM Inspector probe the selectors that major providers are known to use. If your provider uses a custom selector, you have to know its name — you'll find it in the DKIM-Signature header of any message you've sent (the s= tag).
Key strength and the t=y trap
DKIM keys are almost always RSA, and length matters. Keys under 1024 bits can be factored at modest cost — in 2012 a mathematician famously demonstrated forging mail from Google by factoring their then-512-bit key over a weekend — and modern receivers reject such signatures outright. 1024-bit keys are still accepted; 2048-bit is the standard you should be on. Some providers now offer Ed25519 as a second signature, which is compact and strong, but publish it alongside RSA since not all receivers verify it yet.
Two flags in the DNS record deserve attention. An empty p= value means the key is revoked — fine if intentional, a silent failure if not. And t=y marks the key as "in test mode", telling receivers to treat signature failures as if the message were unsigned. It exists for safe rollouts, but it is routinely forgotten after setup, quietly downgrading your DKIM to decoration. Remove it once signing is verified.
What DKIM does not protect
A valid DKIM signature proves the signing domain authorized the message — but nothing forces the signing domain to match the From address the recipient sees. Spammers sign their mail perfectly well with their own domains. The missing link is alignment: DMARC requires the d= domain of a valid signature (or the SPF domain) to match the visible From domain. DKIM provides the cryptography; DMARC provides the policy that makes it meaningful to humans.
DKIM also breaks in one common legitimate scenario: mailing lists and some gateways that modify the message — adding a footer, rewriting the subject with a list tag — invalidate the body or header hash. This is expected, and it is one reason DMARC lets a message pass on either SPF or DKIM alignment rather than requiring both.
Running DKIM well
Enable DKIM at every service that sends as your domain — the main mailbox provider and every newsletter, CRM and transactional tool. Use 2048-bit keys. Rotate keys periodically (annually is a reasonable cadence for most businesses): publish the new key under a new selector, switch signing, and only then revoke the old one. And monitor your published keys — a deleted DNS record or an expired provider integration fails silently, and you will learn about it from deliverability graphs unless something is watching. MonitorBase checks your selectors on every audit and alerts when a key disappears, weakens or enters test mode.