Glossary
Definition
DKIM (DomainKeys Identified Mail)is a cryptographic signature added to an email’s header that lets the receiving server verify the message was authorized by the sending domain and was not altered in transit. The domain signs each message with a private key, and receivers check that signature against a public key published in DNS.
We verify billions of email addresses, and the health of a domain’s authentication is one of the first things we read on any sender. DKIM sits at the center of that picture. It is the mechanism that lets a receiving server trust that a message genuinely came from the domain it claims, and that not a single byte was changed along the way. Here is what DKIM actually is, how it works, how it fits alongside SPF and DMARC, and why it matters for whether your mail reaches the inbox at all.
DKIM is built on public-key cryptography, the same idea behind a website’s padlock. Your domain holds a private key that never leaves your sending infrastructure, and it publishes the matching public key openly in DNS. The private key signs; the public key verifies. Because only the holder of the private key can produce a signature the public key will accept, a valid signature is proof of origin.
When your server sends a message, it computes a hash of the body and a chosen set of headers, encrypts that hash with the private key, and stamps the result into a DKIM-Signature header on the email. That header also names the signing domain and a selector, which tells receivers exactly where to look for the key.
The public key lives in a DNS TXT record at a selector subdomain, for example selector1._domainkey.yourdomain.com. The record carries the version (v=DKIM1), the key type (usually k=rsa), and the public key itself in a long p= value. The selector matters because it lets one domain run several keys at once, so your marketing platform, your CRM, and your transactional provider can each sign with their own key without colliding.
On the receiving side, the server reads the DKIM-Signature header, extracts the domain and selector, and fetches the public key from your DNS. It recomputes the hash over the same headers and body, decrypts the signed hash with the public key, and compares the two. If they match, the message passes DKIM: it was authorized by the domain and arrived intact. If they differ, the signature fails, which is a strong signal the mail was forged or tampered with in transit.
DKIM is one of three standards that together make email trustworthy, and it is easy to confuse them. They solve different problems and are strongest together.
DMARC also adds alignment: it is not enough for DKIM to pass, the signing domain has to match the domain in the visible From address. That alignment is what stops a spoofer from signing with their own unrelated domain and claiming a pass. You want all three configured, and you can confirm them in one place with the DMARC, DKIM, and SPF check.
DKIM does two jobs that both bear directly on whether your mail lands. First, anti-spoofing: because a valid signature cannot be forged without your private key, DKIM makes it far harder for anyone to impersonate your domain in a phishing campaign. Combined with a DMARC reject policy, it lets receivers throw away mail that pretends to be you.
Second, reputation and inbox placement. Mailbox providers read a valid DKIM signature as a trust signal and weigh authenticated mail more favorably, so it is more likely to clear the spam filter. This stopped being optional in 2024: Gmail and Yahoo now require DKIM for bulk senders, and mail that arrives unsigned or with a broken signature can be throttled or rejected at the door. A missing selector or an expired key quietly tanks deliverability long before anyone notices.
This is where teams most often blur two separate questions. DKIM proves a domain is authorized to send and that its outbound messages are intact. It says nothing about whether a given mailbox on that domain can actually receive the message you are about to send. A domain can have flawless DKIM and still be full of dead addresses, full mailboxes, and role addresses that route nowhere useful.
Confirming the receiving side is exactly what our engine does. We read a domain end to end: its SMTP behavior, its mail exchangers, and whether each specific address resolves to a live, reachable mailbox. Authentication and verification are two halves of the same trust question, and you need both. A domain that authenticates but cannot receive wastes your sends; a deliverable address on a domain that fails authentication gets filtered before anyone reads it.
The practical workflow is to confirm authentication first, then verify the list. Use the authentication checker to confirm DKIM, SPF, and DMARC are published and aligned, run an MX lookupto see which servers actually handle the domain’s mail, and then run every address through email verification so you are sending authenticated mail to addresses that can genuinely receive it. For verifying at scale, the volume tiers are on the pricing page.
Keep learning
DKIM is one of several deliverability concepts worth understanding together. These are the terms most worth learning next.
A DNS record listing which servers are allowed to send mail for a domain.
The policy layer that ties SPF and DKIM together and tells receivers how to act on failures.
The protocol mail servers speak to hand a message from sender to recipient.
Confirming an address is real, reachable, and safe to send to before you send.
A permanent delivery failure, usually because the mailbox does not exist.
A shared inbox like info@ or support@ that belongs to a team, not a person.
Paste a domain and see whether its DKIM signature, SPF record, and DMARC policy are published and aligned, in seconds. No signup.
Common questions
The questions we get most about DKIM, answered with the same logic our verification engine uses to read a domain.
DKIM is a tamper-proof seal on your email. Your mail server adds an invisible cryptographic signature to the header of every message it sends, and the receiving server checks that seal before deciding whether to trust the mail.
If the signature matches, the receiver knows two things: the message really came from your domain, and nobody changed it on the way. If it does not match, that is a strong signal the mail is forged or was altered.
When your server sends a message, it hashes selected headers and the body, encrypts that hash with a private key, and writes the result into a DKIM-Signature header. The matching public key lives in a DNS TXT record at a named selector.
The receiving server reads the signature, fetches the public key from your DNS, and verifies the hash. If everything checks out, the message passes DKIM. You can inspect the published record on the DMARC, DKIM, and SPF check.
They are the three pillars of email authentication. SPF says which servers are allowed to send for your domain. DKIM cryptographically signs the message so it cannot be altered or forged. DMARC ties the two together and tells receivers what to do when a message fails.
You want all three. SPF and DKIM each prove a different thing, and DMARC turns those proofs into an enforceable policy plus reporting. Check all three at once on the authentication checker.
It is a DNS TXT record published at a selector subdomain, such as selector1._domainkey.yourdomain.com. The value holds the version tag v=DKIM1, the key type k=rsa, and the public key in a long p= string.
The selector lets one domain run several keys at once, so each sending platform can have its own. To see which selectors and servers a domain uses, pair the lookup with an MX lookup.
Yes, meaningfully. Mailbox providers treat a valid DKIM signature as a trust signal, so authenticated mail is more likely to reach the inbox and less likely to be filtered as spam. It is also a prerequisite for DMARC alignment.
Gmail and Yahoo now require DKIM for bulk senders, so missing or broken signatures can get mail rejected outright. Authentication is one half of deliverability; a clean, verified list is the other.
Not the signature itself. Forging a valid DKIM signature would require your private key, which never leaves your servers, so an attacker cannot fake a passing signature for your domain. That is the whole point of public-key cryptography.
The weak spots are operational: a leaked private key, a key left too short, or a selector that was never published. DMARC closes the remaining gap by rejecting unsigned or misaligned mail outright.
No, and the distinction matters. DKIM proves a domain is authorized to send and that its outbound mail is intact. It says nothing about whether a specific mailbox on that domain can actually receive what you send to it.
Confirming a mailbox is reachable is a separate job, and it is ours: we test the domain and the address end to end. Run any address through the free email checker to see whether it can truly receive.
Checking a single domain’s authentication records is free with our public tools. For verifying real mailboxes across a large list, the per-address economics and volume tiers are laid out on the pricing page.
Authentication and verification answer different questions, so we keep them separate: the record checker confirms a domain is set up to send, and the verification engine confirms each address can receive.