{{ summaryTitle }}
{{ summaryFigure }}
{{ summaryLine }}
{{ badge.label }}
Identity DNS lookup inputs
Enter a mailbox or mailto link, for example alice@example.com.
SMIMEA queries _smimecert type 53; OPENPGPKEY queries _openpgpkey type 61.
Use Derived for mailbox input; Manual only for a complete DNS owner name.
Format: hash._smimecert.example.com or hash._openpgpkey.example.com.
Auto tries Cloudflare first, then Google only if transport fails.
Enable for fresh DNS publication or inconsistent public answers.
{{ compare_resolversBool ? 'On' : 'Off' }}
Accepted range: 1000-15000 ms; 4500 ms is the default.
ms
Field Value Copy
{{ row.label }} {{ row.value }}
Field Value Copy
{{ row.label }} {{ row.value }}
{{ header }} Copy
{{ row.index }} {{ row.owner }} {{ row.ttl }} {{ row.detailA }} {{ row.detailB }} {{ row.detailC }} {{ row.notes }}
No {{ activeFamily.recordLabel }} payload was returned by the primary resolver. Review the Identity DNS Brief and Resolver Evidence tabs for the outcome.
Resolver Outcome Records AD TTL / negative cache Time (ms) Set digest Alias chain Copy
{{ row.resolver }} {{ row.outcome }} {{ row.records }} {{ row.ad }} {{ row.ttl }} {{ row.time }} {{ row.digest }} {{ row.aliasChain }}

        
Customize
Advanced
:

Email encryption discovery has two questions that should stay separate. The first is whether public key material is published for a mailbox. The second is whether that material should be trusted for a real recipient. SMIMEA and OPENPGPKEY records answer the discovery question by placing S/MIME certificate associations or OpenPGP transferable public keys in DNS, where DNS delegation, caching, aliases, resolver policy, and DNS Security Extensions (DNSSEC) all affect the evidence returned by a lookup.

The mailbox local part is not placed in DNS as plain text. It is prepared, hashed with SHA-256, truncated to the leftmost 28 octets, and written as a 56-character hexadecimal label. The family label then identifies the record type being requested, while the domain remains visible at the right side of the owner name. This hides the exact local part from simple zone browsing, but it does not make the query anonymous because the derived owner name, domain, resolver path, and timing are still visible to the resolver used for the lookup.

Mailbox local + domain Prepare local part SHA-256 leftmost 28 octets Owner family label DNS answer SMIMEA uses _smimecert and type 53. OPENPGPKEY uses _openpgpkey and type 61.
SMIMEA
Publishes an S/MIME certificate association below _smimecert with RR type 53. The payload follows the TLSA-style usage, selector, and matching-type structure before the association bytes.
OPENPGPKEY
Publishes an OpenPGP transferable public key below _openpgpkey with RR type 61. The record carries the DNS key blob, not a human-readable OpenPGP fingerprint.
DNSSEC AD
The authenticated-data flag is resolver evidence that the answer was validated through DNSSEC. It is useful only when the resolver and transport path are trusted for that decision.

Publication mistakes often come from address handling before DNS is queried. Quoting, comments, whitespace around dots, Unicode normalization, plus-addressing conventions, case handling, and domain spelling can all change the prepared local part or final owner name. A mail system may deliver two address variants to the same mailbox while SMIMEA and OPENPGPKEY derive different DNS owner names for those variants.

A positive answer is therefore a starting point, not an end-to-end trust decision. A deployment review should compare the derived owner name, record family, DNSSEC evidence, TTLs, resolver agreement, and payload bytes against the certificate or OpenPGP key workflow the organization intends recipients to use.

How to Use This Tool:

Start with derived owner mode for a normal mailbox lookup. Use manual owner mode only when you already have a complete owner name from a zone file, resolver trace, or another diagnostic.

  1. Enter one Email identity, such as alice@example.com or a mailto: link. The lookup extracts the mailbox before deriving the DNS owner.
  2. Choose Record family. SMIMEA checks the _smimecert owner suffix and RR type 53. OPENPGPKEY checks the _openpgpkey owner suffix and RR type 61.
  3. Leave Owner source on Derive from email address unless you want to query an exact owner name directly. Manual owner mode bypasses mailbox hashing and uses the normalized owner name you enter.
  4. Use Resolver profile to choose Auto, Cloudflare only, or Google only. Auto tries Cloudflare first and falls back to Google only when the first resolver path has a transport failure.
  5. Turn on Compare public resolvers during fresh publication, key rollover, or inconsistent answers. The result then compares Cloudflare and Google answer sets for the same owner name.
  6. Adjust Timeout per query only when resolver requests are failing. The accepted range is 1000 to 15000 ms, and the default is 4500 ms.
  7. Read Identity DNS Brief first. Then use Owner Name Build, the payload tab, and Resolver Evidence to inspect the owner derivation, returned data, AD status, TTLs, negative-cache clues, alias chain, and resolver agreement.

