DomainKeys Identified Mail (RFC 6376) — sign mail with your domain private key; receivers verify via the DNS public key. Generate an RSA key pair and a standard DKIM TXT record.
RFC 6376 §3.1: the selector identifies which public key to verify with, and multiple selectors can run in parallel (e.g. old and new coexisting during rotation). DNS hostname format: selector._domainkey.yourdomain.com.
RFC 6376 §3.3.3: use 2048 bits or higher. Some receivers (e.g. Gmail) already reject 1024-bit DKIM keys.
RFC 6376 §3.3: sha256 is required by the standard; sha1 is only for legacy compatibility.
DKIM (RFC 6376): the sender signs specific header fields and the body with the domain's private key, placing the signature in the DKIM-Signature header; receivers fetch the public key (TXT record) at selector._domainkey from DNS to verify. A valid signature proves the mail was sent by an authorized server for the domain and was not tampered with.
TXT record format: v=DKIM1; k=rsa; p=publicKeyBase64. k is the key type and p is the Base64-encoded public key (without PEM headers/footers). A single DNS TXT record is limited to 255 characters; longer values must be split (most DNS providers handle this automatically).
Private key setup: configure the private key (PEM) in your mail server signing module. Common locations: OpenDKIM (/etc/opendkim/keys/), Postfix (via milter), Exchange/commercial mail systems (import via admin console).
Key rotation: rotate every 6-12 months. When rotating, publish the new selector public key first, switch signing, confirm verification passes, then remove the old selector to avoid disruption.
Relation to DMARC: DKIM is one of DMARC's authentication pillars. DMARC alignment requires the d= domain to match the sender domain (or a subdomain). After generating, verify with our Email DNS One-Click Diagnostic.
Standards: RFC 6376 (DKIM), RFC 8301 (deprecation of weak key algorithms), RFC 7489 (DMARC).