What Is DKIM? How It Works (Plain-English Guide)

Email was designed in an era when everyone on the network was trusted, so the protocol that moves it has no built-in way to prove who actually sent a message. The "From" address you see is just text the sender typed — anyone can write anything there, the same way you can write any return address you like on a paper envelope. That gap is what makes spoofing, phishing, and forged sender addresses possible, and it is the problem a whole family of email authentication standards was invented to close. DKIM is one of the three load-bearing members of that family, alongside SPF and DMARC.

If you have ever opened a domain's DNS settings, used a marketing platform, or read a raw header and seen a long block beginning with `DKIM-Signature:`, you have brushed up against it. The term turns up in deliverability guides, in the fine print of every email provider, and in the headers of essentially every legitimate email you receive — and it is rarely explained in plain language. It tends to be presented as a checkbox you tick during setup, with no account of what it actually does or why it works.

This guide is the plain-English version. We will start with what DKIM is and what the letters stand for, then walk through how it works step by step — the private-key signing on the sending side, the public key published in DNS, and the verification the receiver performs. We will break down the `DKIM-Signature` header field by field in a real example, explain selectors and why a domain can have several keys at once, cover key length and rotation, and draw the careful line between what a valid DKIM signature actually proves and what it does not. Then we will place DKIM next to SPF and DMARC, including the alignment concept that makes the three work as a system, and finish with how to set it up and verify it. We close with a short, honest note on how an AI-native email client like AI Emaily relates to all of this.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication standard, defined in RFC 6376, that lets the organization responsible for a message attach a digital signature to it — and lets any receiving mail server check that signature to confirm two things: that the message was authorized by the domain that claims to have sent it, and that the parts of the message that were signed have not been changed in transit. It is, in short, a tamper-evident seal tied to a domain name.

The mechanism behind it is public-key cryptography, the same broad idea that secures websites over HTTPS. The sending domain holds a private key it keeps secret, and it publishes a matching public key openly in its DNS records. When the domain sends mail, its server uses the private key to compute a signature over the message's headers and body. The receiver, on the other end, looks up the public key in DNS and uses it to verify that signature. Because only the holder of the private key could have produced a signature the public key validates, a passing check is strong evidence the message genuinely came from that domain.

It helps to be precise about what "the domain" means here, because it is the heart of DKIM and the part most explanations blur. DKIM does not authenticate the human author of an email, and it does not directly authenticate the visible "From" address on its own. What it authenticates is a domain — specified inside the signature in a tag called `d=` — that takes responsibility for the message. That signing domain is often the same as the From domain (`d=example.com` for mail from `you@example.com`), but it need not be; a mailing list or an email platform may sign with its own domain. Tying the signing domain back to the visible From address is a separate job — exactly the job DMARC does. Hold on to that distinction; it explains a great deal of how the system fits together.

The name itself records a small piece of history. DKIM is the merger of two earlier efforts: Yahoo's DomainKeys and Cisco's Identified Internet Mail. The two were combined and standardized by the IETF, first published as RFC 4871 in 2007 and then revised into the current RFC 6376 in 2011. That lineage is why the name reads a little awkwardly — "DomainKeys Identified Mail" stitches both ancestors' names together — and why you will still occasionally see the older "DomainKeys" term floating around in legacy documentation.

Why does email need DKIM at all?

To see why DKIM exists, you have to understand the hole it fills. The protocol that actually transports email between servers — SMTP, the Simple Mail Transfer Protocol — was specified in 1982 for a small, trusting research network. It was built to move messages reliably, and it does that well. What it was never built to do is verify identity. There is nothing in plain SMTP that checks whether the server claiming to send mail for a domain is actually allowed to, and nothing that stops a sender from putting any address at all in the "From" header.

The result is that the sender of an email is, by default, self-asserted and unverifiable. The address you read at the top of a message is content the sender supplied, not a fact the system proved. An attacker who wants to impersonate your bank, your CEO, or a vendor can simply write that organization's address into the From field and send. The receiving server has historically had no native way to tell a genuine message apart from a forged one — both arrive looking identical, because the forged one is identical except for who really sent it.

