What this analysis does
Enter the sender domain and selector from a real message. Mailybox checks TXT and CNAME forms, parses the key tags, follows common delegation and reports whether the selector is missing, revoked or structurally weak.
DKIM cannot be checked reliably from a root domain alone. The selector and signing domain in a real DKIM-Signature identify the DNS owner name that must be inspected. This tool keeps that message evidence attached to the published key.
Find d= and s= in a real message
Open the raw header of a message sent through the production service. In DKIM-Signature, d= is the signing domain and s= is the selector. Querying a selector copied from another provider or from an old setup can produce a technically correct lookup that says nothing about the message being investigated.
Mailybox builds the selector owner name, checks TXT and delegated CNAME forms and reports the final DNS target. Keeping both the original owner and the delegated target visible makes third-party sending setups easier to audit.
- Use the signing domain from d=, not automatically the visible From domain.
- Copy the selector exactly; DNS labels are not free-form descriptions.
- Test a recently delivered production message after selector rotation.
Interpret the key record conservatively
A DKIM record can identify RSA or Ed25519 key material, restrict service use and declare a revoked selector through an empty public-key value. A record that exists is not automatically usable: malformed tags, duplicate TXT candidates or an empty key are material findings.
Key length is a structural signal, not a message verdict. Rotation decisions should account for provider support, the active signing configuration and evidence that new messages use the replacement selector before the old selector is retired.
DNS lookup and signature verification are different checks
This inspector validates the public record and delegation path. It does not recompute the cryptographic signature over a message body. Receiver-stamped Authentication-Results from a delivered message remains the best evidence that the exact message was verified with the key available to that receiver.
After a DNS correction, send through the same application or provider that produced the problem. Confirm that the new header names the expected selector and that the receiver records dkim=pass.
Example: a provider delegates the selector
Evidence supplied
DKIM-Signature contains d=example.com and s=mail2026. The owner mail2026._domainkey.example.com is a CNAME.
How to read the result
The inspector follows the delegation, displays both DNS names and parses the final key. Delegation is not treated as a missing TXT record at the original owner.
Known limits
- The lookup cannot prove that an ESP is currently signing every stream with the selector.
- A public key alone cannot verify body integrity without the original signed message.
- DNS propagation and resolver caching can temporarily expose different selector states.
Common questions
Can DKIM be checked without a selector?
Not precisely. Obtain the selector from DKIM-Signature or the sending provider configuration.
Does a CNAME mean DKIM is misconfigured?
No. Delegating a selector to a provider is common. The final target and key must still be valid.
What does an empty p= value mean?
It represents a revoked DKIM public key, not a usable signing key.