2026年6月16日

DANE（TLSAレコード）の切り替え手順：証明書更新・鍵交換・MX移行を止めずに行う

DNS・名前解決

DANE の切り替えは「新しい TLSA レコードを先に足し、TTL が切れるのを待ってから証明書（または鍵・MXホスト）を替え、最後に古い TLSA を消す」という順番がすべてです。この順番を守れば、送信側のメールサーバーが一時的に配送を止める事態をほぼ避けられます。この記事では、メールサーバー（SMTP）の DANE を前提に、証明書の更新、鍵の交換、MX ホストの移行、DANE の取りやめという4つの切り替えを、確認コマンドとあわせて説明します。

DANE の切り替えで何が起きるのか

DANE（DNS-Based Authentication of Named Entities）は、TLS サーバーの証明書や公開鍵の指紋を DNSSEC で署名された TLSA レコードとして公開し、接続してくる側に照合させる仕組みです。現在実用されているのはほぼ SMTP（RFC 7672）で、主要なブラウザは HTTPS の DANE を検証しません。WordPress サイトとの関係でいえば、サイトと同じドメインで自前のメールサーバー（Postfix など）を運用している場合に関わってきます。

照合に失敗したときの動きが重要です。DANE に対応した送信側サーバーは、TLSA が公開されているのに証明書が一致しないと、平文に落とさず配送を保留します。つまり TLSA と実際の証明書がずれた瞬間から、そのドメイン宛てのメールが外部で滞留し始めます。切り替え作業の目的は、このずれが起きる時間帯を作らないことです。

前提の確認

作業前に次の2点を確かめます。

MX レコードを置くゾーンと、MX ホスト名のゾーンの両方が DNSSEC で署名され、親ゾーンに DS が登録されていること
現在の TLSA レコードの内容と TTL

# MX と TLSA を DNSSEC 付きで問い合わせ、応答の flags に ad が付くか見る
dig +dnssec example.com MX @1.1.1.1
dig +dnssec _25._tcp.mail.example.com TLSA @1.1.1.1

ad フラグは、問い合わせたリゾルバが DNSSEC の検証に成功したことを示します。付かない場合は、送信側から見て DANE が有効になっていない状態なので、まず DNSSEC 側を直します。TLSA の行に表示される数字（例: 3600）が TTL で、後の待ち時間の基準になります。

どの形式の TLSA を使うか

TLSA は「用途・セレクタ・照合方式」の3つの数字とハッシュ値で構成されます。SMTP では RFC 7671 と RFC 7672 の運用指針に沿って、次のどちらかを使うのが一般的です。

3 1 1（DANE-EE、公開鍵、SHA-256）: サーバー自身の公開鍵に一致させる方式。鍵を変えない限り、証明書を更新しても TLSA を変える必要がありません。
2 1 1（DANE-TA、公開鍵、SHA-256）: 発行元の中間 CA などの公開鍵に一致させる方式。CA 側が中間証明書を切り替えると一致しなくなります。

Let's Encrypt のように複数の中間証明書を使い分けたり、予告のうえで階層を更新したりする CA では、2 1 1 を中間証明書に向けると、自分は何もしていないのに照合が外れることがあります。特別な理由がなければ 3 1 1 をおすすめします。

ハッシュ値は証明書から次のように計算します。パスは環境に合わせて置き換えてください。

openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | sha256sum

出力された64桁の16進数が 3 1 1 の値です。

切り替え1：証明書の更新（鍵は同じ）

3 1 1 を使っていて鍵を使い回す設定なら、証明書の更新では TLSA を触る必要がありません。ここでつまずきやすいのは、ACME クライアントが更新のたびに新しい鍵を作る設定になっているケースです。certbot には既存の鍵を再利用する --reuse-key オプションがありますが、既定の挙動や設定ファイルでの書き方はバージョンで異なるため、利用中のバージョンの文書で確認してください（2026年10月現在）。

更新後に、実際に配信されている証明書の公開鍵ハッシュが TLSA と一致しているかを確かめる習慣をつけると、鍵が知らないうちに変わっていた事故を早く見つけられます。

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -dane_tlsa_domain mail.example.com \
  -dane_tlsa_rrdata "3 1 1 公開中のハッシュ値" </dev/null 2>/dev/null \
  | grep -E "Verification|DANE"

