TLSA Record Setup: Generate & Fix the 3 1 1 Hash

14 min read How to Generate a TLSA Record and Fix the 3 1 1 Mismatch 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. 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. Key finding 30 of 5.5M scanned domains publish a DANE TLSA record (0.0%) 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. What Does 3 1 1 Mean? DANE-EE, SPKI, and SHA-256 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). Each field is a single octet on the wire: 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. 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. 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. 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.