DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending server add a cryptographic signature to each message's headers. The matching public key is published in DNS under a selector name, and the receiver uses it to confirm the signed parts were not changed in transit and that the signing domain authorized the message.
Why it matters
Unlike SPF, a DKIM signature survives forwarding, since it travels with the message. DKIM also supplies the signing domain that DMARC can align with the visible From address. Large mailbox providers expect it, and each email service you use usually needs its own selector.
Example
DNS record at selector1._domainkey.example.com:
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."The header on a sent message:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...d= is the signing domain and s= the selector, which tells the receiver where to find the key.
Common mistakes
- Publishing the key under the wrong selector name or domain.
- Breaking a long 2048-bit key by pasting it with line breaks or exceeding the 255-character string limit without splitting.
- Leaving DKIM disabled at the sending provider after adding the DNS record.
- Never rotating keys, or deleting an old selector while mail signed with it is still in flight.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.