What Is DKIM? DKIM Record, Selector and How to Set It Up

DKIM (DomainKeys Identified Mail) proves two things about an email: that a server authorized by the domain sent it, and that nobody changed it on the way. It does this with a pair of keys — a private one that stays on the sending server and a public one published in DNS. This article covers the DKIM record, selectors, key length, rotation and how to set it up with your mail services.

How DKIM works

1. The sending server takes selected headers (From, Subject, Date and others) and the body, computes a hash and signs it with the private key.
2. It adds a DKIM-Signature header with the signature and instructions for verifying it.
3. The receiver reads the header, fetches the public key from DNS and checks the signature. If any signed part changed, verification fails.

A shortened signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2025;
  h=from:to:subject:date:message-id; bh=…; b=…

• d= — the signing domain. For DMARC it must align with the From domain.
• s= — the selector, which tells the receiver where to look for the key.
• h= — the list of signed headers; bh= — the body hash; b= — the signature itself.

What a DKIM record looks like

The public key is published as a TXT record at selector._domainkey.domain. For the signature above that is:

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

A 2048-bit key is longer than 255 characters, the limit for a single string in a TXT record. DNS panels handle this differently: some split it automatically, others expect you to paste the value as several quoted strings in one record. If the key arrives broken, the record is usually split into two separate records by mistake — there must be one TXT record whose strings are joined together.

What a DKIM selector is and why there are several

The selector is just a name you or your provider choose: google, selector1, s1, mail2025. It exists so that one domain can have many keys at the same time:

• one for your mailbox provider;
• one for the newsletter platform;
• one for the helpdesk or CRM;
• a new one during key rotation, while the old one is still valid.

There is no way to list all selectors of a domain through DNS — you can only ask for a specific name. That is why checkers try a set of common selectors, and why the reliable way is to read the selector from a real message.

How to find your selector in email headers

1. Send a message from the service you want to check to a mailbox you control.
2. Open the original message with full headers. Most mail clients offer "Show original", "View source" or "Message headers" in the message menu.
3. Find the DKIM-Signature header. The value of s= is the selector, d= is the domain.
4. Also look at Authentication-Results, added by the receiver: it says dkim=pass or fail and for which domain.
5. Paste the domain and selector into the DKIM checker to see the published key, its type and length. Without a selector the tool tries about 30 common ones.

Key length: 1024 or 2048 bits

The DKIM standard requires signers to use keys of at least 1024 bits and recommends 2048. Keys of 512 or 768 bits are considered breakable and receivers may ignore them. In practice:

• Use 2048 bits wherever your provider and DNS panel support it, which today is nearly everywhere.
• 1024 bits still verifies, but there is no reason to choose it for a new key.
• Longer keys (4096) are rarely needed and some DNS panels struggle with their length.

For reference, promopilot.link signs with selector mail and a 2048-bit RSA key (checked in October 2026).

CNAME-delegated keys

Many providers do not ask you to publish the key itself. Instead you publish a CNAME that points your selector to a record they control:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.provider.example.net.

The advantage is that the provider can rotate keys without you touching DNS again. Microsoft 365 works this way with two selectors, selector1 and selector2: you publish both CNAMEs, and it alternates between them during rotation. Many newsletter and transactional platforms also issue two or three CNAMEs. Always copy the exact targets from your provider's admin panel — they contain your tenant or account name and cannot be guessed.

How to set up DKIM

1. List every service that sends as your domain: mailbox, newsletters, CRM, helpdesk, billing, website forms.
2. In each service's admin panel, find the domain authentication or DKIM section and add your domain. The service generates a key pair or CNAME records.
3. Publish the records in your DNS panel exactly as given: the host name (selector plus ._domainkey), the type and the value.
4. Wait for DNS to update, then return to the service and click verify or enable signing. Some providers do not start signing until you do this.
5. Send a test message and check the headers for dkim=pass with d= set to your domain.
6. Repeat for each service, then publish DMARC to see the overall picture — see how to set up DMARC.

Key rotation

A key that never changes is a key that may already be compromised. A clean rotation looks like this:

1. Generate a new key pair and publish the public key under a new selector.
2. Switch signing to the new selector.
3. Keep the old record for at least a few days so delayed and queued messages still verify.
4. Revoke the old key by publishing the record with an empty p=, or remove it.

With CNAME delegation the provider does steps 1–3 for you. If you manage keys yourself, a rotation every 6–12 months is a common practice.

Common DKIM problems

• Record not found — wrong host name. Some panels append the domain automatically, so mail._domainkey.example.com becomes mail._domainkey.example.com.example.com. Enter only mail._domainkey.
• Key broken — extra spaces, quotes or line breaks inside p=, or the key split into two records.
• Signature fails after sending — something modifies the message after signing: a footer added by a gateway, a mailing list, a security appliance.
• DKIM passes but DMARC fails — the service signs with its own domain. Enable signing with your domain.

Why DKIM matters more than SPF for DMARC

SPF is tied to the IP address that delivers the message, so it breaks whenever mail is forwarded: the forwarding server is not in your SPF record. A DKIM signature travels inside the message and survives forwarding as long as the signed parts are not changed. That is why a domain that relies on SPF alone sees DMARC failures from forwarded mail, while a domain with aligned DKIM on every stream does not. If you can only fix one thing for a third-party sender, enable DKIM with your own domain.

DKIM is one of three parts. How it fits together with SPF and DMARC is explained in SPF, DKIM and DMARC explained; to check the rest of the mail setup, use the SPF checker, MX lookup and IP blacklist check.