Unitpost

Look up a DKIM record

Finds your public key and checks its type and size.

The s= value in a sent message's DKIM-Signature header. Empty tries common ones.

The lookups go from your browser to a public DNS-over-HTTPS resolver. Nothing is sent to Unitpost, and there's no sign-up.

A DKIM record is a TXT record at selector._domainkey.yourdomain holding the public key receivers use to verify the DKIM-Signature on your mail. The selector is the s= tag of that signature. Enter it to see the key's type and size (RFC 8301 requires at least 1024 bits and recommends 2048), whether the key is revoked or in testing mode, and what to fix. Without a selector, the lookup tries common ones.

How to find your DKIM selector

The selector is the s= value in the DKIM-Signature header of a message you sent, and the key is published at <s>._domainkey.<d>, where d= is the signing domain.

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

Here the key is at s1._domainkey.example.com. DNS has no way to list the selectors a domain uses, so a lookup needs the name. Without one, this tool tries a set of common selectors, and finding nothing there proves nothing.

To get the header, open a message you sent in Gmail and choose Show original, or paste the headers into the header analyzer, which lists every signature's d= and s=. If you send through Unitpost, the selector is part of the DKIM record name shown on your domain page.

Key sizes: 1024 or 2048 bits

Use a 2048-bit RSA key. RFC 8301 requires signers to use at least 1024 bits, recommends 2048, and tells receivers not to accept signatures from shorter keys.

KeyStatus
RSA under 1024 bitsNot accepted: receivers give the signature no credit (RFC 8301).
RSA 1024 bitsThe minimum. It verifies, and Gmail accepts it for personal accounts while recommending 2048.
RSA 2048 bitsRecommended. Unitpost generates a 2048-bit key for each domain.
Ed25519Defined in RFC 8463, with a short key. Sign with an RSA key as well, because a receiver that doesn't support Ed25519 ignores that signature.

A 2048-bit key's p= value is longer than the 255 characters one TXT string can hold. Publish it as one record made of several quoted strings, which receivers join; never as two records.

CNAME-delegated keys

Some providers ask you for a CNAME at <selector>._domainkey.<domain> that points at a key they host, instead of a TXT record holding the key. Receivers follow the CNAME, and so does this lookup, so the key shows as if it were published directly.

The provider can then rotate the key without you editing DNS. The cost is that the key lives in their zone: if the target goes away, every signature with that selector fails. Unitpost asks for a TXT record with the key itself.

Rotating a DKIM key

Publish the new key under a new selector, switch signing to it, and remove the old selector only after mail signed with it has been delivered.

  1. Generate the new key pair and publish its public key at a new selector, such as s2._domainkey.example.com.
  2. Look it up here until it resolves with the expected key size.
  3. Switch your signer to the new selector, and check a fresh message's s=.
  4. Leave the old record in place while delayed and retried mail signed with it is still arriving, then remove it or empty its key (v=DKIM1; p=), which receivers read as revoked.

If signatures fail after a change, see why DKIM verification fails.

Errors and how to fix them

No DKIM record found

Also reported as: DKIM record not found; DKIM selector not found; dkim=none

None of the common selectors this tool tried has a key. That doesn't prove the domain has none: DNS can't list selectors, and many providers use names of their own.

  1. Open a message you sent and copy the s= value from its DKIM-Signature header.
  2. Enter it as the selector and check again.
  3. If the message has no DKIM-Signature header, your sending service isn't signing for your domain. Turn DKIM on there and publish the record it gives you.

DKIM selector not found in DNS

Also reported as: No DKIM key found for selector; dkim=neutral (no key for signature); DKIM public key not found

There is no record with a public key at <selector>._domainkey.<domain>. Signatures that name this selector can't be verified, so DKIM comes back failed or neutral for them.

  1. Compare the selector with the s= tag of a recent message; it changes when a provider rotates keys.
  2. Check the name in your DNS editor. Most editors add the domain, so enter s1._domainkey; typing the full name there creates s1._domainkey.example.com.example.com.
  3. Publish the record your provider shows for that selector, then check again.

DKIM key revoked (empty p=)

Also reported as: DKIM public key revoked; Empty p= tag in DKIM record

