TLSA Record Setup: Generate & Fix the 3 1 1 Hash | DMARCguard Skip to main content<br>14 min read Share
How to Generate a TLSA Record and Fix the 3 1 1 Mismatch<br>A TLSA record pins your mail server’s TLS certificate in DNS so a sending server either reaches the right key over SMTP or refuses to deliver — and its most common form, 3 1 1, is the heart of DANE (DNS-Based Authentication of Named Entities, RFC 6698; for mail, RFC 7672). This guide shows you how to generate a TLSA record with OpenSSL, publish it, verify it resolves and validates, and fix the 3 1 1 mismatch that breaks most deployments. No theory — just the commands.<br>Who this is for: Postfix and Exim operators and Microsoft 365 admins adding inbound DANE, plus anyone whose dane tlsa 3 1 1 mismatch search landed them here. For what a TLSA record is and where DANE fits in the wider picture, see our DANE protocol guide; this post stays operational.<br>Key finding 30 of 5.5M scanned domains publish a DANE TLSA record (0.0%)<br>Source: DMARCguard, State of Email Authentication 2026 (February 2026) DANE is rare. But for SMTP it is the strongest transport-authentication option there is, and the reason so few domains publish a TLSA record is the DNSSEC prerequisite, not the record itself. If your zone is already signed, the work below takes about three commands and one DNS record.<br>What Does 3 1 1 Mean? DANE-EE, SPKI, and SHA-256<br>In a TLSA record, 3 1 1 is three numeric fields: certificate usage 3 (DANE-EE), selector 1 (the SubjectPublicKeyInfo — the public key, not the whole certificate), and matching type 1 (a SHA-256 hash). Together they tell a sending server one thing: this exact public key, hashed with SHA-256, is the only one my mail server will present (RFC 6698 §2.1.1–2.1.3).<br>Each field is a single octet on the wire:<br>Certificate usage (RFC 6698 §2.1.1) — 0 PKIX-TA, 1 PKIX-EE, 2 DANE-TA, 3 DANE-EE. For SMTP, only 2 and 3 are usable. Postfix treats usages 0 and 1 as unusable, and RFC 7672 §3.1.3 says SMTP TLSA records SHOULD NOT use PKIX-TA(0) or PKIX-EE(1) — there is no agreed-upon CA list across MTAs and no human present to click through a warning.<br>Selector (RFC 6698 §2.1.2) — 0 is the full certificate; 1 is the SubjectPublicKeyInfo (SPKI), the public key only. Selector 1 survives a certificate renewal as long as you reuse the same key pair.<br>Matching type (RFC 6698 §2.1.3) — 0 is an exact match of the selected data, 1 is its SHA-256 hash, 2 is SHA-512.<br>So 3 1 1 reads as “DANE-EE, SPKI, SHA-256.” RFC 7672 §3.1 names exactly this combination — DANE-EE(3) SPKI(1) SHA2-256(1) — as the primary recommendation for SMTP, because it pins the leaf public key, needs no CA, and explicitly ignores certificate expiry and hostname checks (§3.1.1, §3.1.3). The one alternative worth knowing is 2 1 1 (DANE-TA), which pins the issuing CA instead of the leaf — covered in the examples below.<br>How to Generate a TLSA Record with OpenSSL<br>To generate a 3 1 1 TLSA record, extract your certificate’s public key, convert it to DER, and SHA-256 hash it. The 64-character hex digest is the record’s third value:<br>Generate a 3 1 1 TLSA value with OpenSSL bash
# Generate a 3 1 1 TLSA value: DANE-EE (3) / SPKI (1) / SHA-256 (1).<br># Selector 1 hashes the public key (SubjectPublicKeyInfo), so the value<br># stays the same across renewals as long as you reuse the key pair.<br>openssl x509 -in cert.pem -noout -pubkey \<br>| openssl pkey -pubin -outform DER \<br>| openssl dgst -sha256 -binary \<br>| hexdump -ve '/1 "%02x"'; echo
# Output is the 64-character hex digest — the third field of the record:<br># 3 1 1 4e7098b757d837a9d782a1fe31057708ee4d2a71166e185f66009c488ed3632c
# Prefer not to manage the binary pipe? `openssl dgst -sha256` prints the<br># same hex after the "= " (the prefix differs across OpenSSL versions):<br># SHA2-256(stdin)= 4e7098b757d837...ed3632c<br>openssl x509 -in cert.pem -noout -pubkey \<br>| openssl pkey -pubin -outform DER \<br>| openssl dgst -sha256
# Selector-0 variant (3 0 1) hashes the WHOLE certificate, not the key, so<br># the value changes on every renewal even when the key is unchanged. Avoid<br># it for SMTP — it guarantees a mismatch at the next cert rollover.<br>openssl x509 -in cert.pem -outform DER \<br>| openssl dgst -sha256 -binary \<br>| hexdump -ve '/1 "%02x"'; echo
The first pipe (openssl x509 -noout -pubkey) pulls the SubjectPublicKeyInfo out of the certificate; openssl pkey -pubin -outform DER re-encodes it as the DER bytes the matching type hashes; openssl dgst -sha256 produces the digest. That is selector 1 — you are hashing the public key, so the value stays constant across renewals whenever you reuse the key.<br>Selector 0 is the trap. Hashing the whole certificate (openssl x509 -outform DER | openssl dgst -sha256, giving a 3 0 1 record) produces a value that changes on every renewal even if the key never moves — which is why selector 1 is the operational default. A second, related mistake is just as common: publishing selector 1 but computing the digest over the whole certificate. The record is...