That single weakness is the root of an enormous amount of email crime: phishing, business email compromise, and spoofed transactional mail that mimics a service you trust. Spam filters can guess at these using reputation and content heuristics, but guessing is not the same as a cryptographic check. What was missing was a way for a domain to make a verifiable claim — "this message is really from us" — that a receiver could test rather than trust.

Email authentication is the family of standards built to provide exactly that, and it has three members that work together. SPF (Sender Policy Framework) lets a domain publish, in DNS, the list of servers authorized to send mail for it, so a receiver can check whether the sending server is on the approved list. DKIM, the subject of this guide, adds the cryptographic signature that proves a message was authorized by a domain and not tampered with. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together, links them to the visible From address, and tells receivers what to do when a message fails. DKIM is the integrity-and-authorization layer of that stack — the piece that signs the actual message rather than merely vouching for the server that sent it.

How does DKIM work, step by step?

DKIM has two halves: a signing process that happens on the sending side, and a verification process that happens on the receiving side. The two are linked by a key pair — a private key the sender keeps and a public key the sender publishes in DNS. Walking through both halves in order is the clearest way to see why the whole thing holds together.

On the sending side, when an outbound mail server (operated by your domain, your email provider, or your sending platform) is about to send a message, it builds a DKIM signature. First it decides which parts to sign: a chosen set of header fields — almost always including `From`, and typically `Subject`, `Date`, `To` — and the message body. It runs those signed parts through a hashing algorithm to produce a compact fingerprint, then encrypts that fingerprint with the domain's private key. The encrypted result, together with details about exactly what was signed and how, is packed into a new `DKIM-Signature` header and added to the top of the message, riding along in its headers all the way to the recipient.

On the receiving side, when a mail server accepts an incoming message, it reads two tags from the `DKIM-Signature` header: `d=`, the signing domain, and `s=`, the selector. It combines these into a specific DNS location and queries it for the domain's published public key. With the public key in hand, the receiver recomputes the hash over the same headers and body the signature says were signed, then checks that this freshly computed hash matches the one the sender encrypted with its private key. If the two match, the signature is valid: the message was signed by something holding that domain's private key, and the signed content arrived unchanged. If they do not match — because the key is wrong, or the signed content was altered en route — verification fails.

The asymmetry of the key pair is what gives this its force. The private key can produce signatures that the public key can verify, but the public key cannot be run backward to forge a signature. So publishing the public key openly in DNS for the whole world to read costs the domain nothing in security — anyone can verify, but only the holder of the secret private key can sign. That is precisely why a forged email fails: an attacker can copy your From address all day, but without your private key they cannot produce a `DKIM-Signature` that your published public key will accept. The steps below lay the whole sequence out in order.

1. 1

   Generate a key pair

   The domain owner (or their email provider) creates a public/private cryptographic key pair. The private key is stored securely on the signing server; the public key is destined for DNS.

2. 2

   Publish the public key in DNS

   The public key is published as a TXT record at a specific subdomain that encodes the selector, e.g. selector1._domainkey.example.com. Receivers will read it from there.

3. 3

   Sign the outgoing message

   When sending, the server hashes the chosen headers plus the body, encrypts that hash with the private key, and adds the result as a DKIM-Signature header on the message.

4. 4

   The message travels with its signature

   The DKIM-Signature header rides along in the message headers through every hop to the recipient's mail server. No central authority is involved.

5. 5

   The receiver fetches the public key

   The receiving server reads the d= (domain) and s= (selector) tags from the signature, builds the DNS location, and queries DNS for the published public key.

6. 6

   The receiver verifies the signature

   It recomputes the hash over the same signed parts and checks it against the decrypted signature using the public key. A match means pass; any mismatch means fail.

What is the DKIM-Signature header?

The `DKIM-Signature` header is where everything DKIM does is recorded. It is a single header field added to the top of a signed message, and it carries both the signature itself and a set of tags telling the receiver exactly what was signed and how to verify it. Because all the verification instructions travel inside the message, no separate lookup is needed beyond fetching the public key — the header is self-describing.

