Skip to content
Control Plane Labs
Search

OPENPGPKEY record

Publishes an OpenPGP public key for an email address at a DNS-derived owner name for automated key discovery.

Written and maintained by Ben Ennis

Last reviewed July 27, 2026 · How we verify this

Zone-file example

b5b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6._openpgpkey.example.com. 3600 IN OPENPGPKEY mQIN...

Typical uses

  • Discovering an OpenPGP public key for a mailbox under a domain the operator controls
  • Bootstrapping encrypted mail without relying on a centralized public-key directory
  • Publishing a key through DNSSEC-protected infrastructure for clients that support the profile
  • Automating key rotation while keeping the mailbox-to-key lookup name stable

When it breaks, check

  • The owner name is the lowercase SHA-256 digest of the mailbox local part below _openpgpkey
  • The RDATA is base64-encoded OpenPGP key material and must not be wrapped with zone-file comments
  • DNS publication is discovery, not proof of identity unless the client validates the DNSSEC and profile policy
  • Large keys can exceed comfortable DNS response sizes; test authoritative and recursive responses

What the OPENPGPKEY record does

The record creates a DNS namespace for OpenPGP keys without putting the address itself in a query name. For an address such as alice@example.com, the client canonicalizes the local part according to the profile, computes its SHA-256 digest, and queries the digest below _openpgpkey.example.com. The answer contains an ASCII-armored key’s binary form encoded as base64 in the OPENPGPKEY RDATA.

The indirection is a privacy and compatibility choice: the zone does not need a readable mailbox label, and DNS providers can serve the key through ordinary authoritative servers. It does not turn DNS into a trust anchor by itself. Key validity, revocation, fingerprints, and DNSSEC status remain separate checks that the mail client must perform.

Zone-file and wire format

The RDATA is the base64-encoded OpenPGP public key packet. The owner name has the form <sha256-local-part>._openpgpkey.<domain>, with the digest rendered as lowercase hexadecimal. The domain part is not included in the digest. Publish one or more records only when the consuming profile defines how to handle key material and rotation.

; the digest below is illustrative, not a real mailbox hash
b5b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6._openpgpkey.example.com. 3600 IN OPENPGPKEY \\
  mQINBG...base64-key-data...

Common uses

OPENPGPKEY suits domains that want a standards-based, decentralized discovery path for encrypted mail. It can sit beside a web key directory, support managed mailboxes, and reduce manual key exchange for clients that implement the profile. It does not replace TXT policy records or DMARC alignment, and it is not a certificate record. Use the DNS lookup tool to inspect the wire response, then validate the decoded key in an OpenPGP-capable client.

Troubleshooting

Compute the owner name with a tested implementation rather than copying the visible mailbox into a DNS console. Confirm the local-part normalization, lowercase hexadecimal digest, and trailing zone dot. Query with DNSSEC enabled and inspect the response size; a truncated UDP answer should retry over TCP, not be treated as NXDOMAIN.

If the client finds a key but refuses it, compare the returned fingerprint and expiration against the user’s verified key record. A stale key can remain cached until its TTL expires, while a missing DNSSEC chain can make a correct-looking answer untrusted.

# The owner is the lowercase SHA-256 digest of the local part.
dig <sha256-local-part>._openpgpkey.example.com OPENPGPKEY +dnssec +noall +answer

# Retry over TCP if the response is truncated.
dig +tcp <sha256-local-part>._openpgpkey.example.com OPENPGPKEY +noall +answer

The defining RFC

OPENPGPKEY is DNS type 61, defined by RFC 7929. The RFC specifies the hashed owner name, the base64 wire representation, and the requirement that clients use DNSSEC validation before treating the record as an authenticated binding. Key discovery is not the same as key trust: OpenPGP clients still need normal fingerprint, expiration, and revocation handling. The DNS lookup tool is useful for checking the record but does not validate the OpenPGP key’s social trust.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types