DKIM

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send. Receivers verify the signature using a public key published in your DNS. If the message was altered in transit or forged by someone else, the signature breaks. SPF authorises who can send; DKIM proves what was sent. The protocol is specified in RFC 6376, with cryptographic parameters updated by RFC 8301.

How it works

When your mail provider sends a message, it:

1. Hashes selected headers (From, To, Subject, Date) plus the body.
2. Signs the hash with a private key.
3. Attaches the signature as a DKIM-Signature header.

When the receiver gets the message, it:

1. Reads the DKIM-Signature header, including the selector (s=) and domain (d=).
2. Queries your DNS at <selector>._domainkey.<domain> to fetch the public key.
3. Re-hashes the message and verifies the signature.

If the hash matches, the message is authentic and unmodified. If not, something has been tampered with, or someone forged the message and never had access to your private key.

Where the public key lives

The public key is published as a TXT record at a specific DNS path:

<selector>._domainkey.yourdomain.com

Three parts:

• Selector: any label your provider chooses. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailgun uses pdk1 and pdk2, Postmark uses timestamped selectors ending in pm. One domain can have many active selectors (one per service that signs your mail).
• _domainkey: required by the DKIM spec (RFC 6376 §3.6.2.1). Always this exact string.
• Your domain: whatever root domain the mail is being signed as.

A typical TXT record at that path:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

The p= value is the base64-encoded public key. The matching private key lives with your mail provider, guarded closely.

Anatomy of a signature

A real DKIM-Signature header in an outgoing message:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=google; h=from:to:subject:date;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbAv+yuU4zGeeruD00lszZ...

Full tag semantics are defined in RFC 6376 §3.5.

Detection

DKIM doesn't publish a directory. There's no way for an external scanner to enumerate every selector a domain has. Sudory probes the sixteen most common selector names in parallel. One match means DKIM is live.

Sudory marks DKIM as pass when any probed selector returns a v=DKIM1 record. If nothing matches, Sudory marks it as warn rather than fail, because the absence in our probe list doesn't prove absence overall. Your provider might use a custom name.

Setting it up

Every mainstream provider has a one-click DKIM flow. The pattern is the same everywhere:

The provider generates a key pair, gives you the public key, you publish the TXT record, they verify and flip signing on.

Common mistakes

• Expired keys not republished. Providers rotate keys on a schedule. If your DNS still points to an old selector, signatures stop verifying.
• Weak crypto. RFC 8301 prohibits rsa-sha1 outright (receivers MUST NOT treat those signatures as valid) and requires RSA keys of at least 1024 bits, with 2048+ recommended. Modern providers default to rsa-sha256 and 2048-bit keys. Older on-premises mail appliances sometimes still produce rsa-sha1 signatures; those fail verification today.
• Only signing some traffic. If you use Postmark, Mailchimp, and SendGrid, each needs its own selector published.
• TXT record split badly. Base64 keys exceed the 255-character TXT limit. DNS allows concatenating quoted chunks, but some providers won't let you.

Check which selectors respond on your domain: scan your domain. Sudory probes all sixteen and reports every match.