It is written as a series of `tag=value` pairs separated by semicolons. Most of the tags are short two-letter codes, and once you know what they mean the header stops looking like noise and starts reading like a manifest. The example below shows a representative `DKIM-Signature` header, and the table after it decodes each tag in plain English. You do not need to memorize these — but being able to glance at a signature and read the signing domain, the selector, and which headers were covered is a genuinely useful skill when you are debugging deliverability.

A few of these tags carry most of the meaning. `d=` is the signing domain — the identity DKIM authenticates — and `s=` is the selector that, combined with `d=`, tells the receiver where in DNS to find the public key. `h=` lists exactly which headers were signed; anything not in that list is not protected by the signature, which is why the `From` header is essentially always included. `bh=` is the hash of the body, and `b=` is the signature itself, computed over the signed headers and the body hash together. The `a=` tag names the algorithm — today that is almost always `rsa-sha256`, with the older `rsa-sha1` now deprecated as too weak.

The `c=` (canonicalization) tag is the one that trips people up, so it is worth a plain-English explanation. Email is notorious for being slightly modified in transit — an intermediate server might fold a long header onto two lines, change tabs to spaces, or add trailing whitespace. If the receiver hashed the message byte-for-byte exactly as the sender did, these harmless cosmetic changes would break every signature. Canonicalization is a normalization step that both sides agree to apply before hashing, so that trivial whitespace differences do not cause a false failure. "Simple" canonicalization is strict and tolerates almost no change; "relaxed" is more forgiving of whitespace and header folding. Most senders use `relaxed/relaxed` because it survives the small reformatting that real mail systems do, while still detecting any meaningful tampering.

What is a DKIM selector and the DKIM record?

The selector is the small piece of plumbing that lets the receiver find the right public key, and it explains why a domain can run several DKIM keys side by side. When the receiver reads `d=example.com` and `s=selector1` from a signature, it constructs a very specific DNS name by slotting them into a fixed pattern: `<selector>._domainkey.<domain>`. So those two tags point the receiver at `selector1._domainkey.example.com`, and it queries DNS there for a TXT record containing the public key. That TXT record is what people mean when they say "the DKIM record."

The reason selectors exist — rather than just one fixed location per domain — is flexibility. A single domain often sends mail through several systems at once: its own server, a marketing platform, a transactional email service, a help-desk tool. Each of those can have its own DKIM key, published under its own selector, so they can sign independently without sharing a private key. Selectors also make key rotation safe: to roll a key, you publish a new key under a new selector, switch your signing to it, and only then retire the old selector once no in-flight mail still relies on it. Nothing breaks during the handover because both keys can be live at once.

The DKIM record itself is a DNS TXT record, and its value is also a set of `tag=value` pairs — a different, smaller set than the signature uses. The key field is `p=`, which holds the public key as a base64-encoded string. You will also commonly see `v=DKIM1` (the record version), `k=rsa` (the key type), and sometimes `t=` flags (for testing mode) or `h=` (allowed hash algorithms). The example below shows what a published DKIM record looks like and what each part does.

Why does DKIM key length and rotation matter?

DKIM's security rests on the strength of its keys, and two practical choices govern that: how long the key is and how often it is changed. Both are easy to get wrong by leaving defaults in place for years, so they are worth understanding even if you never touch them directly.

Key length is the size of the cryptographic key, measured in bits for RSA keys. The long-standing recommendation is a minimum of 2048-bit RSA. Older setups sometimes used 1024-bit keys, which were considered adequate years ago but are now regarded as weak — short enough that a well-resourced attacker could, in principle, work to factor them and forge signatures. The 2048-bit size is the current baseline that the major mailbox providers expect. There is a practical wrinkle: a 2048-bit key produces a long public key, and some older DNS interfaces struggle with TXT records over 255 characters, which has to be handled by splitting the value into segments (most DNS providers do this for you automatically). A newer alternative, Ed25519, produces much shorter keys at strong security, but RSA-2048 remains the most broadly supported choice in 2026, so many domains publish both.

