What Is DKIM and How Does It Work?

What DKIM means

DKIM, short for DomainKeys Identified Mail, is an email authentication method that lets a receiving mail server verify that a message carries a valid signature from a domain.

In plain English, DKIM is a cryptographic responsibility check. Your mail system signs selected message headers and a hash of the body with a private key. Gmail, Outlook, Yahoo, and other receivers look up the matching public key in DNS, verify the signature, and use that result as one signal when deciding how to handle the message.

DKIM does not prove that the visible From address is honest, that the human sender is legitimate, or that the message is wanted. It proves that the message was signed by a system with access to the private key for the domain in the DKIM signature, and that the signed parts still match after normal DKIM canonicalization. That is why DKIM needs SPF and DMARC beside it.

How DKIM works

DKIM works by pairing a private signing key in your email platform with a public key published in your DNS.

• Your provider creates a DKIM key pair. The private key stays with the sender, such as Google Workspace, Microsoft 365, Postmark, Mailchimp, or your own mail server.
• You publish the public key as a DNS TXT record under a selector, usually in the form selector1._domainkey.example.com.
• When a message is sent, the sender adds a DKIM-Signature header. That header includes the signing domain in d=, the selector in s=, the signed header list in h=, a body hash in bh=, and the signature in b=.
• The receiver uses the selector and signing domain to find the DNS key, verifies the signature, and checks whether the signed headers and body hash still match.

The selector matters because one domain can use more than one DKIM key. That lets you rotate keys, use different providers, or separate product mail from marketing mail without replacing every sender at once. The technical standard is RFC 6376, with later updates for algorithms and operational details.

Where SPF and DMARC fit

DKIM is strongest when SPF and DMARC are also correct, because modern receivers look at the whole authentication picture.

SPF is the DNS TXT record that lists which servers are allowed to send mail for a domain in the SMTP envelope, often called the MAIL FROM or Return-Path domain. A normal SPF record starts with v=spf1, includes approved senders, and commonly ends in ~all for soft fail or -all for hard fail. Use only one SPF record at the same DNS name. SPF also has a hard 10 DNS-lookup limit for mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect. Stacked tools can break SPF even when the record looks reasonable. The SPF standard is RFC 7208.

DMARC connects SPF and DKIM to the visible From domain. A message passes DMARC if either SPF passes and aligns with the From domain, or DKIM passes and aligns with the From domain. The policy can be p=none for monitoring, p=quarantine to ask receivers to treat failures as suspicious, or p=reject to ask them to reject failures. Receivers still apply their own local filtering rules, so DMARC is not the only delivery decision. Add a rua=mailto: address if you want aggregate reports about mail that appears to use your domain. The DMARC standard is RFC 7489.

Why DKIM affects deliverability

Gmail and Outlook do not send mail to spam because of one DNS record alone, but weak authentication is a common reason legitimate mail gets filtered or distrusted.

Mailbox providers combine authentication, sender reputation, complaint rates, sending patterns, message content, infrastructure signals, and local policy. DKIM helps because it gives them a stable domain signal. If your DKIM signature is missing, broken, or signed by a domain that does not align with DMARC, the receiver has less evidence that the message belongs to the visible sender.

Google's email sender guidelines tell senders to turn on DKIM, publish DMARC, and use SPF or DKIM authentication with domain alignment for DMARC. Microsoft explains in its email authentication guidance that SPF, DKIM, and DMARC work together to validate sender identity and reduce spoofing. For current provider-specific requirements, use those official pages instead of copying old checklist numbers from blog posts.

MX records still matter because they tell the internet where your domain receives mail. They do not authenticate outbound messages, but broken MX can stop replies and make a domain look neglected. Blocklists also matter, especially after compromised accounts, bad lists, or sudden volume spikes. Still, authentication is usually the fastest fix and the easiest one to verify.

How to check your DKIM setup

The fastest way to debug DKIM is to check live DNS records and a real sent message, not a copied note from your email provider.

• Find every service that sends as your domain, including newsletters, invoicing, support desks, CRM tools, and product email.
• Confirm each sender has DKIM enabled and that its selector record exists in DNS.
• Send a test message to Gmail or Outlook and inspect the authentication results. DKIM should pass for the sending domain.
• Check that either DKIM or SPF passes and aligns with the visible From domain so DMARC can pass.
• Review SPF for duplicate records, missing senders, unsafe +all, and the 10-lookup limit.
• Start DMARC at p=none with aggregate reports, then move toward quarantine or reject after all legitimate senders pass and align.

You can see the same issues quickly with the free InboxRadar domain scorecard. It checks SPF, DKIM, DMARC, MX, and blocklist signals, grades the domain, and watches for drift so a DNS edit or provider change does not quietly break deliverability later.