DKIM

DKIM (DomainKeys Identified Mail) is an email authentication standard defined in RFC 6376. The sending mail system signs each outgoing message with a private cryptographic key; a header named DKIM-Signature carries the signature, the algorithm, and a pointer to the public key. The receiving server fetches the public key from DNS and verifies that the signature matches the message body and listed headers — proving both that the message originated from a server holding the private key, and that the signed portions of the message have not been altered in transit.

The public key lives at {selector}._domainkey.{domain} as a TXT record. Selectors are arbitrary identifiers — typically s1, s2, mail, or vendor-specific names like amazonses. Selectors enable key rotation: publish a new key under a fresh selector, switch the signer to the new selector, leave the old key in DNS until in-flight signed messages are flushed, then delete the old TXT record. Rotation is a basic hygiene practice — most ESPs rotate at least annually and on any suspected compromise.

For vendor-backed sending (Amazon SES, Mailgun, SendGrid, SparkPost — all built-in drivers under app/SendingServers/Drivers/Vendors/), DKIM is signed by the vendor. The operator's job is to publish the vendor-provided CNAME or TXT records on their sending domain. For the generic SMTP driver, DKIM signing is done by the upstream MTA (Postfix's opendkim milter, Postal's built-in signer, etc.) — AcelleMail does not sign DKIM itself.

The full setup walkthrough — what the records look like for the major vendors and how to verify signing — lives in the deliverability pillar guide.

SPF authenticates the IP address; DKIM authenticates the message itself. A forwarded email that breaks SPF (because it now comes from the forwarder's IPs) typically still passes DKIM (the signature covers the body, not the path). DMARC then aligns one or both signals against the visible From: header. All three layers compose — modern deliverability assumes you publish all three.