DANE（TLSA レコード）は、DNSSEC で署名されたゾーンに置いて初めて効力を持ちます。署名がなければ送信側は TLSA を無視し、署名が壊れていれば送信側は配送を保留します。つまり「DNSSEC を正しく動かし続けること」が DANE の運用そのものです。この記事では、メールサーバー（SMTP）で DANE を使う場合を例に、DNSSEC 側の前提の確かめ方、TLSA の公開、両方がそろっているかの確認、そして DNSSEC の作業（鍵の更新や DNS 事業者の移行）で DANE を巻き込まないための順番を説明します。
TLSA の値の選び方や、証明書の更新に合わせた TLSA の入れ替えは別の記事で扱います。ここでは DNSSEC と DANE の「つなぎ目」に焦点を当てます。
DANE に DNSSEC が要る理由
TLSA レコードは「このホストのポート 25 では、この公開鍵（または証明書）を使う」と宣言するものです。DNS の応答が改ざんされれば、攻撃者は TLSA を書き換えたり消したりできます。そこで DANE は、DNSSEC の検証に成功した TLSA だけを信用する仕組みになっています。SMTP での DANE を定めた RFC 7672 の考え方を、運用者の目線でまとめると次のようになります。
- 検証に成功（secure）した TLSA がある。 送信側は TLS を必須にし、相手の証明書が TLSA と一致しなければ送りません。
- ゾーンが署名されていない（insecure）。 TLSA があっても使われず、従来どおりの「使えれば TLS」の配送になります。
- 署名の検証に失敗（bogus）。 送信側は配送を保留し、再送を繰り返します。DANE を使っていない送信側でも、検証するリゾルバーを使っていれば名前解決自体が失敗します。
3つ目が運用上いちばん怖い状態です。DANE を入れると、DNSSEC の失敗がそのままメールの遅延として表に出ます。
署名されている必要がある範囲
受信ドメインが example.com、MX が mx1.example.net の場合、DANE が働くには次の応答がすべて secure である必要があります。
example.comの MX レコードmx1.example.netの A／AAAA レコード_25._tcp.mx1.example.netの TLSA レコード
MX が別ドメインにある構成では、両方のゾーンに DNSSEC が必要です。MX が secure でない場合、送信側はその先の TLSA を見に行きません。自社ドメインだけ署名して、MX を置いている事業者側のゾーンが未署名、という構成では DANE は働かないので、最初に確認しておきます。
手順1：DNSSEC が正しく動いているかを確かめる
DANE を足す前に、DNSSEC が健全であることを確かめます。ここで問題が見つかった場合は、TLSA を公開する前に直します。
# 親ゾーンに DS があるか（レジストラ経由で登録したもの）
dig +short DS example.com
# ゾーンの DNSKEY と署名
dig +dnssec +multi DNSKEY example.com
# 検証するリゾルバーで ad フラグが立つか
dig @1.1.1.1 +dnssec MX example.com | grep -E 'flags:|status:'
# 手元で検証の過程を確かめる（BIND の delv）
delv MX example.com見るべき点は3つです。DS が返ってくること、検証するリゾルバーへの問い合わせで flags: に ad が含まれ status: NOERROR であること、delv の出力に ; fully validated と表示されることです。DS がないなら、ゾーンは署名されていても insecure 扱いです。ad が立たず SERVFAIL になるなら bogus の可能性が高く、DS と DNSKEY の不一致や署名の期限切れを疑います。DNSViz のような可視化ツールで、親から子への信頼の連鎖がどこで切れているかを見ると原因を絞りやすくなります。
また、使っている DNS 事業者が TLSA レコードを登録できるかもこの段階で確かめます。DNSSEC の署名に対応していても、TLSA のレコード種別を扱えないサービスがあり、対応状況は事業者ごとに異なります（2026年10月現在）。
手順2：TLSA の値を作って公開する
受信側のメールサーバーの証明書から、TLSA の値を作ります。ここでは、一般に推奨される「3 1 1」（DANE-EE、公開鍵、SHA-256）を使います。証明書ではなく公開鍵に結びつけるため、同じ鍵のまま証明書を更新する限り、TLSA を変えずに済みます。
# サーバー証明書の公開鍵の SHA-256（16進）
openssl x509 -in /etc/letsencrypt/live/mx1.example.net/cert.pem -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 \
| awk '{print $NF}'出力された16進文字列を、次の形で DNS に登録します。
_25._tcp.mx1.example.net. 3600 IN TLSA 3 1 1 （上で得た16進文字列）名前の先頭は、ポート番号とプロトコルです。SMTP の受信は 25 番なので _25._tcp になり、付ける場所は受信ドメインではなく MX のホスト名です。ここを _25._tcp.example.com にしてしまう誤りがよくあります。
TTL は、DNSSEC の署名の有効期間より十分短くしておきます。TLSA を入れ替えるときは「新旧の値を並べて TTL 分待つ」流れになるため、極端に長い TTL は作業を遅らせます。逆に短すぎると問い合わせが増えるので、数時間程度から始めるのが扱いやすいでしょう。
手順3：TLSA が署名つきで返るかを確かめる
登録した TLSA が、署名とともに返ってくるかを確かめます。
# RRSIG が一緒に返るか
dig +dnssec TLSA _25._tcp.mx1.example.net
# 検証するリゾルバー経由で ad フラグが立つか
dig @1.1.1.1 +dnssec TLSA _25._tcp.mx1.example.net | grep -E 'flags:|status:'ANSWER SECTION に TLSA と RRSIG が並び、ad が立っていれば DNSSEC 側は問題ありません。RRSIG が出てこない場合、DNS 事業者がそのレコード種別を署名していないか、手動署名のゾーンで再署名を忘れています。BIND などでゾーンを自前で署名している場合は、レコードを足したあとに再署名とゾーンの再読み込みが必要です。
手順4：証明書と TLSA の一致を確かめる
DNS 側が正しくても、サーバーが提示する証明書と TLSA が一致しなければ、DANE に対応した送信側は配送を止めます。OpenSSL の s_client で、TLSA の値を与えて照合できます。
openssl s_client -connect mx1.example.net:25 -starttls smtp \
-servername mx1.example.net \
-dane_tlsa_domain mx1.example.net \
-dane_tlsa_rrdata "3 1 1 （TLSA の16進文字列）" </dev/null 2>/dev/null \
| grep -E 'Verification|DANE'一致していれば、照合に成功した旨と、どの TLSA が一致したかを示す行が出ます。Postfix を使っている環境なら、付属の posttls-finger で、DNS から TLSA を引いて照合する動きを再現できます。外部の検証サービスでメール受信側の DANE を調べる方法もありますが、どれもある時点の結果にすぎないため、定期的な確認と組み合わせて使います。
送信側でも DANE を使う場合（Postfix の例）
自社のサーバーから送るメールで相手の TLSA を検証したい場合は、送信側の設定が必要です。Postfix では main.cf に次の2行を足します。
smtp_dns_support_level = dnssec
smtp_tls_security_level = danePostfix は自分で DNSSEC を検証せず、リゾルバーが返す ad フラグを信用します。そのため、/etc/resolv.conf が指すリゾルバーは、同じホスト上で動く検証リゾルバー（127.0.0.1 の Unbound など）にしておきます。ネットワーク越しのリゾルバーの ad フラグは途中で書き換えられるおそれがあるからです。設定を変える前に main.cf のバックアップを取り、反映は postfix check のあとに postfix reload で行います。
DNSSEC の作業で DANE を壊さない順番
DANE を入れたあとは、DNSSEC の作業がメール配送に直結します。特に注意が必要な3つの場面を挙げます。
鍵の更新（ZSK・KSK のロールオーバー）
DNS 事業者が自動で署名している場合は、事業者に任せられます。自前で署名している場合、KSK を更新するときは新しい DS を親ゾーンに登録し、古い DS の TTL が切れるまで古い KSK を残す、という順番を守ります。ここで手順を誤ると、ゾーン全体が bogus になり、DANE 対応の送信側からのメールが止まります。作業前に delv と DNSViz で現状を記録し、作業後にもう一度確かめます。
DNS 事業者の移行
署名したまま DNS 事業者を移る方法はありますが、手順が複雑です。分かりやすいのは、いったん insecure に戻してから移る方法です。
- レジストラで DS を削除する
- 親ゾーンの DS の TTL が切れるまで待つ（この間、DANE は使われなくなり、配送は従来の TLS に戻る）
- 新しい事業者へ NS を切り替え、新しい事業者で署名を有効にする
- 新しい DNSKEY が公開されたことを確かめてから、新しい DS を登録する
- 手順1と手順3の確認を繰り返す
順番を逆にして、DS を残したまま署名を止めたり NS を切り替えたりすると bogus になります。TLSA を含むすべてのレコードを、新しい事業者に移し忘れていないかも確かめます。
署名の期限切れ
自前署名で再署名の自動化が止まると、RRSIG の期限が切れた時点で bogus になります。RRSIG の有効期限（dig +dnssec の出力にある日時）を監視対象に加えておくと、メールが止まる前に気づけます。
まとめ
- DANE は、DNSSEC で検証に成功した TLSA だけを使います。未署名なら無視され、検証に失敗すれば配送が保留されます。
- MX、MX ホストのアドレス、TLSA のすべてが secure である必要があります。MX を別ドメインに置いている場合は、そちらのゾーンの署名も確かめます。
- TLSA は
_25._tcp.MXホスト名に「3 1 1」で置き、dig +dnssecで署名つきで返ること、openssl s_client -dane_tlsa_rrdataで証明書と一致することを確かめます。 - 送信側で DANE を使うなら、Postfix の
smtp_tls_security_level = daneと、同じホスト上の検証リゾルバーを組み合わせます。 - DNSSEC の鍵更新や DNS 事業者の移行は、DS の追加と削除の順番を守って進め、作業の前後で検証結果を記録します。