DKIM (DomainKeys Identified Mail) signs every message you send with a private key, and publishes the matching public key in your DNS. When an inbox receives your mail, it verifies the signature against the public record—proving the message really came from your domain and wasn’t tampered with along the way.
Why this is a yes
- The big providers require it. Google, Yahoo, and Microsoft’s bulk sender requirements demand DKIM alongside SPF and DMARC. For everyone else it’s still the baseline of looking legitimate.
- It’s the DMARC workhorse. DMARC passes when SPF or DKIM passes and aligns with the From domain. SPF breaks when mail is forwarded; a DKIM signature survives the trip. If only one of the two holds up in the real world, it’s DKIM.
- Spoofing protection scales with your brand. The more recognizable your domain gets, the more attractive it becomes to impersonate. A signature only you can produce is the counter.
How it works in practice
- You publish a public key in DNS (usually CNAME or TXT records your ESP hands you).
- Every outbound message gets a
DKIM-Signatureheader generated with the private key. - Receivers look up the public key and check the pair.
Having multiple DKIM records is normal—typically one or more per sending provider, each under its own selector. They don’t conflict the way SPF records do.
The gotchas
- Key length: 1024-bit is the right choice for transactional and marketing mail—see do I need 2048-bit DKIM? (spoiler: no).
- Verify after setup. A broken record—DNS typo, truncated value, wrong selector—means failed signatures, and under an enforcing DMARC policy, failed signatures mean blocked mail.
- Don’t sign and forget. If a private key is ever exposed, rotate it. Your ESP should make that boring.
If you send through an ESP like Resend, DKIM comes with domain verification out of the box. Confirm the records resolve, then move on to DMARC.