What is DKIM? How DKIM signatures and records work

DKIM, short for DomainKeys Identified Mail, is a signature the sending server adds to each message it sends. The receiving server checks it against a public key the signing domain publishes in DNS, and when the check passes it knows which domain vouches for the message and that the signed parts arrived as they left.

The standard is RFC 6376 from 2011, now a full Internet Standard. For how DKIM fits with SPF and DMARC, see the overview.

What DKIM proves, and what it does not

A valid signature proves two things:

• The domain in d= took responsibility for the message. RFC 6376 calls DKIM a way to "claim some responsibility for a message".
• The signed parts did not change. The body and the signed headers hash to the values they had at signing.

Nothing else. The signer need not be the author, so d= does not have to match the From address a person reads: a newsletter tool can sign your campaign with its own domain. Checking that the two match is the job of DMARC.

Nor does a pass mean the mail is wanted. Spammers can sign with domains they own, so a signature only gives receivers a reliable name to attach reputation to. DKIM encrypts nothing either: the message stays as readable as before.

How DKIM signing works

When a message leaves, the signing server:

1. Canonicalises a copy, a standard form used only for hashing, so harmless changes on the way do not break the signature.
2. Hashes the body with SHA-256 and writes the result, in base64, into bh=.
3. Hashes the signed headers, listed in order in h= with From always among them, followed by the new DKIM-Signature header with b= left empty.
4. Signs that hash with the domain's private key, puts the result in b= and adds the header to the message.

The c= tag sets canonicalisation for headers and body separately. simple tolerates almost no change. relaxed lowercases header names, unfolds wrapped lines and collapses runs of spaces, so it survives the whitespace changes servers make. Set c=relaxed/relaxed explicitly: a signature without c= is read as simple/simple.

How a receiver verifies a DKIM signature

The receiver repeats the work and compares:

1. It fetches the TXT record named by the selector, then _domainkey, then the domain in d=: s1._domainkey.example.com.
2. It hashes the canonical body and compares the result with bh=.
3. It hashes the headers in h= and checks b= against that hash with the public key.

RFC 6376 names each way this can fail, and the names point at the cause:

A failed signature does not get mail refused: RFC 6376 tells receivers not to decide on it alone, and the domain's DMARC policy says what happens next.

A DKIM-Signature header, tag by tag

A sending server adds a header like this one, shortened:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;  t=1793404800; x=1794009600;  h=from:to:subject:date:message-id:mime-version:content-type;  bh=yQ9Ac4INleo9rDdPpDn+QbR2lLxdU1/Pkb6filuIXrU=;  b=JyW9sJyJSoF9KC8i6dl4yeMLpt7M5GJbhBKj34ydDu7bUxTFXAFJTdwHEukT5pcU...

Of the tags not shown, i= names the user the domain signs for, and l= limits how much of the body is signed, a risk covered below.

The DKIM record in DNS

The public key sits in a TXT record at the selector's name:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Remove t=y once you are live: receivers must treat mail from a domain in testing mode exactly like unsigned mail.

Why a 2048-bit key needs two strings

A TXT record holds text in strings of up to 255 characters, and the base64 of a 2048-bit RSA key alone is 392. So the record is published as two strings, which receivers join with nothing in between:

s1._domainkey.example.com.  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."                                   "...IDAQAB" )

A 1024-bit key, at 216 characters, fits in one string, but use 2048 bits wherever your DNS provider allows, as Google advises.

RSA or Ed25519: which DKIM key to use

RFC 8463 requires every verifier to support Ed25519, yet Red Sift's April 2026 test of 19 mailbox providers found 9 that verified it, and Gmail, Microsoft 365, Yahoo and iCloud were not among them. Use it only as a second signature beside RSA, under its own selector, as RFC 8463 describes: a receiver that cannot check one still checks the other.

What is a DKIM selector?

Every signature names its key with s=, and that name is the selector. RFC 6376 leaves the number of selectors to the domain owner, so each service that sends for a domain can sign with its own key: your mailbox provider under one selector, your newsletter tool under another.

A service can also take over a selector through a CNAME. You publish a pointer, and the service keeps the key at its end and rotates it without you touching DNS:

