DKIM

What is DKIM?

DKIM (DomainKeys Identified Mail) is an email authentication standard that attaches a digital signature to the email header when it leaves the sending server. The signature is created using a private key held by the sending server. The receiving server retrieves the corresponding public key from the sender's DNS records and verifies the signature — confirming both that the email came from the claimed domain and that the message content was not modified in transit.

DKIM was defined in RFC 6376 (2011) and has been a standard authentication requirement for enterprise email since the mid-2010s. It solves a limitation of SPF: SPF validates the sending server's IP address but doesn't validate the message content. DKIM validates both origin and integrity — a DKIM-signed email that was intercepted and modified would fail DKIM verification.

For sales teams, DKIM is backend infrastructure. The rep doesn't configure it (the IT team or domain admin does), but its presence or absence directly affects whether outreach lands in inbox. A domain without DKIM configured is treated with more suspicion by every major inbox provider — and from February 2024, Google and Yahoo require DKIM for senders above 5,000 messages/day.

How DKIM works

1. The sending company generates a DKIM key pair: a private key (stored on the sending mail server) and a public key (published in DNS as a TXT record at a specific selector subdomain, e.g., 'google._domainkey.gangly.com').

2. When the mail server sends an email, it creates a hash of selected email headers and the message body, then encrypts that hash with the private key to create the DKIM signature. The signature is added as an email header.

3. The receiving server reads the DKIM-Signature header, retrieves the public key from the sender's DNS, and decrypts the signature. If the decrypted hash matches a fresh hash of the received email content, DKIM PASSES — the email came from the claimed domain and wasn't modified. If they don't match, DKIM FAILS.

Setting up DKIM

Most business email providers (Google Workspace, Microsoft 365) handle DKIM automatically once configured in their admin console. The setup: generate the DKIM key pair in the email provider's admin settings → copy the generated TXT record → add it to the domain's DNS settings → verify it's active and passing.

For sending tools beyond the primary inbox (SendGrid, Mailgun, HubSpot, Outreach), each service provides its own DKIM TXT record that must be added to DNS. Multiple services mean multiple DKIM records — each service gets its own selector subdomain, so there's no conflict.

Verify DKIM is configured and passing with MXToolbox.com DKIM Checker or by sending a test email and reading the email headers. A passing DKIM shows 'DKIM: PASS' in the authentication-results header.

DKIM, SPF, and DMARC: the full authentication stack

DKIM addresses a different problem than SPF. SPF validates the server IP. DKIM validates message integrity and origin. DMARC ties them together — it defines policy for what to do when either check fails, and requires that one of SPF or DKIM aligns with the header-from domain. All three are required for comprehensive authentication and for Google/Yahoo 2024 bulk sender compliance.

A domain with only SPF and no DKIM is missing message integrity validation — a spoofed email can still pass SPF if sent through an authorized server. A domain with DKIM but no DMARC has no enforcement policy — even failed DKIM checks may still deliver the email. The full stack: SPF + DKIM + DMARC = complete authentication.

See SPF → and DMARC →

Frequently asked questions