If the form reports Enter one mailbox like alice@example.com, fix the address format or switch to manual owner mode with a complete _smimecert or _openpgpkey owner name.

Interpreting Results:

Record found means the primary resolver returned at least one record of the selected family. Confirm that Lookup owner used matches the owner name you expected, that the record family is correct, and that the payload row matches the certificate association or OpenPGP key material you intended to publish.

  • AD true is stronger than AD false because it means the followed resolver responses carried authenticated-data status. It still depends on trusting that resolver path.
  • NXDOMAIN means the queried owner name did not exist from that resolver view. NOERROR / no record means the owner existed, but the selected RR type was absent.
  • Alias without terminal record means a CNAME path was found, but no final SMIMEA or OPENPGPKEY answer appeared at the followed name.
  • Resolver agreement is most useful during publication changes. Different set digests, record counts, AD status, TTLs, or alias targets should pause a rollout decision until cache timing and authoritative DNS explain the difference.

For OPENPGPKEY, Payload SHA-256 is a digest of the DNS key blob returned in the answer. It helps compare resolver payloads, but it is not the OpenPGP fingerprint displayed by OpenPGP software. For SMIMEA, the association preview is only a compact display; compare the full association bytes before approving a publication change.

Do not treat a positive public resolver answer as the only trust proof. Check DNSSEC validation, the intended certificate or key material, recent TTL or negative-cache timing, and another resolver or authoritative path when the result affects user trust.

Technical Details:

SMIMEA and OPENPGPKEY owner names are deterministic DNS names derived from a mailbox. The domain stays readable as the DNS suffix, while the local part becomes a truncated SHA-256 label. The same prepared local part and domain produce the same owner name; a small change in quoting, Unicode form, plus tag, or dot placement can produce a completely different label.

The lookup follows the record family chosen by the user. SMIMEA uses a certificate-association record whose fields mirror TLSA-style usage, selector, and matching type. OPENPGPKEY uses a transferable public key blob. The DNS result also carries resolver metadata, including response code, TTL, optional negative-cache evidence, AD status, truncation status, elapsed time, answer digest, and any CNAME path followed before the final answer.

Transformation Core

SMIMEA and OPENPGPKEY owner-name construction
Stage Rule Review meaning
Mailbox extraction A plain mailbox or mailto: input is reduced to one local part and one domain. Invalid inputs stop before a DNS lookup, so the owner name is not guessed.
Local-part preparation Surrounding whitespace is trimmed; enclosing quotes are removed; quoted characters are unescaped; simple unquoted comments are removed; whitespace around dots is collapsed; non-ASCII text is normalized to NFC when available. These steps can change the hash label. Compare the prepared local part before editing zone data.
Domain preparation The domain is converted to ASCII host form and lowercased. IDN spelling and domain typos are visible in Owner Name Build.
Hash label SHA-256 of the prepared local part is truncated to the leftmost 28 octets and displayed as 56 hexadecimal characters. The full SHA-256 and truncated label are shown so publication can be audited.
Family suffix _smimecert for SMIMEA, or _openpgpkey for OPENPGPKEY. A correct hash with the wrong family suffix queries the wrong record family.

Lookup Core

Identity DNS lookup outcome rules
Outcome Decision rule Evidence to inspect
Record found One or more answers match RR type 53 for SMIMEA or RR type 61 for OPENPGPKEY. AD status, TTL, payload rows, owner name, set digest, alias chain, and resolver agreement.
Alias without terminal record A CNAME path is followed, but no requested-family record appears at the final name. Alias target, target zone contents, DNSSEC status, and whether the alias chain is expected.
NXDOMAIN The queried owner name does not exist from the resolver view used for the lookup. Prepared local part, truncated hash, family suffix, domain spelling, and negative-cache value.
NOERROR / no record The owner exists, but the requested RR type is not returned. Record family selection, zone data, TTLs, and recent publication timing.
Transport error The resolver request fails or exceeds the selected timeout. Retry, choose another resolver profile, or raise the timeout within the 1000 to 15000 ms range.

Resolver comparison uses canonicalized answer text to avoid treating harmless formatting differences as payload drift. When the canonical answer set is non-empty, a short digest is calculated from the sorted answer values. When no target record is present, the comparison signature comes from the outcome and response code instead.

Payload Rules

