What is a DKIM selector?

A label that identifies which key to use, published at ._domainkey. . Using a different selector per sending service lets you rotate or remove one without affecting the others.

What key length should I use?

2048-bit RSA. 1024-bit is considered weak and is being phased out by major receivers, though it remains common in older configurations.

Why does DKIM fail after my message goes through a mailing list?

The list modified the message — appended a footer, rewrote the subject or altered links — which invalidates the body hash. ARC was designed to preserve authentication results across such intermediaries.

Does DKIM alone stop spoofing?

No. Without DMARC, a receiver has no instruction about what to do when DKIM is absent or misaligned. DKIM plus DMARC alignment is what closes the gap.

TLS & Email🌐 YAS server-sideAPI availableadvanced

DKIM Inspector

Validates a DKIM selector's public key record (length, flags, syntax).

Processed by YAS · not stored

Ready to runInstant execution

All tools →

DKIM Inspector — <selector>._domainkey.<domain>

Validates v=DKIM1, extracts the RSA key length from the DER public key, and reads t= flags.

What does this tool do?

Validates a DKIM selector's public key record (length, flags, syntax).

Why would I use it?

DKIM signatures fail and you suspect the key record.
You want to confirm the published key matches your signing key.
You are setting up DKIM for a new sender.

Real-life example

Input

example.com, selector: default

Output

default._domainkey.example.com → v=DKIM1; k=rsa; p=MIIB... (2048-bit RSA)

The key type and length are validated.

Input → Process → Output → Next

Input: Enter domain and selector.
Process: YAS queries <selector>._domainkey.<domain> and validates the key.
Output: The DKIM record with key details.
Next action: Publish a correct key and confirm signatures in mail headers.

Common mistakes

Using a key shorter than 1024 bits.
Forgetting the selector used by your mail provider.
Confusing DKIM key records with DMARC or SPF records.

What the result means

A valid public key record is required for DKIM signatures to verify.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/dkim-inspector

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/dkim-inspector" \
  -H "Content-Type: application/json" \
  -d '{"input":"example.com","selector":"selector1"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/dkim-inspector", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "example.com",
  "selector": "selector1"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/dkim-inspector", json={"input":"example.com","selector":"selector1"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	Domain, e.g. example.com
selector	string	No (default "selector1")	DKIM selector

Success response

{ "result": { "found": true, "record": "v=DKIM1; k=rsa; p=MIIB...", "keyLength": 2048, "flags": [], "valid": true } }

Validate <selector>._domainkey.<domain> TXT: v=DKIM1, k=rsa, key length, t= flags.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How DKIM Inspector works

DKIM signs selected headers and the message body with a private key held by the sender, and publishes the public key as a TXT record at <selector>._domainkey.<domain>. The receiver reads the selector and domain from the DKIM-Signature header, fetches the key, and verifies the signature. Because the signature travels with the message, it survives relaying — unlike SPF, which is tied to the connecting host.

Two mechanics cause most failures. The body hash covers the message content, so any modification in transit — a mailing list appending a footer, a security appliance rewriting links — invalidates the signature. And the h= tag lists which headers are signed; headers not listed can be added or altered without breaking verification, which is why signing From: is essential and why over-signing is used to prevent header injection.

When to use it: real-world scenarios

Verifying a new sending platform is signing as your domain

Providers often sign with their own domain by default, which passes DKIM but fails DMARC alignment. Checking the selector record confirms which domain is signing.

Diagnosing signatures that fail after a mailing list

List software that appends footers or rewrites subjects breaks the body hash. Confirming the selector is valid narrows it to in-transit modification.

Rotating keys safely

Publish the new selector, switch signing, then retire the old selector after the last signed message could plausibly still be verified.

Auditing key strength

1024-bit DKIM keys are still widespread and are considered weak; 2048-bit is the current expectation.

Pro tips

Use a distinct selector per sending platform. It makes rotation and decommissioning independent, and identifies the source of any failure immediately.
Publish 2048-bit keys. If your DNS provider struggles with the record length, split the TXT into multiple quoted strings — resolvers concatenate them.
Never delete an old selector immediately after rotation. Messages in transit or in a delayed queue still reference it.
Check that the key record has no stray whitespace or line breaks in the p= value; a single wrapped character invalidates every signature.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

DKIM proves a message was signed by a holder of the key and unmodified since; it does not prove the content is trustworthy.
Any in-transit modification breaks the signature, which is a legitimate protocol behaviour rather than a bug.
Verification requires the message itself; a DNS check alone confirms only that the key is published and well-formed.
Key compromise is undetectable through DNS — rotation is the only remedy.

Frequently asked questions

What is a DKIM selector?: A label that identifies which key to use, published at <selector>._domainkey.<domain>. Using a different selector per sending service lets you rotate or remove one without affecting the others.
What key length should I use?: 2048-bit RSA. 1024-bit is considered weak and is being phased out by major receivers, though it remains common in older configurations.
Why does DKIM fail after my message goes through a mailing list?: The list modified the message — appended a footer, rewrote the subject or altered links — which invalidates the body hash. ARC was designed to preserve authentication results across such intermediaries.
Does DKIM alone stop spoofing?: No. Without DMARC, a receiver has no instruction about what to do when DKIM is absent or misaligned. DKIM plus DMARC alignment is what closes the gap.

Related tools

SPF Inspector DMARC Inspector