照合に成功すると、検証結果が OK になり、どの TLSA に一致したかが表示されます（表示の文言は OpenSSL のバージョンで多少異なります）。

切り替え2：鍵の交換（current + next 方式）

鍵を替えるときは、旧鍵と新鍵の両方に一致する TLSA を一時的に並べます。RFC 7671 で「current + next」と呼ばれるやり方です。

新しい鍵ペアを先に作り、その公開鍵からハッシュを計算する
既存の TLSA を残したまま、新鍵の TLSA を同じ名前に追加する
TLSA の TTL の2倍程度待ち、外部のリゾルバから両方の値が見えることを確認する
新しい鍵で発行した証明書に差し替え、メールサーバーを再読み込みする
送信側から新しい証明書で照合が通ることを確認してから、旧鍵の TLSA を削除する

# 1. 新しい鍵を作ってハッシュを計算する（例: ECDSA P-256）
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out next.key
openssl pkey -in next.key -pubout -outform DER | sha256sum

; 2. 移行期間中のゾーン（値はダミー）
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 aaaa...（現在の鍵）
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 bbbb...（次の鍵）

手順3で待つのは、送信側のリゾルバが古い TLSA だけをキャッシュしている間に証明書を替えると、そのリゾルバ経由の送信が照合に失敗するためです。手順4で使う「事前に作った鍵で証明書を発行する」方法は ACME クライアントごとに異なります（CSR を渡して発行する方式など）。手順を決めたら、まずステージング用の CA や検証用ドメインで試してください。

切り替え3：MX ホストの移行

TLSA は MX ホスト名ごとに _25._tcp.<MXホスト名> に置きます。新しいメールサーバー mx2.example.com へ移る場合の順番は次のとおりです。

新サーバーで証明書を用意し、_25._tcp.mx2.example.com に TLSA を公開する
新サーバー単体で openssl s_client による照合が通ることを確認する
MX レコードに新サーバーを追加（または優先度を変更）する
旧サーバーへの配送がなくなったことをログで確認してから、旧 MX と旧 TLSA を削除する

MX を先に向けて TLSA を後から足すと、その間に届いたメールは照合できずに保留されます。外部のメールホスティングへ移る場合は、移行先が DANE に対応しているか、TLSA を誰が管理するのかを先に確認しておくと手戻りがありません。

切り替え4：DANE をやめる・DNSSEC を外す

DANE を取りやめるときも順番があります。先に TLSA を削除し、その TTL が過ぎてから DNSSEC の変更（DS の削除や DNS 事業者の移転）に進みます。DNS 事業者の移転などで署名が壊れて検証失敗（bogus）の状態になると、TLSA の有無にかかわらず名前解決そのものが失敗し、メールもサイトも届かなくなります。DS の扱いは DNSSEC 側の手順に従ってください。

切り替え後の確認と監視

送信側の視点での確認: Postfix 付属の posttls-finger（例: posttls-finger -c -l dane example.com）や、DANE に対応した外部のメール検証サービスで、MX ごとに照合結果を見ます。
受信ログ: 切り替え直後は、受信件数が普段どおりかを見ます。DANE の失敗は受信側のログには残らず、送信側で保留されるため、件数の減少が最初の手がかりになります。
証明書更新の後処理: 更新のたびにハッシュを再計算し、公開中の TLSA と比べるスクリプトを cron などで回すと、鍵の変化を見落としにくくなります。

自分のサーバーから送るメールにも DANE を使う場合は、Postfix で smtp_tls_security_level = dane と smtp_dns_support_level = dnssec を設定し、DNSSEC を検証するローカルリゾルバ（Unbound など）を用意します。設定の変更前には main.cf のバックアップを取り、検証環境で配送を確かめてから本番に反映してください。

まとめ

DANE の切り替えは「新しい TLSA を足す → TTL を待つ → 証明書・鍵・MX を替える → 古い TLSA を消す」の順番で行う
SMTP では 3 1 1 を使い、証明書の更新で鍵を変えない運用にすると、TLSA の更新頻度を大きく減らせる
鍵の交換は current + next の2レコード並行、MX 移行は TLSA を先に公開してから MX を向ける
DANE をやめるときは TLSA を先に消し、DNSSEC の変更はその後に行う
失敗は送信側の配送保留として現れるので、openssl s_client や posttls-finger で外から照合を確認する