SMIMEA and OPENPGPKEY payload interpretation
Record family Payload fields Important interpretation limit
SMIMEA Certificate usage values 0 to 3, selector values 0 to 1, matching type values 0 to 2, then association bytes. Usage, selector, and matching type must match the certificate material recipients are expected to trust. Exact-match certificate data can be operationally large.
OPENPGPKEY A transferable public key blob, decoded from generic DNS hex or base64-style resolver text when possible. The displayed SHA-256 is over the DNS key blob, not the OpenPGP fingerprint shown by OpenPGP tooling.
DNSSEC evidence AD status is recorded from the followed resolver responses. AD false does not prove the data is false; AD true should still be trusted only when the recursive resolver path is acceptable for the decision.
Cache evidence Positive answers expose TTL where available; negative answers may expose an SOA-derived negative-cache estimate. Recent zone changes can remain invisible until recursive caches expire.

A CNAME path is followed for a short chain when the first answer does not contain the requested record type. The alias target should be held to the same signing, publication, and rollover discipline as the original owner name because recipients ultimately rely on the terminal DNS data.

Security and Privacy Notes:

Owner-name derivation and payload hashing happen in the browser before resolver evidence is requested. In derived mode, the selected public resolver receives the derived owner name, selected RR type, and normal DNS request context; the raw mailbox local part is not sent as the DNS question. The mailbox domain remains visible in the owner name.

  • Manual owner mode sends the exact owner name you enter to the selected resolver path.
  • Resolver comparison sends the same owner-name question to both supported public resolvers.
  • DNS-over-HTTPS encrypts transport to the resolver, but the resolver can still observe the query name, type, timing, and client network context.
  • Shared links, screenshots, browser history, copied tables, and downloaded reports may reveal the mailbox identity or owner name.
  • Trust-sensitive use should require DNSSEC validation and independent certificate or OpenPGP key verification, not only a positive DNS answer.

Worked Examples:

Checking an S/MIME Publication

Enter alice@example.com, choose SMIMEA, and keep Owner source on derived mode. Owner Name Build should show the _smimecert suffix, RR type 53, full SHA-256 value, and truncated hash label. If Identity DNS Brief reports Record found with AD true, compare the usage, selector, matching type, association size, and association preview with the certificate association you expected.

Watching an OpenPGP Rollover

Choose OPENPGPKEY, enable Compare public resolvers, and run the mailbox lookup. If Resolver Evidence shows different set digests or record counts, public resolver views differ for that run. Wait for TTL expiry or check authoritative DNS before deciding which key blob recipients are likely to see.

Debugging a Missing Owner

If derived mode returns NXDOMAIN, inspect Owner Name Build for the canonical local part, truncated hash label, family suffix, and lookup owner. A quoted local part, comment, Unicode character, delivery alias, or domain spelling change can place the expected record at a different owner name than the one being queried.

Narrowing a Manual-Owner Problem

Paste a complete owner name into Manual owner name. If manual mode returns NOERROR / no record, the owner exists but the selected RR type did not appear. If manual mode succeeds while derived mode fails, the mailbox-to-owner derivation is the part to investigate.

FAQ:

Why is the mailbox local part hashed?

The record families use a prepared, truncated SHA-256 label instead of placing the raw local part directly in DNS. Owner Name Build shows the prepared local part, full hash, truncated label, and final owner so publication mistakes are easier to find.

Is AD true required?

For trust-sensitive use, yes. AD true means the recursive resolver returned authenticated-data status for the followed lookup path. AD false should be checked with another trusted DNSSEC validation path before relying on the record.

Why does OPENPGPKEY show Payload SHA-256 instead of a fingerprint?

The displayed digest is computed over the DNS key blob returned by the resolver. It helps compare DNS payloads across resolvers or time, but it is not the OpenPGP fingerprint shown by OpenPGP software.

Can CNAME aliases be used?

The lookup follows a short CNAME path and reports the alias chain. Treat the final target with the same DNSSEC and publication discipline as the original owner name, and confirm the requested record family appears at the terminal name.

What should I check when no record is found?

Start with mailbox spelling, prepared local part, truncated hash label, family suffix, and domain. Then check TTL or negative-cache evidence before assuming a recent publication change should already be visible everywhere.

Glossary:

SMIMEA
A DNS record family for S/MIME certificate associations, queried as RR type 53 below _smimecert.
OPENPGPKEY
A DNS record family for OpenPGP transferable public key blobs, queried as RR type 61 below _openpgpkey.
Owner name
The full DNS name built from the truncated local-part hash, family label, and mailbox domain.
AD flag
The DNSSEC authenticated-data signal returned by a validating recursive resolver.
Negative cache
The time a resolver may keep an absence result such as NXDOMAIN or NOERROR with no requested record.
Set digest
A compact comparison value for the canonical answer set returned by one resolver during the lookup.