DANE が動作しないときの原因は、多い順に「証明書の更新で TLSA レコードと鍵が合わなくなった」「ゾーンの DNSSEC が正しく有効になっていない」「TLSA の名前やパラメーターの書き間違い」「送信側が DANE を検証する設定になっていない」の4つにほぼ集約されます。この記事では、DANE が現実に使われているメール（SMTP）を中心に、ログや症状の読み方と、原因ごとの確認コマンドと直し方を説明します。
まず確認したいこと: DANE は何に効くのか
DANE は、TLS サーバーの証明書や公開鍵の情報を DNS の TLSA レコードに載せ、DNSSEC の署名でその内容を保証する仕組みです（RFC 6698、SMTP での使い方は RFC 7672）。
現在 DANE が実際に検証されているのは、主にメールサーバー間の SMTP です。Postfix などの送信側メールサーバーが、宛先の MX ホストの TLSA を確認して、STARTTLS の相手が正しいサーバーかを確かめます。一方、主要なブラウザは HTTPS で DANE を検証していません（2026年10月現在）。WordPress サイトのために _443._tcp.www.example.com へ TLSA を登録しても、ブラウザの動作は変わりません。「設定したのに何も起きない」という相談のかなりの部分はこれが理由です。
以下は、メールの DANE を前提に進めます。
症状とログの読み方
DANE の問題は、自分が「受信側（TLSA を公開している）」か「送信側（TLSA を検証する）」かで現れ方が違います。
- 受信側の TLSA が間違っている場合。 DANE を検証する送信サーバーからのメールが届かなくなり、送信側で保留（deferred）になります。送信元に返る不達通知や、送信側のログに
Server certificate not verifiedのような理由が残ります。DANE を検証しない送信元からは普通に届くため、「一部の相手からだけ届かない」という症状になります。 - 受信側の DNSSEC が有効でない場合。 TLSA があっても送信側は DANE を使わず、通常の暗号化（相手を検証しない STARTTLS）で配送します。メールは届くため、気付きにくい状態です。
- 送信側（自分の Postfix）が DANE を検証していない場合。 ログに
Verified TLS connection establishedではなくUntrusted TLS connection establishedなどが出ます。
Postfix のログは /var/log/mail.log（または journalctl -u postfix）で見られます。宛先ドメインで絞って、TLS の接続結果の行を探します。
sudo grep -E "TLS connection established|TLSA|certificate not verified" /var/log/mail.log | tail -n 50TLSA lookup error のようなメッセージが出ている場合は、TLSA の問い合わせ自体が失敗（SERVFAIL など）しています。この場合、送信側は安全側に倒してメールを保留します。
原因1: 証明書の更新で TLSA と合わなくなった
もっとも多い原因です。Let's Encrypt などで証明書を自動更新すると、設定によっては更新のたびに新しい秘密鍵が作られます。TLSA に公開鍵のハッシュ（3 1 1 など）を載せている場合、鍵が変わった時点で TLSA と一致しなくなります。
確認方法
実際にサーバーが提示している証明書から、公開鍵の SHA-256 ハッシュを計算し、DNS の TLSA と比べます。
# サーバーが提示している証明書の公開鍵ハッシュ（3 1 1 の値に相当）
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -pubkey \
| openssl pkey -pubin -outform DER \
| sha256sum
# DNS に登録されている TLSA
dig +short _25._tcp.mail.example.com TLSAOpenSSL には DANE の照合機能もあるので、登録値で検証が通るかを直接試せます。
openssl s_client -starttls smtp -connect mail.example.com:25 \
-dane_tlsa_domain mail.example.com \
-dane_tlsa_rrdata "3 1 1 TLSA_HEX_VALUE" \
-verify_return_error </dev/null一致すれば、出力に検証成功と、どの TLSA が一致したかが表示されます。
直し方
まず TLSA を現在の鍵に合わせて修正し、送信側の再送を待ちます。再発を防ぐには、鍵の更新を TLSA の更新と連動させます。
- 普段は certbot の
--reuse-keyなどで同じ鍵を使い続ける設定にする。 - 鍵を変えるときは、先に新しい鍵のハッシュを TLSA に追加し、現在の TLSA と新しい TLSA を並べて公開する。
- TLSA の TTL の2倍程度以上待ってから、新しい鍵の証明書に切り替える。
- 切り替えが確認できたら、古い TLSA を削除する。
3 1 1（サーバー証明書の公開鍵のハッシュ）は証明書を更新しても鍵が同じなら値が変わらないため、運用しやすい形式です。3 0 1（証明書全体のハッシュ）は更新のたびに値が変わるので、自動更新と組み合わせると今回の問題を起こしやすくなります。
原因2: DNSSEC の信頼の連鎖が切れている
TLSA は DNSSEC で検証できて初めて意味を持ちます。送信側が見るのは、宛先ドメインの MX レコードと、MX ホスト名の TLSA レコードの両方です。どちらかが「署名されていない（insecure）」と判定されると、DANE は適用されません。
確認方法
DNSSEC を検証するリゾルバーに問い合わせ、応答の flags に ad が付くかを見ます。
dig +dnssec example.com MX
dig +dnssec +multi _25._tcp.mail.example.com TLSAad が付かない場合は、DNSViz で該当の名前を解析し、DS レコードが親ゾーンに登録されているか、署名の期限が切れていないかを確認します。よくあるのは次のケースです。
- 宛先ドメインは署名済みだが、MX ホストが別のドメイン（例: レンタルサーバーやメールサービスのホスト名）で、そちらが署名されていない。この場合、TLSA はそのホスト名のゾーンに置く必要があり、自分では対応できないこともあります。
- DNS 事業者を移転したときに DS を更新し忘れ、検証に失敗している。
- 存在しない TLSA を問い合わせたときの「存在しないことの証明」を DNS 事業者が正しく返さず、SERVFAIL になる。先ほどの
TLSA lookup errorはこのケースでも出ます。
原因3: TLSA の名前やパラメーターの書き間違い
名前
TLSA は _ポート番号._tcp.ホスト名 に置きます。SMTP なら _25._tcp. に MX レコードが指すホスト名 を続けます。ドメイン名そのもの（_25._tcp.example.com）に置いても、MX が mail.example.com なら参照されません。
DNS 事業者の管理画面によっては、ホスト名の欄にゾーン名を自動で補うため、_25._tcp.mail.example.com.example.com のように重複していることがあります。dig で実際の名前を引いて確認します。
パラメーター
TLSA の3つの数字は、順に「証明書の使い方（usage）」「何をハッシュするか（selector）」「ハッシュの種類（matching type）」です。
- SMTP では、usage は
3（DANE-EE: サーバー証明書そのもの）か2（DANE-TA: 自分で指定した CA）を使います。0と1は SMTP の DANE では使わないことになっています。 - usage
2を使う場合、メールサーバーは指定した CA の証明書をチェーンに含めて送る必要があります。中間証明書の設定漏れで失敗することがあります。 - 値の16進数に余分な空白や改行が入っていないか、ハッシュの種類（
1は SHA-256）と値の長さが合っているかも見ます。
原因4: 送信側が DANE を検証していない
自分のメールサーバーから送るときに DANE を使いたい場合は、送信側の設定を確認します。Postfix では次の2つが基本です。
# /etc/postfix/main.cf（例）
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane変更前に main.cf をバックアップし、postfix check で確認してから systemctl reload postfix で反映します。
この設定だけでは足りないことがあります。Postfix は OS のリゾルバーから返る ad フラグを見て検証済みかを判断するため、DNSSEC を検証するリゾルバーを使っている必要があります。Postfix のドキュメントでは、同じサーバー上（127.0.0.1）で検証するリゾルバーを動かす構成が推奨されています。
また、glibc 2.31 以降では、/etc/resolv.conf に options trust-ad がないと、アプリケーションに渡す応答から ad フラグが外されます。ローカルの Unbound を使っている場合は、次のようになっているかを確認します。
nameserver 127.0.0.1
options trust-adresolv.conf が自動生成される環境では、直接書き換えても元に戻ることがあるため、生成元（systemd-resolved や NetworkManager など）の設定で対応します。
設定できたら、Postfix に付属する posttls-finger で、DANE を使って接続できるかを試します。
posttls-finger -t 30 -l dane example.com出力に Verified TLS connection established が出れば、DANE による検証で接続できています。
変更後の確認と外部ツール
修正したら、TLSA と DNSSEC の両方を外部からも確認します。
- DNSViz: 信頼の連鎖と TLSA の署名状態を図で確認できます。
- internet.nl: メールのテストで DANE の有無と一致を確認できます。
TLSA を修正しても、送信側のキャッシュに古い値が残っている間は結果が変わりません。TLSA の TTL を確認し、その時間が過ぎてから再確認します。
まとめ
- 主要なブラウザは HTTPS で DANE を検証しないため、DANE の確認はメール（SMTP）で行います。
- もっとも多い原因は証明書更新による鍵の変更です。サーバーの公開鍵ハッシュを計算して TLSA と比べ、鍵を変えるときは新旧の TLSA を並べて公開してから切り替えます。
- MX と TLSA の両方が DNSSEC で検証できる（
adが付く）か、MX ホストのゾーンが署名されているかを確認します。 - TLSA の名前は
_25._tcp.MXホスト名、SMTP の usage は3か2を使います。 - 送信側の Postfix は
smtp_tls_security_level = daneと DNSSEC を検証するリゾルバー、options trust-adがそろって初めて DANE を使えます。