Key rotation is the practice of periodically replacing your DKIM key with a fresh one. The logic is the same as changing any long-lived secret: the longer a private key is in use, the worse the damage if it ever leaks. Rotating on a schedule — many organizations aim for every few months to twice a year — limits how long a compromised key stays useful to an attacker. Selectors make rotation painless: you publish the new key under a new selector, move signing to it, leave the old selector live briefly so already-sent mail still verifies, then remove the old record. Because both keys coexist during the overlap, no legitimate mail fails to verify. The bullets below summarize the practical guidance.

• Use at least 2048-bit RSA keys; treat 1024-bit as legacy and replace it. Ed25519 is a strong, shorter modern option but is less universally supported.
• Rotate keys periodically (commonly every few months) to limit the damage window if a private key is ever exposed.
• Rotate using a new selector so the old and new keys overlap — no legitimate mail fails verification during the handover.
• Keep the private key off shared or world-readable storage; it is the one secret that the whole scheme depends on.
• If your provider manages keys via CNAME, rotation usually happens on their side with no action from you.

What does DKIM prove — and what does it not prove?

This is the section that prevents the most misunderstanding, because DKIM is routinely credited with things it does not actually do. A valid DKIM signature is a precise, narrow guarantee, and being clear about its edges is what lets you reason correctly about the whole authentication stack.

A passing DKIM check proves two things. First, authorization: the message was signed by something in possession of the private key for the domain named in the `d=` tag, which means that domain took responsibility for the message. Second, integrity of the signed parts: the headers listed in `h=` and the message body, as they were when signed, have not been altered in transit — because any change would break the hash and fail the signature. Together these make DKIM a strong, cryptographic statement that a specific domain stands behind this message and that the signed content arrived intact.

