DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The receiving server uses it to confirm that the message was really sent with your domain's authorization and wasn't changed along the way. Here's how signatures and keys work, how to check DKIM, and how to rotate keys without downtime.
How DKIM works
DKIM uses a key pair: a private key and a public key.
- The private key stays on the sending mail server. The server computes a signature over the message body and selected headers and adds a
DKIM-Signatureheader. - The public key is published in the domain's DNS as a TXT record.
- The receiving server reads the domain and selector from the signature, fetches the public key from DNS, and verifies the signature.
If the message was altered in transit (subject, body, or a signed header), the signature won't match and the result is dkim=fail. Unlike SPF, DKIM doesn't depend on the sending server's IP address, so it usually survives forwarding.
Selectors and the DNS record
A selector is an arbitrary name that lets one domain have several keys at once, such as one for corporate mail and another for a newsletter service. The public key lives at <selector>._domainkey.<domain>:
mail2026._domainkey.example.uz. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."| Tag | Meaning |
|---|---|
v=DKIM1 | Version; recommended, and it should come first |
k=rsa | Key type; RSA is the default |
p= | Public key in base64; an empty value means the key is revoked |
t=y | Optional testing-mode flag |
You can name a selector anything. Including a date or sequence number (mail2026, s202610) makes it obvious which key is newer when you rotate.
Some newsletter services ask for a CNAME instead of a TXT record: s1._domainkey.example.uz points to a name the service controls, and the service manages the key. That's a normal setup.
Key length: 2048 bits
1024-bit RSA keys are the bare minimum and are being phased out. Today, 2048 bits is the standard choice. 4096-bit keys offer no real practical benefit, are awkward to fit in DNS, and aren't supported by every receiver.
A 2048-bit public key is about 400 characters in base64, but a single string in a TXT record is limited to 255 characters. So the key is split into several quoted strings within one record:
mail2026._domainkey.example.uz. IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...first part..."
"...second part of the key...IDAQAB" )Most DNS web panels split it for you if you paste the whole key. If your panel truncates long values, check with dig that the full key comes back.
How to check DKIM
The DNS record
dig TXT mail2026._domainkey.example.uz +shortOn Windows: nslookup -type=txt mail2026._domainkey.example.uz. The answer should contain v=DKIM1 and the key in p=.
Message headers
Send a message to an external mailbox and open its raw source (in webmail this is usually called "Show original" or "View source"). Look for the signature:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.uz;
s=mail2026; t=1760000000; h=from:to:subject:date:message-id;
bh=...; b=...d=— the signing domain. For DMARC, it needs to match the domain in the From address.s=— the selector used to find the key.h=— the list of signed headers;fromis always required.c=— canonicalization;relaxed/relaxedtolerates minor whitespace and header-case changes.bh=andb=— the body hash and the signature itself.
The receiving server records the result in a header like this:
Authentication-Results: mx.recipient.example;
dkim=pass header.d=example.uz header.s=mail2026Why DKIM fails
| Result | Likely cause |
|---|---|
dkim=none | The message isn't signed; signing isn't enabled for the domain |
dkim=permerror or "no key" | No record for that selector, a typo in the name, or a truncated key |
dkim=fail, "body hash did not verify" | The body changed after signing: a gateway disclaimer, antivirus, or a mailing list |
dkim=fail, "signature verification failed" | The key in DNS doesn't match the private key on the server |
Don't use the l= tag (signed body length), even if some guide suggests it. It lets an attacker append their own content to a signed message without breaking the signature.
Key rotation
It's good practice to rotate DKIM keys periodically, say every 6–12 months, and immediately if you suspect the private key has leaked. Selectors make this possible without downtime:
- Generate a new key pair and publish the public key under a new selector (
mail2027), leaving the old one in place. - Wait until the record is visible in DNS (allow for the TTL).
- Switch the server to sign with the new selector and check the headers of a test message.
- Keep the old key in DNS for a few more days so that delayed messages still verify.
- Delete the old record, or publish it with an empty
p=to explicitly revoke the key.
With MCMail, we generate and enable the DKIM keys for your domain and send you the public-key record when you connect it. DKIM works together with SPF and DMARC; it takes all three to give receivers real confidence in your mail.