---
title: "TLSA Record Setup: Generate & Fix the 3 1 1 Hash"
description: "Generate a TLSA record with OpenSSL, publish it, then fix the common DANE 3 1 1 mismatch. Copy-paste commands plus a free TLSA record checker. Step by step."
publishedAt: 2026-07-30
tags: ["dane", "tlsa", "dnssec", "smtp", "openssl", "tls-rpt", "email-authentication"]
faq:
- question: "How do I generate a TLSA record with OpenSSL?"
answer: "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."
- question: "What does 3 1 1 mean in a TLSA record?"
answer: "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."
- question: "How do I check if my TLSA record is valid?"
answer: "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."
- question: "Why does my TLSA record keep mismatching after certificate renewal?"
answer: "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."
- question: "Should I use 3 1 1 or 2 1 1 for email?"
answer: "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."
---
# 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](/learn/dane/); 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](/blog/what-is-dane/) 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.
{/* TODO: create SVG at landing-page/public/images/blog/tlsa-record-setup/tlsa-record-setup_3-1-1-anatomy_diagram.svg — labeled breakdown of `3 1 1 ` per seo-conventions Blog SVG Diagrams. */}
## 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:
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](https://dane.sys4.de/common_mistakes).
Prefer not to run OpenSSL at all? Paste a certificate or hostname into our
[TLSA/DANE record generator](/tools/dane-generator/) and it computes the
`3 1 1` value for you, ready to publish.
{/* TODO: create SVG at landing-page/public/images/blog/tlsa-record-setup/tlsa-record-setup_openssl-pipeline_flowchart.svg — cert → pubkey → DER → SHA-256 → record per seo-conventions Blog SVG Diagrams. */}
## 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:
| Record | Pins | Use when | On renewal |
| ------- | ------------------------------- | --------------------------- | -------------------- |
| `3 1 1` | Leaf public key (SPKI), SHA-256 | Default for SMTP | Stable if key reused |
| `2 1 1` | Issuing-CA public key, SHA-256 | Pin the CA across rotations | Stable while same CA |
| `3 0 1` | Full leaf certificate, SHA-256 | Rare | Breaks every renewal |
The owner name always follows the same shape: `_25._tcp.` — 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.` 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.
1. **Pick the owner name per MX host.** For `mail.example.com` that is
`_25._tcp.mail.example.com`. Repeat for every MX hostname you run.
2. **Choose the record type.** Select `TLSA` if your panel offers it; if not,
use the generic `TYPE52` form, which is the same record under its numeric
name.
3. **Paste the value** `3 1 1 ` — three space-separated
fields followed by the digest from the OpenSSL step.
4. **Set a short-ish TTL** (300–3600 seconds). A lower TTL makes the
publish-before-swap rollover later in this guide propagate faster.
5. **Confirm DNSSEC is live.** Your zone must be signed and the DS record
present at your registrar. Without it, the TLSA is invisible to senders
(RFC 6698 §4).
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:
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](/tools/dane-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.
{/* TODO: create SVG at landing-page/public/images/blog/tlsa-record-setup/tlsa-record-setup_mismatch-decision-tree_flowchart.svg — mismatch root-cause decision tree per seo-conventions Blog SVG Diagrams. */}
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`](https://community.letsencrypt.org/t/tlsa-record-changes-with-every-renewal-process-which-breaks-dane/144145)
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](https://www.postfix.org/TLS_README.html)). **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](https://community.mailcow.email/d/3936-acme-post-renewal-hook-to-fix-tlsa-records-of-jumping-intermediate-certs)).
**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:
The order is the whole point. Add the next key's `3 1 1` hash while the old
certificate is still served, wait until the old TTL has fully expired in
caches, deploy the new chain, and only then remove the old record. The TTL
clock starts ticking only once the *last* secondary nameserver is serving the
update — not when you hit save. Swap the certificate first and you guarantee a
window where no published record matches the served key, which is a silent
inbound-mail outage for every DANE-validating sender.
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](https://techcommunity.microsoft.com/blog/exchange/announcing-general-availability-of-inbound-smtp-dane-with-dnssec-for-exchange-on/4281292)),
Proton Mail and Comcast all honor it — but
[Gmail and Google Workspace do not validate inbound DANE](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)
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](/blog/mta-sts-vs-dane/).
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](https://www.zivver.com/blog/use-of-email-security-standards-in-the-netherlands-september-2025-only-14-dane-6-mta-sts).
So a TLSA record is not set-and-forget — pair it with
[TLS-RPT to catch a silent mismatch](/learn/tls-rpt/) (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.` 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.