DKIM explained: how email signatures prove your mail is genuine

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send. Receiving servers verify that signature against a public key in your DNS — proving the message really came from your domain and wasn't altered in transit.

What is DKIM, in one paragraph?

When you send an email, your mail server signs parts of the message (headers and body) with a private key and adds the signature to a DKIM-Signature header. The receiving server looks up your public key in DNS, checks the signature, and knows two things: the email genuinely came from your domain, and nobody tampered with it along the way. No signature or a broken one? That's a red flag for spam filters.

How does DKIM work, step by step?

1. Signing: Your sending server (Google Workspace, Instantly, your SMTP provider) hashes selected headers and the body, encrypts the hash with your private key, and adds a DKIM-Signature header to the outgoing email.
2. Lookup: The receiving server reads the d= (domain) and s= (selector) values from that header.
3. Verification: It queries DNS for the public key at <selector>._domainkey.<domain> — for example, google._domainkey.example.com.
4. Result: If the signature decrypts correctly with the public key, DKIM passes. If anything in the signed content was changed in transit, verification fails.

What is a DKIM selector?

The selector is a label that lets you publish multiple DKIM keys for one domain — one per sending service. Google Workspace might use selector google, while your cold email tool uses instantly or similar. Each selector has its own DNS record and its own key pair, so you can rotate or revoke one service's key without touching the others. Rotating selectors periodically is good hygiene — if a private key ever leaks, you replace just that selector.

Where does the DKIM record live?

It's a TXT record at <selector>._domainkey.yourdomain.com. A typical value looks like this:

The p= value is your public key (a long base64 string). You don't write this by hand — your sending provider generates the key pair and gives you the exact DNS record to publish.

How do I check if DKIM is set up?

• DNS check: Query <selector>._domainkey.yourdomain.com for a TXT record. No record, no DKIM.
• Send a test email to Gmail and open "Show original" — look for dkim=pass in the Authentication-Results header.
• Use the free DKIM check in the OutboundAuth toolkit — enter your domain and selector and it validates the record for you.

Common DKIM mistakes

• Publishing the key but never enabling signing. The DNS record alone does nothing — your sending service must actually sign outgoing mail. Check the provider's admin panel.
• Wrong selector. The selector in the email's DKIM-Signature header must match the DNS record you published. A typo means receivers can't find your key.
• Broken key formatting. Copy-paste errors — missing characters, extra spaces or line breaks — silently invalidate the record.
• Forgetting a sending service. Every tool that sends as your domain needs its own selector and signing enabled: your Workspace, your cold email platform, your invoicing app.
• Key too short. Use 2048-bit keys. Some DNS providers mangle long TXT records — if yours does, check whether it supports splitting the value across multiple quoted strings.

DKIM, SPF and DMARC together

DKIM is one leg of the trio: SPF authorizes which servers may send for you, DKIM proves the message is authentic and unaltered, and DMARC ties them together with a policy for failures. You need all three for reliable inbox placement — read the SPF guide and the DMARC rollout guide to complete the picture.