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.

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.

How to Generate a TLSA Record with OpenSSL

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:

# Generate a 3 1 1 TLSA value: DANE-EE (3) / SPKI (1) / SHA-256 (1).
# Selector 1 hashes the public key (SubjectPublicKeyInfo), so the value
# stays the same across renewals as long as you reuse the key pair.
openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | hexdump -ve '/1 "%02x"'; echo

# Output is the 64-character hex digest — the third field of the record:
#   3 1 1 4e7098b757d837a9d782a1fe31057708ee4d2a71166e185f66009c488ed3632c

# Prefer not to manage the binary pipe? `openssl dgst -sha256` prints the
# same hex after the "= " (the prefix differs across OpenSSL versions):
#   SHA2-256(stdin)= 4e7098b757d837...ed3632c
openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

# Selector-0 variant (3 0 1) hashes the WHOLE certificate, not the key, so
# the value changes on every renewal even when the key is unchanged. Avoid
# it for SMTP — it guarantees a mismatch at the next cert rollover.
openssl x509 -in cert.pem -outform DER \
  | openssl dgst -sha256 -binary \
  | 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.

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 syntactically valid and will never match, a top error documented by the DANE SMTP Validator’s “Common Mistakes” list.

Prefer not to run OpenSSL at all? Paste a certificate or hostname into our TLSA/DANE record generator and it computes the 3 1 1 value for you, ready to publish.

TLSA Record Examples: 3 1 1 vs 2 1 1 vs 3 0 1

Use 3 1 1 for almost all SMTP mail: it pins the leaf public key and survives certificate renewal if you reuse the key. Use 2 1 1 only when you must pin the issuing CA across leaf rotations; avoid 3 0 1, because the full-cert hash changes on every renewal. Here are all three as live records:

; Owner name format: _<port>._<protocol>.<MX-hostname>
; For MTA-to-MTA mail this is always port 25 over TCP (RFC 7672 §2.1):
;   _25._tcp.<each-MX-hostname>

; 3 1 1 — DANE-EE / SPKI / SHA-256. The recommended SMTP record (RFC 7672 §3.1).
; Pins the leaf public key; stays valid across renewal if you reuse the key.
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
    4e7098b757d837a9d782a1fe31057708ee4d2a71166e185f66009c488ed3632c )

; 2 1 1 — DANE-TA / SPKI / SHA-256. Pins the issuing CA's public key, so it
; keeps validating across leaf rotations as long as the same CA signs.
; (RFC 7672 §3.1 names DANE-TA(2) as the second choice; its own example uses
;  the 2 0 1 full-cert form.) The issuing CA cert MUST be in the served chain.
_25._tcp.mail.example.com. IN TLSA 2 1 1 (
    1f2e3d4c5b6a79880192a3b4c5d6e7f80a1b2c3d4e5f60718293a4b5c6d7e8f90 )

; 3 0 1 — DANE-EE / full cert / SHA-256. Hashes the entire certificate, so it
; breaks on every renewal. Rarely the right choice for mail.
_25._tcp.mail.example.com. IN TLSA 3 0 1 (
    af53b991cf4bceed4987aa6d7084b144ac8c84ba3d9c45128d652a97739bd74c0 )

The owner name always follows the same shape: _25._tcp.<MX hostname> — port 25, TCP, then the MX host that actually accepts mail (RFC 7672 §2.1). DANE binds to each MX host independently, not to the org domain, so a domain with two MX hosts needs a TLSA record under each. (RFC 7672 §3.1 lists DANE-TA(2) Cert(0) SHA2-256(1) — the 2 0 1 full-CA form — as its documented second choice; operators more often publish the 2 1 1 SPKI variant to pin just the CA’s key.)

How to Publish the TLSA Record at Your DNS Provider

Publish the record at the owner name _25._tcp.<your-mx-hostname> as record type TLSA (or generic type TYPE52 if your provider lacks a TLSA field), with the three fields and the hash as the value. The zone MUST be DNSSEC-signed and the DS record published at your registrar — otherwise validating senders ignore the record entirely.