s1._domainkey.example.com.  CNAME  s1.example-com.dkim.example.net.

Can a domain have more than one DKIM record?

Yes, one per selector. The mistake is two TXT records at the same selector: RFC 6376 leaves the result undefined, and a receiver may use either. A new key gets a new selector.

How do I find my DKIM selector?

Read s= in the DKIM-Signature header of a message your domain sent. DNS has no way to list the names under _domainkey, so a checker has to know or guess. Our deliverability checker tries the selectors your mail provider is known to use plus a common set, and says when a key it finds has been revoked.

How to rotate a DKIM key

A key that signs for years has years in which to leak. M3AAWG, the messaging industry's anti-abuse group, recommends rotating at least every six months, in a guide last revised in 2019:

1. Publish the new key under a new selector and wait until DNS serves it.
2. Switch signing to the new key.
3. Keep the old key published for seven to 30 days, so mail in transit still verifies.
4. Retire it by emptying p=, keeping the record so receivers can see the retirement was deliberate.

Never put a new key under an old selector: RFC 6376 warns that a failure caused by the changed key then looks exactly like a forgery. Dated selectors such as s202611 keep the order obvious.

Why DKIM survives forwarding but not mailing lists

A forwarding server usually passes a message on unchanged, so the signature still checks out at the other end. SPF usually fails there instead, because it checks the server that hands the message over. RFC 9989, the DMARC standard published in May 2026, agrees: on a relay, "DKIM signatures will generally remain valid".

Mailing lists are different. A list that tags the subject or adds a footer changes signed content, and the signature fails. In the words of the IETF's DKIM working group, the signature of a re-posted message "typically does not survive and cannot be recovered".

List software has adapted by rewriting the From line, often to the list's own address, so DMARC is judged on a domain the list controls. ARC, the Authenticated Received Chain, was designed to make that rewrite unnecessary, but RFC 9989 notes that it has not become widely used.

The l= tag and DKIM replay

The l= tag limits the body hash to the first so many bytes, so a list can add a footer without breaking the signature. Anything after that point is unsigned, and RFC 6376 warns that it can "completely replace the original content in the end recipient's eyes". Leave the tag out.

Replay works because a signature covers the message, not the envelope that says who receives it. Someone who gets one signed message, for instance by sending spam through a large provider that signs it, can resend it to thousands of new recipients, and every copy still verifies under the provider's good name. RFC 6376 offers only partial defences, such as receivers spotting one signature in unusual volume.

Senders can limit what a replayed copy may change: sign every header a reader sees, and list From, To, Subject and Date in h= once more than they appear, so a copy that gains a second Subject fails. A service that lets strangers send should filter what it signs: replay starts with a signature given away.

A lasting fix is in progress: the IETF's DKIM working group has adopted DKIM2, which aims to record every server a message passes through and every change each one makes, so a receiver can tell an honest forward from a replay. The group's target for sending its documents to the IESG for approval is March 2027.

What Gmail, Yahoo and Microsoft require

Gmail and Yahoo made authentication a condition of delivery in February 2024, and Outlook.com followed in May 2025:

Outlook.com refuses mail that misses the bar with 550 5.7.515: Microsoft first planned to send it to Junk, and decided on rejection before the rules took effect. Gmail may mark unauthenticated mail as spam or refuse it with a 5.7.26 error.

Is DKIM enough without SPF?

For DMARC, yes: one aligned pass is enough, and DKIM is the one that survives forwarding. RFC 9989 makes DKIM the one you cannot skip, because a domain at p=reject "MUST apply valid DKIM signatures" and must not rely on SPF alone. The large mailbox providers still want both from bulk senders, so publish both and let DMARC tie them together.

Where Nextmail fits

Every domain you add to Nextmail gets its own signing key, and its signing record is listed with the MX and SPF records from the moment you add it. Sending switches on shortly after that record answers in public DNS. Where a record does not match yet, the domain page shows what DNS answers and the usual reason, such as a DNS provider that added your domain to the name twice.

Connect a domain has the steps, and Domains explains how records are checked. The deliverability checker reads any domain's SPF, DKIM, DMARC, BIMI and MX records from live DNS and says what each one means and what is missing. The same check runs over the API.