The record exists but its p= is empty, which RFC 6376 defines as a revoked key. Every signature that uses this selector fails.

  1. If you still sign with this selector, publish the current public key in p=.
  2. If the key was retired on purpose, make sure your signer uses another selector, and look that one up instead.

DKIM record syntax error

Also reported as: Invalid DKIM record; Malformed DKIM record

The key reads fine, but another part of the record doesn't: v=DKIM1 is not the first tag or has another value, or a part isn't a tag=value pair. RFC 6376 has receivers discard a record whose v= isn't DKIM1, and the key with it.

  1. Rewrite the record as v=DKIM1; k=rsa; p=<public key>, with v=DKIM1 first and semicolons between tags.
  2. Copy the value again from your provider rather than editing it by hand.
  3. Check again.

DKIM public key is invalid or truncated

Also reported as: DKIM key could not be parsed; Invalid DKIM public key; DKIM record has no p= tag

The record has no usable key: p= is missing, its value doesn't decode to an RSA or Ed25519 public key, or k= names a type receivers don't support. The usual cause is a key cut short when pasted, or split across two records.

  1. Compare the p= value in DNS with the one your provider gave you, character for character; a shorter value was truncated.
  2. If your DNS editor limits the field length, enter the key as several quoted strings in one record.
  3. Remove anything pasted into the middle of the key, such as a stray quote mark.
  4. Check again. More in the public key was truncated.

DKIM key shorter than 1024 bits

Also reported as: Weak DKIM key; DKIM key too short; 512-bit DKIM key

RFC 8301 tells receivers not to accept signatures made with RSA keys under 1024 bits, so mail signed with this key gets no DKIM credit.

  1. Generate a 2048-bit key in your sending service, or with openssl genrsa -out dkim.key 2048 if you sign yourself.
  2. Publish it under a new selector and switch signing to it.
  3. Remove this record once nothing signs with it.

DKIM key is 1024 bits

Also reported as: 1024-bit DKIM key; Upgrade DKIM key to 2048 bits

1024 bits is the minimum RFC 8301 allows, and signatures with it verify. It is flagged because 2048 bits is the current recommendation, from the RFC and from Gmail.

  1. Rotate to a 2048-bit key under a new selector the next time you change DKIM; see rotating a DKIM key.
  2. Publish the longer key as several quoted strings in one TXT record.

DKIM record in testing mode (t=y)

Also reported as: DKIM t=y flag; DKIM test mode

t=y tells receivers the domain is testing DKIM, and RFC 6376 says they must not treat its mail differently from unsigned mail. A signature with this key can earn your mail nothing.

  1. Confirm signatures verify: send a message to a Gmail address and look for dkim=pass under Show original.
  2. Remove t=y from the record, leaving v=DKIM1; k=rsa; p=<public key>.

DKIM record only allows SHA-1

Also reported as: rsa-sha1 DKIM signature; DKIM h=sha1

The record's h= tag lists the hash algorithms it may be used with, and sha256 isn't among them. RFC 8301 retired SHA-1 for DKIM, so signatures this key allows are not accepted.

  1. Remove the h= tag, which allows every algorithm, or set h=sha256.
  2. Make sure your signer uses a=rsa-sha256.

Frequently asked questions

What is a DKIM selector?

A name that picks one of the domain's DKIM keys, so a domain can publish several at once. The signature names it in `s=`, and the key lives at `<selector>._domainkey.<domain>`.

How do I find my DKIM selector?

Open a message you sent, view its original headers, and read `s=` in the DKIM-Signature header. Your sending service's DNS instructions also show it.

Should I use a 1024-bit or 2048-bit DKIM key?

2048-bit. RFC 8301 and Gmail both recommend it; 1024 still verifies but is the minimum. Publish a 2048-bit key as several strings in one TXT record.

Can a domain have more than one DKIM key?

Yes. Each key sits at its own selector, so one per sending service is normal, and two for the same service is how a key rotates without failures.

Why does DKIM pass but DMARC fail?

The signature passed for a domain that doesn't match your From domain, usually your provider's (`d=provider.example`). Set up DKIM for your own domain in the provider so it signs with `d=yourdomain`.

Go deeper: Why DKIM verification fails · SPF and DKIM for bulk senders · Sending domains in Unitpost

Free tools

Send from a domain that checks out

Unitpost sets up SPF, DKIM and DMARC with you and keeps checking them.

Start for freeExplore the docs