DANE（DNS-Based Authentication of Named Entities）が動かない原因は、ほとんどが「TLSA レコードと実際の証明書が一致していない」か「TLSA レコードが DNSSEC で検証できていない」のどちらかです。特に証明書を自動更新した直後に TLSA が古いまま残り、DANE に対応した送信側のメールサーバーが配送を保留する、という形のトラブルがよく起こります。この記事では、メールサーバー（SMTP）での DANE を対象に、症状の見方、原因の順番、確認コマンドと直し方を説明します。
前提：DANE は主に SMTP で使われている
DANE は、DNS に置いた TLSA レコードで「このサーバーの正しい証明書（または公開鍵）はこれです」と宣言する仕組みです。TLSA レコードそのものが偽装されないように、DNSSEC での署名が前提になっています。
現在、実際に広く使われているのはメールサーバー間の通信（SMTP、RFC 7672）です。主要な Web ブラウザは HTTPS での DANE 検証に対応していないので、Web サイトの TLSA を設定しても閲覧者側の動作は変わりません。この記事も SMTP を前提に進めます。
SMTP の DANE で TLSA を置く場所は、ドメインそのものではなく MX レコードが指すメールサーバーのホスト名です。
; MX が mx1.example.com を指している場合
example.com. IN MX 10 mx1.example.com.
_25._tcp.mx1.example.com. IN TLSA 3 1 1 （公開鍵の SHA-256 ハッシュ）3 1 1 は「サーバー自身の証明書（3）の公開鍵部分（1）を SHA-256 でハッシュしたもの（1）」という意味で、SMTP では最もよく使われる組み合わせです。
症状の見え方
DANE が壊れたときに困るのは、受信側（TLSA を公開している側）です。DANE に対応した送信側のサーバーは、TLSA と証明書が一致しないと「なりすましの可能性がある」と判断して配送を保留し、再試行を繰り返します。送信側のログには、証明書の照合に失敗した旨のメッセージが残ります。DANE に対応していない送信元からのメールは普通に届くため、「特定の相手からのメールだけ遅れる、届かない」という症状になりがちです。
自分のサーバーが送信側として DANE を検証している場合（Postfix で smtp_tls_security_level = dane など）は、相手先の TLSA の不備で自分の送信が保留されることもあります。この場合はログで相手のホスト名を確認し、相手の管理者に知らせるのが基本です。
ステップ1：TLSA レコードが DNSSEC で検証されているか
TLSA があっても、ゾーンが DNSSEC で検証できなければ DANE は使われません（送信側は TLSA を無視するか、検証できない状態として扱います）。まず、検証するリゾルバに問い合わせて ad フラグを確認します。
# MX を確認する
dig example.com MX +short
# MX ホストの TLSA を、検証するリゾルバで引く
dig _25._tcp.mx1.example.com TLSA @1.1.1.1 +dnssecflags: に ad があり、ANSWER SECTION に TLSA が返れば合格です。ad が付かないなら、MX ホストのゾーンが署名されていない、または DS が親に登録されていません。MX ホストが別のドメイン（ホスティング事業者のドメインなど）にある場合は、そちらのゾーンが DNSSEC に対応している必要があります。SERVFAIL が返るなら DNSSEC 自体の検証失敗なので、先にそちらを直します。
ステップ2：TLSA の値と実際の証明書を照合する
次に、メールサーバーが実際に提示している証明書から公開鍵のハッシュを計算し、TLSA の値と比べます。
# サーバーが STARTTLS で提示する証明書を取り出す
openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com </dev/null 2>/dev/null \
| openssl x509 -outform PEM > live.pem
# 「3 1 1」用のハッシュ（公開鍵 → DER → SHA-256）を計算する
openssl x509 -in live.pem -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256出力された16進数の文字列が TLSA の最後の値と一致すれば正常です（大文字・小文字の違いは関係ありません）。一致しなければ、TLSA が古いか、サーバーが想定と違う証明書を提示しています。
Postfix を使っている場合は、付属の posttls-finger で送信側と同じ考え方の検証を試せます。posttls-finger -t30 -T180 -c -l dane example.com のように実行すると、TLSA の取得から証明書の照合までの結果が表示されます。オプションの詳細はお使いの版のマニュアルで確認してください。外部から一通り確認したい場合は、internet.nl のメールテストのように DANE の判定を含むサービスも使えます。
原因1：証明書の更新で鍵が変わった（最も多い）
3 1 1 は公開鍵に結びついているので、証明書を更新しても鍵が同じなら TLSA を変える必要はありません。問題は、更新のたびに新しい鍵を作る設定になっている場合です。Let's Encrypt の certbot は、既定では更新時に新しい鍵を作ります。
対処には2つの考え方があります。
- 鍵を再利用する：certbot の
--reuse-keyオプションのように、更新時に同じ鍵を使い続ける設定にします。TLSA の変更は鍵を意図的に替えるときだけで済みます。 - 次の鍵を先に公開する：現在の鍵と次に使う鍵の両方の TLSA を並べて公開しておき、TLSA の TTL が過ぎてから証明書を切り替えます。切り替え後、古い鍵の TLSA を外します。
いずれの場合も、「証明書を差し替えてから TLSA を直す」順番は避けます。新しい TLSA が DNS のキャッシュに行き渡る前に証明書が変わると、その間は照合に失敗します。
原因2：2 1 1（認証局の鍵を指定）で中間証明書が変わった
TLSA の先頭を 2（信頼の起点となる認証局）にして中間証明書の公開鍵を指定する方式は、サーバーの鍵を更新しても TLSA を変えずに済む利点があります。ただし、認証局が中間証明書を切り替えると一致しなくなります。Let's Encrypt のように、複数の中間証明書を使い分けたり、定期的に入れ替えたりする認証局もあります（2026年10月現在）。
この方式を使うなら、発行されうる中間証明書の候補をすべて TLSA に並べる、あるいは 3 1 1 と組み合わせて片方が外れても照合できるようにする、といった備えが要ります。サーバーが中間証明書をチェーンに含めて送っていないと、2 系の照合はできない点にも注意してください。
原因3：TLSA を置く名前やポートが違う
よくある設定ミスは次のとおりです。
- ドメインの頂点（
_25._tcp.example.com）に置いていて、MX が指すホスト名に置いていない - MX が複数あるのに、一部のホストにしか TLSA がない（その MX に配送されるときだけ照合が行われない、または失敗する）
- ポートが 25 ではなく 587 や 465 になっている（サーバー間の配送は 25 番です）
- MX が CNAME を指している（MX の値に CNAME を使うこと自体が規格上の誤りで、照合以前に問題を起こします）
dig example.com MX +short の結果すべてについて、_25._tcp.<ホスト名> の TLSA を確認してください。
原因4：STARTTLS が提供されていない・使用法 0 / 1 の TLSA
TLSA を公開しているのに、サーバーが STARTTLS を提供していないと、DANE に対応した送信側は配送を保留します。メールサーバーの設定変更で TLS を一時的に止めた場合などに起こります。openssl s_client -starttls smtp が TLS のハンドシェイクまで進むかを確認します。
また、TLSA の先頭（証明書の使用法）が 0 や 1 の場合、SMTP 向けの規格（RFC 7672）では公開しないことが推奨されており、送信側によっては使えないレコードとして扱われます。SMTP では 3 1 1 か 2 1 1 を使うのが一般的です。
変更作業の前に
TLSA を書き換える前に、現在のレコードと証明書、鍵のバックアップを取っておきます。秘密鍵はパーミッションを絞り、Web から見える場所や Git リポジトリに置かないでください。変更は TTL を意識して段階的に行い、作業後はステップ1・2のコマンドで照合結果を確認します。
まとめ
- SMTP の DANE は、MX が指すホストの
_25._tcpに置いた TLSA と、DNSSEC の検証が前提 - まず
dig +dnssecでadフラグと TLSA の有無を確認し、次に openssl で証明書のハッシュを照合する - 最も多い原因は、証明書の更新で鍵が変わったのに TLSA が古いままになっていること
- 鍵の再利用か、次の鍵の TLSA を先に公開する運用で、更新時の不一致を防げる
2 1 1を使う場合は中間証明書の入れ替えに備え、MX が複数あれば全ホストを確認する