DKIM (DomainKeys Identified Mail)

A cryptographic signature on outgoing email headers, verified against a public key in DNS. Proves the email actually came from someone authorized at the claimed sender domain.

DKIM (DomainKeys Identified Mail, RFC 6376) is the email-authentication piece where the sender signs the message and the receiver verifies the signature against a public key in DNS.

How it works

Your email server has a private key.
Before sending, it computes a cryptographic signature over the message headers and body and adds a DKIM-Signature: header.
The signature header references a public key by selector and domain: d=example.com; s=acme-2026.
Receivers fetch the public key from acme-2026._domainkey.example.com via DNS TXT.
If the signature verifies against that key, the message is authentic.

What's in DNS

A typical DKIM TXT record:

acme-2026._domainkey.example.com.   TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

v=DKIM1 — DKIM v1.
k=rsa — RSA key.
p=... — base64-encoded public key.

The selector (acme-2026) lets you rotate keys without breaking anything: publish a new selector, switch the signer to use it, leave the old one in DNS until existing mail clears the queue.

DKIM for SaaS sending from customer domains

If your SaaS sends email from customer-owned domains (hello@janesbakery.com), you need DKIM on each customer's domain. Two patterns:

Custom DKIM key per customer. You generate a key pair per domain, give the customer the TXT record to add. Most isolated.
Shared DKIM via d=yourapp.com. The signature claims authority from your domain, not theirs. Faster setup but less convincing to receivers.

ESPs like SendGrid and Postmark default to per-customer DKIM and have flows for the TXT record handoff.