DNSSEC is the hard prerequisite, not an optional extra. A TLSA record in an unsigned zone is treated as insecure and ignored (RFC 6698 §4); an expired RRSIG takes the whole zone bogus, so even A/AAAA and MX stop resolving. Sign the zone and publish the DS record before you publish the TLSA. Provider support varies — some registrars are slow to accept DS records for external nameservers, and some DNS panels only expose the generic TYPE52 form — so confirm both ends of the chain before you rely on the record.

How to Check and Validate Your TLSA Record

Verify a TLSA record with dig +dnssec TLSA _25._tcp.mail.example.com — confirm the record returns and that the ad (authenticated-data) flag is set, which proves the DNSSEC chain validated. Then confirm the record actually matches the served certificate before you enforce anything:

# Confirm the TLSA RRset resolves AND the DNSSEC chain validates.
# Senders ignore any TLSA that DNSSEC did not authenticate (RFC 6698 §4),
# so a record that "exists" but is unsigned protects nothing.
dig +dnssec TLSA _25._tcp.mail.example.com

# Check two things in the output:
#   1. The header carries the 'ad' (authenticated-data) flag —
#         ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...
#      'ad' means your resolver validated the signature.
#   2. An RRSIG TLSA record is returned alongside the TLSA answer.

# Then confirm the published hash matches the certificate your server
# actually serves, BEFORE you enforce. posttls-finger probes the live MX,
# negotiates STARTTLS, and logs which TLSA record matched. Use dane-only so
# a mismatch fails loudly. (It is an unsupported Postfix test program.)
posttls-finger -l dane-only example.com

The ad flag is the part operators miss. A record can resolve perfectly and still be worthless if it is unsigned — conforming MTAs ignore any TLSA that DNSSEC did not authenticate (RFC 6698 §4). posttls-finger -l dane-only goes one step further: it connects to the live MX, negotiates STARTTLS, and logs which TLSA record matched, so you confirm the hash matches the served certificate before you commit. It is an unsupported Postfix test program, but it is the canonical pre-deploy check.

If you would rather not assemble the commands, run your mail host through our free DANE/TLSA checker — it resolves the record, validates the DNSSEC chain, and tells you whether the hash matches the live certificate.

How to Fix a TLSA 3 1 1 Mismatch

A TLSA 3 1 1 mismatch almost always means the published hash no longer equals the public key your server now presents — usually because a certificate renewal generated a new key. Fix it by re-generating the 3 1 1 hash from the live certificate, or prevent it by reusing the key (certbot --reuse-key) and always running two records — current plus next. Work through the causes in order; the first one accounts for most production failures.

1. A renewal generated a new key pair. This is the single most common cause. Certbot’s default renewal issues a fresh key each cycle, so a selector-1 hash stops matching the served leaf at the first renewal — often weeks after a clean deploy. Fix: re-hash the live certificate and republish, then switch renewals to certbot --reuse-key so the SPKI stays stable.
2. You hashed the wrong object. Publishing selector 1 but computing the digest over the whole certificate (or over a non-DER encoding) produces a valid-looking record that never matches. Fix: re-run the SPKI pipeline from the generate section — x509 -pubkey → pkey -pubin -outform DER → dgst -sha256.
3. The usage is unusable for SMTP. A 1 x x (PKIX-EE) record is treated as unusable by Postfix, which withdrew its silent 1→3 mapping in version 3.2 — so the record behaves as if no TLSA exists (Postfix TLS_README). Fix: use usage 3 (or 2).
4. An ACME intermediate “jumped.” Let’s Encrypt periodically rotates which intermediate signs your leaf (for example R10 ↔ R11), which breaks a 2 1 1 DANE-TA record even when the leaf key is unchanged (mailcow community, August 2024). Fix: publish a stable 3 1 1 leaf record, and if you also pin the CA, publish a 2 1 1 for every intermediate that can sign you.
5. The zone is not DNSSEC-signed, or the signature is broken. An unsigned zone makes the TLSA invisible; an expired RRSIG turns the zone bogus; and an NSEC3 “proof of non-existence” on the _tcp ancestor label can make a QNAME-minimizing resolver conclude the _25._tcp record does not exist. Fix: sign the zone, keep signatures fresh, and re-test with dig +dnssec.
6. The TTL has not flushed during a rollover. Activating the new certificate before the old TLSA record’s TTL expires leaves senders matching against a cached hash that no longer applies. Fix: use the publish-before-swap pattern below.