Now the limits, which matter just as much. DKIM does not, by itself, prove that the visible `From` address is legitimate. The signature authenticates the `d=` domain, and that domain need not match the From address the reader sees. A spammer can perfectly validly DKIM-sign a phishing email with their own throwaway domain — `d=somethrowaway.xyz` — while putting `your-bank.com` in the From field; the DKIM signature passes (it is correctly signed by the spammer's domain) yet the email is still a forgery aimed at the From address. Closing that gap is exactly the alignment job DMARC performs, which we cover next.

DKIM also does not prove the content is true, safe, or sent with good intent — it is an authentication mechanism, not a reputation or spam judgment. A signed message can be malware; a signature only attests to origin and integrity, not honesty. It does not encrypt the message (that is TLS in transit, or PGP/S/MIME end to end) — anyone can still read a DKIM-signed email. And a signature only protects the parts that were signed: headers omitted from `h=` are unprotected, which is part of why DKIM is designed to be used alongside SPF and DMARC rather than alone. The table draws the line clearly.

How do DKIM, SPF, and DMARC work together?

DKIM is one leg of a three-legged stool, and it makes the most sense when you see all three legs at once. The three standards overlap deliberately, each covering a weakness the others leave open, and modern deliverability depends on having all three in place and consistent.

SPF (Sender Policy Framework) checks the path. The domain publishes, in a DNS TXT record, the list of IP addresses and servers allowed to send mail on its behalf. When a message arrives, the receiver checks whether the connecting server's IP is on that authorized list. SPF's weakness is that it validates the envelope sender and the sending server, not the message content, and it breaks when mail is forwarded — because forwarding changes the server in the path while leaving the From address intact. SPF answers "did this come from an approved server?" but says nothing about whether the message was altered.

DKIM checks the message. As we have seen, it cryptographically signs the headers and body and proves a domain authorized an unchanged message. Crucially, because the signature travels with the message, DKIM survives forwarding in a way SPF does not — a forwarded message still carries a valid signature as long as the signed parts are untouched. DKIM's gap, in turn, is that on its own it does not tie the signing domain to the From address the reader sees.

DMARC ties it all together and adds enforcement. It does two things SPF and DKIM cannot do alone. First, alignment: DMARC requires that the domain authenticated by SPF or DKIM matches the domain in the visible From address — closing the exact gap where a spammer signs with their own domain but spoofs yours. A message passes DMARC if it passes SPF with an aligned domain, or passes DKIM with an aligned domain (it needs only one of the two to pass and align). Second, policy and reporting: the domain owner publishes a DMARC record stating what receivers should do with mail that fails — `none` (monitor only), `quarantine` (send to spam), or `reject` (refuse outright) — and receivers send back aggregate reports showing who is sending mail claiming to be that domain. The table summarizes the division of labor.

The concept of alignment deserves one more pass, because it is the linchpin most people miss. DKIM authenticates the `d=` domain; DMARC asks whether that `d=` domain matches the From domain the user sees. "DKIM alignment" means those two line up — `d=example.com` on a message from `you@example.com`. When they align and the signature is valid, DMARC passes on the DKIM leg. When a phisher signs with `d=throwaway.xyz` but spoofs `From: you@example.com`, the signature is technically valid but does not align, so DMARC fails and the receiver applies the published policy — quarantine or reject. This is the mechanism by which the three standards together turn "the From address is just text anyone can type" into "the From address is something a receiver can verify."

In practice you want all three configured and consistent. Deploying DKIM without DMARC leaves the alignment gap open; deploying DMARC without DKIM (or SPF) gives it nothing to enforce against. They are designed as a set.

How do you set up DKIM for a domain?

Setting up DKIM is mostly a configuration task, and the exact clicks depend on your email provider — Google Workspace, Microsoft 365, and every email platform have their own DKIM setup page. But the underlying sequence is the same everywhere, because it follows the mechanism directly: generate a key pair, publish the public key in DNS at the selector location, turn on signing, then confirm it works. The steps below are the provider-agnostic version of what you will do.

Two practical notes before the steps. First, if you send mail through more than one service — say, your mailbox provider plus a marketing platform plus a billing system — each one needs its own DKIM setup, with its own selector and key, so that every stream of mail you send is signed. A message that goes out unsigned (or signed by a domain that does not align) is the one that lands in spam. Second, DNS changes are not instant; after you publish the record, it can take anywhere from a few minutes to a day or so to propagate before verification reliably succeeds, so do not panic if the check fails immediately after you save.

1. 1

   Generate the key pair in your provider

   In your email provider's admin console, enable DKIM / find the authentication settings. It will generate a public/private key pair and keep the private key on its side.

2. 2

   Copy the public key record it gives you

   The provider shows you a DNS record to add — usually a TXT record with the p= public key, or a CNAME pointing at the provider's hosted key, at a selector subdomain.

3. 3

   Add the record at your DNS host

   In your domain's DNS settings (where you manage your nameservers), create the exact record the provider specified at the exact name, e.g. selector1._domainkey.yourdomain.com.

4. 4

   Wait for DNS to propagate

   Allow time for the new record to spread across DNS — minutes to a day. Verification will fail until the record is visible to receivers.

5. 5

   Enable signing in the provider

   Once the record is live, switch on DKIM signing in the provider so outgoing mail starts carrying a DKIM-Signature header. Some providers do this automatically once they detect the record.

6. 6

   Repeat for every sending service

   Do the same for each platform that sends mail as your domain — marketing, transactional, support tools — so every outbound stream is signed under its own selector.

How do you check and verify DKIM?

Once DKIM is set up, you will want to confirm it is actually working — and when something looks off, you will want to read the result. There are two everyday ways to verify: look at the headers of a message you sent, or use a DKIM checker tool that inspects your DNS and a sample message for you.

The most direct check is to send yourself an email (or send to an account at a different provider) and view the raw message headers. In most clients this is under a "Show original" or "View source" option. Look for an `Authentication-Results` header added by the receiving server — it summarizes the SPF, DKIM, and DMARC outcomes in plain text, usually as `dkim=pass`, `dkim=fail`, or `dkim=none`. A `dkim=pass` with your domain in the `header.d=` field means signing and verification are both working and aligned. You will also see the original `DKIM-Signature` header you can decode using the table earlier in this guide. The example below shows what a passing result looks like.

The second route is a DKIM checker or email authentication tester — a free web tool where you either enter your domain and selector to inspect the published DNS record, or send a sample message to a generated address and get back a full report on SPF, DKIM, and DMARC. These decode the record for you, flag a missing or malformed key, warn about a weak (1024-bit) key, and confirm alignment, all without reading raw headers — the fastest way to catch a typo in a record or a selector mismatch.

When a check fails, the cause is almost always one of a small set of issues. The most common is that the DNS record has not propagated yet, or was entered at the wrong name or with a typo in the long public key. Next is a selector mismatch — the signature uses one selector but the published record lives under another. Then there is message modification in transit: a mailing list or forwarding rule that rewrites the subject or body after signing breaks the signature, which is one reason mailing lists historically caused DKIM failures (and why ARC was later introduced to help). Finally, a key that is too short or in a deprecated algorithm can fail at stricter receivers. The bullets list what to check first.

• DNS propagation or a typo: confirm the record exists at the exact selector name and the p= value was copied in full, then allow time to propagate.
• Selector mismatch: the s= in the signature must match the selector where the public key is published.
• Message modified after signing: mailing lists or forwarders that rewrite the subject or body break the signature; check whether a list altered the message.
• Weak key or deprecated algorithm: replace 1024-bit RSA with 2048-bit, and ensure you are using rsa-sha256, not the deprecated rsa-sha1.
• Signing not enabled: confirm the provider is actually adding a DKIM-Signature header to outgoing mail, not just that the DNS record exists.

How does AI Emaily relate to DKIM?

DKIM is mostly the concern of whoever administers a sending domain — it is set up once in DNS and runs in the background on every message. As a person reading and replying to mail, you do not configure DKIM per email, and you should not have to think about it. But the result of all this authentication is something your email client should respect and, where it helps, surface clearly.

AI Emaily is an AI-native email client that brings every account you use — Gmail, Outlook, and any IMAP provider — into one place. Because authentication results travel with each message, a client built with security in mind can use that signal: trusting properly authenticated mail, and treating messages that fail authentication or spoof a sender with appropriate suspicion rather than presenting a forgery as though it were genuine. We treat the content of email as untrusted input and lean on the signals the standards provide, so the inbox you read is shaped by whether a message can actually be verified — not just by what its From line claims.

It is also worth being clear about the boundary. AI Emaily does not replace DKIM, SPF, or DMARC — those are domain-level standards that live in DNS and on sending servers, and they will keep doing their job regardless of which client you read mail in. What a good client adds is making the outcome legible and acting on it sensibly, so the work the standards do reaches you as a safer, clearer inbox. And it is private by design: your mail is yours, used to help you read and write, not to train models for anyone else. You can start free at app.aiemaily.com/signup.

The bottom line on DKIM

DKIM — DomainKeys Identified Mail — closes one of email's oldest holes: the fact that anyone can claim to be anyone. It does this with a clean cryptographic idea. The sending domain signs each message with a private key it keeps secret and publishes the matching public key openly in a DNS TXT record at a selector location. Any receiver can fetch that public key, recompute the hash over the signed headers and body, and confirm two things — that the domain in the `d=` tag authorized the message, and that the signed content was not altered in transit. Because only the private-key holder can sign and anyone can verify, a forger without the key simply cannot produce a signature that passes.

Hold on to the limits as firmly as the guarantees. DKIM proves a domain signed an unaltered message; it does not prove the visible From address is real, that the content is safe, or that the message is encrypted. Tying the signing domain to the From address is DMARC's job, and authorizing the sending server is SPF's — which is why the three are designed as a set. Configure all of them, use a 2048-bit (or Ed25519) key, rotate it on a schedule using selectors, and verify with a checker or by reading the `Authentication-Results` header.

For most people, the practical payoff is simpler than the mechanism: legitimate mail that you send gets trusted and reaches the inbox, and forged mail that targets you can be caught. That is the quiet work DKIM does on essentially every email you send and receive. And in a client built to respect those signals — like AI Emaily — the result reaches you as a safer, clearer inbox, without you ever having to read a signature to get it.