DKIM

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send. Receivers verify the signature against a public key you publish in DNS. If the message was altered or forged, the signature breaks. SPF authorises who can send; DKIM proves what was sent. Specified in RFC 6376, with crypto parameters updated by RFC 8301.

How it works

Two halves of the same handshake: the sender signs every outgoing message, the receiver verifies the signature against a public key in DNS. If the hashes match, the message is authentic and unmodified.

Sender signs
  1. 01hash selected headers (From, To, Subject, Date) + body
  2. 02sign the hash with your private key
  3. 03attach the signature as a DKIM-Signature header
Receiver verifiesauthentic
  1. 01read DKIM-Signature: pull s= (selector) and d= (domain)
  2. 02query DNS: <selector>._domainkey.<domain> TXT
  3. 03re-hash the message, verify against the public key
  4. 04match ⇒ message authentic. mismatch ⇒ rejected.

Where the public key lives

As a TXT record at a specific DNS path:

<selector>._domainkey.yourdomain.com

Three parts:

  • Selector: a 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 exactly this string.
  • Your domain: the root domain being signed.

A typical 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 provider.

Anatomy of a signature

The DKIM-Signature header travels with every signed message. Each tag plays a specific role.

DKIM-Signature headerRFC 6376 §3.5
DKIM-Signature:v=1;a=rsa-sha256;c=relaxed/relaxed;d=yourdomain.com;s=google;h=from:to:subject:date;bh=47DEQpj8...;b=dzdVyOfA...;
version

always 1. The only version defined.

algorithm

signing algorithm. rsa-sha1 is prohibited by RFC 8301; rsa-sha256 and ed25519-sha256 are valid.

canonicalization

how whitespace is normalised before hashing. Relaxed is forgiving; simple is strict.

domain

signing domain. Must align with the From: for DMARC to pass.

selector

points the receiver at <selector>._domainkey.<domain> for the public key.

signed headers

which headers are covered. Any change to these in transit breaks the signature.

body hash

hash of the message body. Detects body tampering.

signature

the RSA or Ed25519 signature itself. Base64 encoded.

Detection

DKIM has no directory. An external scanner cannot list every selector a domain uses. Sudory probes the sixteen most common selector names in parallel. One match means DKIM is live.

Sudory marks DKIM pass when any probed selector returns a v=DKIM1 record. If nothing matches, Sudory marks warn rather than fail. Missing from our probe list does not prove missing overall; your provider may use a custom name.

Setting it up

Every mainstream provider has a one-click DKIM flow. Same pattern everywhere.

ProviderWhereSelector
Google WorkspaceAdmin console → Apps → Gmail → Authenticate emails=google
Microsoft 365Defender portal → Email & collaboration → Email authentication settings → DKIMs=selector1 and s=selector2
PostmarkSender signatures → Add domain → DKIM tabTimestamped, ends in pm (e.g. s=20240101pm)
SendGridSender Authentication → Domain Authentications=s1, s=s2 (rotated)
MailgunSending → Domain settings → DNS recordss=pdk1, s=pdk2

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

Common mistakes

  • Keys rotated, DNS not updated. Providers rotate keys on a schedule. If your DNS still points to an old selector, signatures stop verifying.
  • Weak crypto. RFC 8301 bans rsa-sha1: receivers MUST NOT treat those signatures as valid. RSA keys must be 1024 bits or more; 2048 is recommended. Modern providers default to rsa-sha256 and 2048-bit keys. Older on-premises appliances still produce rsa-sha1; those fail today.
  • Only some traffic signed. Each sending service needs its own selector. Postmark, Mailchimp, and SendGrid all run separate key pairs.
  • TXT record split badly. Base64 keys exceed the 255-character TXT limit. DNS allows concatenating quoted chunks, but some providers do not expose the option.

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

Aleksej Dix
Aleksej DixFounder of Sudory

Founder of Sudory. Frontend engineer based in Zurich with 20+ years shipping production web apps; now building continuous compliance scanning and writing about the DNS and email-auth controls behind it. Co-founder of WebZurich.