The prevention pattern is two records and patience. Publish the current and next 3 1 1 records together, leave both in place through the transition, deploy the new chain, then drop the old record — RFC 6698’s key-rollover guidance and RFC 7672’s deployment checklist (step 5) both put the new record in DNS before the new certificate goes live:

; Publish-before-swap rollover.
; RFC 6698 key-rollover guidance + RFC 7672 deployment checklist (step 5):
; publish the NEW TLSA record before deploying the new certificate, keep both
; records live through the transition, and remove the old one only after the
; old TTL has fully expired in caches.

; Step 1 — while the OLD certificate is still served, ADD the next key's hash
;          so the RRset carries both current and next:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash-of-CURRENT-key>
_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash-of-NEXT-key>

; Step 2 — wait until every secondary nameserver serves both records and the
;          old TTL has expired everywhere. The TTL clock only starts once the
;          LAST secondary nameserver is serving the update.

; Step 3 — deploy the new certificate / key on the mail server.

; Step 4 — once the new chain is live and verified, drop the old record:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash-of-NEXT-key>

One more caveat for larger setups: if a host presents more than one chain — say an RSA and an ECDSA certificate, or you run multiple MX hosts — a single 3 1 1 cannot match every chain a sender might negotiate. Provision a current-plus-next pair per algorithm and per MX host before you enforce. Then re-run the check from the previous section to confirm the fix landed.

Is DANE Right for Your Domain?

DANE only protects mail when both sides cooperate: your zone must be DNSSEC-signed, and the sending server must validate DANE. Postfix (built-in), Exim 4.91+ (built with SUPPORT_DANE=yes), Microsoft 365 / Exchange Online (inbound DANE GA in 2024, outbound since March 2022), Proton Mail and Comcast all honor it — but Gmail and Google Workspace do not validate inbound DANE and rely on MTA-STS instead. Publishing a TLSA record does not mean every sender checks it; if your senders are Gmail-hosted, deploy MTA-STS as well, and decide which to publish.

Adoption is real but fragile. Even in the highest-adoption market, the Netherlands, only about 14% of domains supported DANE in September 2025, and 33 regressed to no standard within two months. So a TLSA record is not set-and-forget — pair it with TLS-RPT to catch a silent mismatch (RFC 8460) before a renewal turns into lost mail.

FAQ

How do I generate a TLSA record with OpenSSL?

Pipe your certificate through three commands: openssl x509 -noout -pubkey, openssl pkey -pubin -outform DER, then openssl dgst -sha256. The 64-character hex digest becomes the third field of a 3 1 1 record. A generator tool produces the same value without OpenSSL.

What does 3 1 1 mean in a TLSA record?

Three fields: usage 3 (DANE-EE — pin this end-entity certificate), selector 1 (hash the public key, not the whole certificate), and matching type 1 (SHA-256). RFC 7672 names it the recommended configuration for SMTP DANE on port 25.

How do I check if my TLSA record is valid?

Run dig +dnssec TLSA _25._tcp.mail.example.com and confirm both the record and the ad (authenticated-data) flag appear, then check the hash matches the live certificate with a DANE checker or posttls-finger. An unsigned TLSA is ignored by senders.

Why does my TLSA record keep mismatching after certificate renewal?

Renewal usually generates a new key, so a selector-1 hash stops matching on the first renewal. Reuse the key with certbot --reuse-key and always publish two records — current plus next — so a renewal can never leave a zero-match record set.

Should I use 3 1 1 or 2 1 1 for email?

Use 3 1 1 for most SMTP mail — it pins your leaf public key and survives renewal when you reuse the key. Use 2 1 1 only to pin the issuing CA across leaf rotations; it breaks if the signing intermediate changes, as Let’s Encrypt’s does.

Conclusion

Generating a TLSA record is three commands; keeping it matching is the real work. The four moves are always the same:

• Generate the 3 1 1 hash from the SPKI, not the full certificate.
• Publish it at _25._tcp.<mx> in a DNSSEC-signed zone, with the DS record live at your registrar.
• Verify the ad flag and confirm the hash matches the served certificate before you enforce.
• Prevent mismatches with key reuse and a publish-before-swap rollover — two records, current and next, every time.

A TLSA record only protects mail when it matches the key your server actually serves. Check it the day you publish it, and check it again after every renewal.