What Is DKIM and How Email Signing Works
A practical guide to DKIM: how cryptographic email signing works, how to publish the DNS record, and how to verify and fix it.
By the DNSLab team Updated July 9, 2026
Quick answer
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing email headers so receivers can verify the message truly came from your domain and was not altered in transit. Your mail server signs each message with a private key, and receiving servers fetch the matching public key from a DNS TXT record at selector._domainkey.yourdomain.com to check the signature.
What DKIM actually is
DKIM (DomainKeys Identified Mail) is an email authentication method that lets a receiving server confirm that a message really came from your domain and was not altered in transit. Your outgoing mail server adds a cryptographic signature to each message header. That signature is generated with a private key you keep secret, while the matching public key is published in your DNS as a TXT record. When a mailbox provider like Gmail or Outlook receives the message, it fetches your public key from DNS and checks the signature. If the math verifies, DKIM passes; if the message was tampered with or the key does not match, it fails.
Why DKIM matters for deliverability
Without authentication, anyone can forge your From address, and providers have no reliable way to tell your real mail from a spoof. DKIM gives receivers a verifiable claim of ownership, which improves inbox placement and protects your reputation. It is also one of the two pillars DMARC relies on: a message passes DMARC when either SPF or DKIM aligns with the visible From domain. Because DKIM survives forwarding better than SPF (the signature travels with the message), it is often the more durable of the two. Providers increasingly treat missing DKIM as a spam signal, so publishing it is close to mandatory for bulk senders.
How the signing process works step by step
When you send a message, the mail server selects the headers and body to protect, then computes a hash of them. It encrypts that hash with your private key and inserts a DKIM-Signature header containing the domain (d=), the selector (s=), the algorithm, and the signed hash (b=). The selector points to a specific public key, letting you run several keys at once. On the receiving side, the server reads the selector and domain, queries selector._domainkey.yourdomain.com for the public key, decrypts the signature, and recomputes the body hash. Matching hashes prove the content is intact and the sender holds the private key.
Publishing your DKIM DNS record
Your email provider or mail server generates the key pair and gives you the public key plus a selector name such as google, s1, or k1. You publish it as a TXT record at selector._domainkey.yourdomain.com. The value starts with v=DKIM1; k=rsa; p= followed by the long base64 public key. For a selector named s1, the host is s1._domainkey. Use a 2048-bit RSA key where your provider supports it, since 1024-bit keys are considered weak. Many providers (Google Workspace, Microsoft 365, SendGrid, Mailgun) give you the exact record to paste. After publishing, allow time for DNS propagation before enabling signing.
Common DKIM mistakes
The most frequent error is a broken public key: DNS panels sometimes split the long value or add quotes, so the p= string gets truncated or corrupted. Another is a mismatched selector, where the signing server uses one selector but a different one is published. People also forget that each sending service (your website, CRM, newsletter tool) needs its own signature or a shared key, otherwise those streams fail DKIM. Rotating keys without updating DNS, leaving an old CNAME pointing nowhere, or publishing the private key by mistake are all common. Finally, a passing DKIM signature on the wrong domain will not satisfy DMARC unless it aligns with your From domain.
How to verify DKIM with dnslab tools
The fastest check is to send yourself a test message and view the raw headers: look for DKIM-Signature and an Authentication-Results line reading dkim=pass. To confirm the record itself is live, use the dnslab DKIM lookup with your selector and domain to fetch the published TXT value and confirm the public key is complete. Pair it with the SPF and DMARC tools so all three authentication layers agree, and the WHOIS tool to confirm you are editing the right domain. If mail is landing in spam, the Blacklist tool tells you whether an IP reputation problem is masking an otherwise valid DKIM setup.
Frequently asked questions
- Do I need DKIM if I already have SPF?
- Yes. SPF authorizes which servers may send for your domain, but it breaks on forwarding and does not protect message content. DKIM signs the message itself so tampering is detectable. Together they give DMARC two ways to pass, so running both is strongly recommended for reliable inbox delivery.
- What selector should I use for DKIM?
- The selector is just a label that names one key, so you can pick almost anything (s1, k1, mail, or a date). Your email provider usually assigns it for you. Using distinct selectors per service and per rotation lets you publish and retire keys independently without breaking active mail streams.
- How long does DKIM take to work after publishing?
- The TXT record must propagate through DNS first, which typically takes minutes to a few hours depending on your TTL. Do not enable signing until the public key resolves, or messages will fail verification. Use the dnslab DKIM lookup to confirm the record is visible before switching signing on.