domainsecuritycheck

← Record Studio

SMIMEA

SMIMEA records (RFC 8162) bind an S/MIME certificate or public key to an email address in DNS — the S/MIME counterpart of TLSA/DANE. A receiving mail client can then discover and verify your certificate straight from DNSSEC-signed DNS. Paste your S/MIME certificate and this generator computes the record locally in your browser.

DNSSEC is a prerequisite. Like DANE, SMIMEA is only trustworthy in a DNSSEC-signed zone: RFC 8162 §6 requires that “the DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than ‘Secure’ …, the DNSSEC validation MUST be treated as a failure”.
Experimental. RFC 8162 is an Experimental RFC — under RFC 2026 that places it outside the Standards Track. Publishing a record does no harm, but do not rely on every recipient acting on it yet. S/MIME itself is now specified by RFC 8551 (S/MIME 4.0).
Privacy. The record name contains a SHA-256 hash of the address’ local-part, so a published SMIMEA record reveals that the address exists and can be brute-forced for common local-parts. Sign the zone with NSEC3 rather than NSEC: RFC 8162 §9.2 notes that NSEC-signed zones are “susceptible to zone walking”, and that zones “using NSEC3 for denial of existence instead of NSEC are significantly harder to brute-force after performing a zone walk”. NSEC3 does not hide the records — it makes turning the enumerated hashes back into addresses harder. The domain part is deliberately not part of the hash, so one rainbow table works across domains (§9.2). The owner name is <hash>._smimecert.<domain>, where the hash is the SHA-256 of the canonicalized local-part truncated to 28 octets; the local-part’s case is preserved.

Reads any SMIMEA record already published for this address (the local-part is hashed in your browser first). No certificate is fetched — S/MIME certificates are not served over a TLS handshake.

The full address. Its local-part (left of the @) is hashed to form the record name; RFC 8162 §3 defines no case mapping, and §4 forbids senders from applying one (“sending MUAs and MTAs … MUST NOT perform any kind of mapping rules based on the email address”). The record is therefore found only for the exact spelling you enter — John.Smith@…, john.smith@… and johnsmith@… are three different owner names, and §4 notes that “some current implementations are known to lowercase at least US-ASCII local-parts”. If your mail system treats variants as equivalent (case, dots, +ext), RFC 8162 §4 leaves it to you to publish a record per variant you want to be reachable under; publishing the all-lower-case form as well is the cheapest insurance.

Paste your S/MIME (email) certificate. For a trust-anchor usage (DANE-TA 2 / PKIX-TA 0), also paste the issuer certificate as a second block — the issuer is pinned then.

Same registry as TLSA (RFC 6698). DANE (2/3) makes the DNSSEC-signed record the trust anchor, so a self-signed or privately issued certificate works; PKIX (0/1) additionally requires a public-CA chain. For publishing your own S/MIME certificate, DANE-EE (3) is the natural choice. One rule SMIMEA does not inherit from TLSA: RFC 8162 §9 requires that a revoked or expired S/MIME certificate “MUST NOT be used, even if that would result in sending a message in plaintext” — unlike DANE-EE (3) under TLSA, where RFC 7671 §5.1 has clients ignore the expiry date. Renew the certificate and republish the record before it expires.

The default 3 0 0 publishes your entire certificate in DNS — that is the point of SMIMEA discovery: a sender can fetch your certificate and encrypt to you without already having it. A hash (e.g. 3 1 1) only lets a client verify a certificate it already holds. Full-certificate records are large, so make sure your DNS answers over TCP/EDNS.

Records are built in your browser; “Load current record” has our server look up your domain’s DNS. Record Studio · Verify the result with the domain security check