DNSVerdictAll toolsGuidesHow it works

How DKIM works and how to publish a DKIM record

Published · Updated

DKIM signs each outgoing message with a private key held by your mail service; receivers fetch the matching public key from DNS and check the signature. To publish it, create a record at <selector>._domainkey.<yourdomain> with the value your provider gives you, as a TXT record or, for providers that manage keys for you, as a CNAME. The selector is chosen by the signer and appears in the s= tag of the DKIM-Signature header. Use RSA keys of 2048 bits where your DNS host allows it; 1024 is the minimum.

What the record looks like

RFC 6376 §3.1 divides the key namespace into selectors so one domain can hold several keys at once, and §3.6.2.1 says all keys live under _domainkey. A signature with d=example.com; s=mail2026 is verified against the TXT record at mail2026._domainkey.example.com:

mail2026._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
TagMeaningDefault
v=DKIM1Version; if present, must be firstDKIM1
k=rsaKey typersa
p=Base64 public key; required; empty means revokednone
t=yTesting flag: the domain is testing DKIM; do not treat failures as a reason to penalizenot set
t=sSigning domain must equal the From domain exactlynot set
h=, s=, n=Hash restriction, service type, notesall / * / none

Copy the value exactly as your provider shows it. A missing character in p= produces a “key syntax” or “bad signature” result.

TXT or CNAME

Providers publish keys in two ways. With a TXT record you paste the public key, and you are responsible for rotating it. With a CNAME, you point the selector at a name the provider controls, for example selector1._domainkey aliasing a host under the provider’s domain, and the provider can rotate the key without you touching DNS. Microsoft 365 uses CNAMEs for its two selectors; Google Workspace uses a TXT record (see the Google Workspace and Microsoft 365 guides). Follow the type your provider specifies: a CNAME cannot coexist with a TXT at the same name (RFC 2181 §10.1), so you cannot use both for one selector. The provider setup check tests the selectors of providers in our database.

Key length and long values

RFC 6376 §3.3.3 required signers to use at least 1024-bit RSA keys for long-lived keys; RFC 8301 §3.2 tightened this to “at least 1024 bits for all keys” and added that signers SHOULD use at least 2048 bits. It also states that verifiers must not accept signatures made with keys under 1024 bits. Use 2048 bits unless your DNS host refuses the length.

A 2048-bit key is longer than 255 characters, the limit of one DNS character-string. Publish it as several quoted strings in one TXT record; verifiers concatenate them with no whitespace (RFC 6376 §3.6.2.2):

mail2026._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                           "...rest of the key..." )

Many DNS panels split the value automatically. If yours does not, and rejects long values, split it manually; do not insert spaces inside the key. If the host is the problem, a 1024-bit key is acceptable as a fallback, with the trade-off that it is easier to attack.

Rotating and revoking keys

RFC 6376 §3.1 recommends assigning new keys to new selectors, not reusing a selector. A rotation looks like this:

  1. Publish the new key under a new selector (mail2027).
  2. Switch your mail service to sign with the new selector.
  3. Keep the old record for a validation interval so messages still in transit verify, then delete it.

To revoke a key, publish the record with an empty p= (§3.6.1: “An empty value means that this public key has been revoked”):

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; p="

Verifiers then treat signatures that use that selector as failures. Revoke when a private key leaks or when a service that held it no longer sends for you. Mail that your own systems still sign with that selector will fail too, so move signing to another selector first.

Find your selector

Send a message to a mailbox you control, copy its full headers, and paste them into the email header analyzer. Look for the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

d= is the signing domain and s= the selector. Query <s>._domainkey.<d> with the DNS lookup for TXT (or CNAME) to see what is published. If d= is the provider’s domain rather than yours, DMARC will not align on DKIM; DMARC fails although SPF and DKIM pass explains the fix.

FAQ

Can I publish more than one DKIM record? Yes, one per selector. Each service you use normally has its own selector. Only one TXT record may exist at any single selector name (§3.6.2.2).

How long does a new DKIM record take to work? As long as the DNS TTL of any cached negative answer, plus the time your provider takes to start signing. Providers quote up to 48 hours; test with a new message after enabling signing, not an old one.

Does DKIM encrypt my mail? No. It only proves the signed headers and body were not modified and that the signing domain authorized the message.

Sources

Tools used

Email Header AnalyzerEmail Provider Setup CheckDNS Lookup