DANE に対応した送信側のメールサーバーは、あなたの MX ホストの TLSA レコードを、EDNS0 の DO ビットを付けた問い合わせで DNSSEC の署名ごと取得します。このとき応答が大きすぎて届かない、TCP に切り替えられない、TLSA が無いことの証明を正しく返せない、といった問題があると、送信側はメールを送らずに保留します。この記事では、TLSA を公開する受信側の立場で、EDNS0 を前提に応答を小さく保ち、取りこぼしなく届けるための設計と確認方法を説明します。
送信側のリゾルバや MTA を DANE に対応させる設定は、この記事では扱いません。ここでは「受け取る側が DNS をどう整えるか」に絞ります。
送信側は何を問い合わせてくるか
DANE で送る側のメールサーバーは、おおむね次の順で問い合わせます。いずれも DNSSEC の署名を要求する DO ビット付きで、その印を運ぶのが EDNS0（RFC 6891）です。
- 宛先ドメインの MX レコード
- MX ホストの A / AAAA レコード
- MX ホストの TLSA レコード（例：
_25._tcp.mx1.example.com）
ここで重要なのは、3つ目の問い合わせに対して「検証できる形で答えられない」ことが、メールの遅延につながる点です。MX ホストのゾーンが署名されていない場合、送信側は DANE を使わずに通常の TLS で送ります。しかし、署名されているのに TLSA の問い合わせがタイムアウトしたり SERVFAIL になったりすると、送信側は攻撃の可能性を考えて送信を保留し、時間をおいて再試行します。保留が続けば、最終的にはエラーとして差出人に戻ります。
TLSA を置いていない MX ホストでも、ゾーンが署名されていれば同じ問い合わせが来ます。その場合は「TLSA は存在しない」ことを NSEC または NSEC3 の署名つきで返す必要があり、ここでつまずく DNS サービスもあります。
応答サイズを見積もる
2020 年の DNS Flag Day では、EDNS で申告する UDP のバッファサイズを 1232 バイト程度にすることが推奨されました。これを超える応答は TC フラグ付きで切り詰められ、TCP で取り直されます。受信側としては、TLSA の応答が 1232 バイトに収まるように設計しておくと、UDP の1往復で済み、断片化の影響も受けにくくなります。
応答の大きさを左右するのは、主に次の要素です。
- TLSA レコードの形式と数：
3 1 1（サーバー証明書の公開鍵の SHA-256）はデータ部が 32 バイトと小さい。証明書全体を入れる3 0 0は数百バイトから千バイトを超えることがある - 署名（RRSIG）の大きさ：DNSSEC の鍵アルゴリズムで変わる。ECDSA P-256（アルゴリズム 13）の署名は 64 バイトで、RSA 2048 ビットの 256 バイトより小さい
- 存在しないことの証明：NSEC3 のレコードと署名が複数付くため、TLSA 本体の応答より大きくなることがある
- 付加情報：権威サーバーが authority や additional のセクションに何を付けるか
TLSA は 3 1 1 を基本にし、レコードの数は「いまの鍵」と「次の鍵」の2件程度にとどめると、鍵の入れ替え期間を含めても余裕を持たせやすくなります。署名のアルゴリズムは、DNS 事業者やゾーンの設定で決まります。アルゴリズムの変更は DS の差し替えを伴う大きな作業なので、サイズのためだけに急いで変える必要はありませんが、新しくゾーンを署名するときは ECDSA P-256 などの小さい署名を選ぶと有利です。
権威サーバーの設定を整える
自分で権威サーバーを運用している場合は、次の3点を確認します。
- EDNS の UDP サイズが 1232 前後になっている
- UDP と TCP の両方で 53 番を受け付けている（ファイアウォールを含む）
- IPv4 と IPv6 の両方で、すべての権威サーバーが同じ応答を返す
BIND で明示する場合の例です。お使いの版で既定値が同じなら、書かなくても動作は変わりません。
// named.conf の options 内（例）
options {
edns-udp-size 1232;
max-udp-size 1232;
// 付加情報を減らして応答を小さくする（既定値は版で異なる）
minimal-responses yes;
};Knot DNS や PowerDNS にも同じ役割の設定がありますが、項目名と既定値は製品と版によって異なります（2026年10月現在）。設定を変える前にはゾーンファイルと設定ファイルをバックアップし、named-checkconf などで構文を確かめてから反映してください。
マネージド DNS を使っている場合、EDNS の扱いは事業者が管理しています。確認すべきなのは、TLSA というレコード型を登録できるか、ゾーンの DNSSEC 署名に対応しているか、そして TLSA の問い合わせに対して存在しないことの証明を正しく返すか、の3点です。
外から確かめる
権威サーバーそれぞれに、送信側と同じ条件で問い合わせて確かめます。ns1.example.com と mx1.example.com は自分の環境に置き換えてください。
# ① バッファ 1232 で、署名つきの TLSA を権威サーバーに直接聞く
dig @ns1.example.com _25._tcp.mx1.example.com TLSA +dnssec +bufsize=1232 +norecurse
# ② 同じ問い合わせを TCP で
dig @ns1.example.com _25._tcp.mx1.example.com TLSA +dnssec +tcp +norecurse
# ③ TLSA を置いていない名前（存在しないことの証明が返るか）
dig @ns1.example.com _25._tcp.mx2.example.com TLSA +dnssec +bufsize=1232 +norecurse
# ④ 検証するリゾルバ経由で ad が付くか
dig @1.1.1.1 _25._tcp.mx1.example.com TLSA +dnssec①では、出力の末尾にある MSG SIZE rcvd が応答の大きさです。1232 以下で、flags: に tc が付いていなければ UDP で収まっています。②がタイムアウトする場合は、TCP の 53 番が途中で塞がれています。③では、NXDOMAIN または NOERROR（回答なし）とともに NSEC か NSEC3 のレコードが authority セクションに返れば正常で、SERVFAIL や応答なしは問題です。④で ad が付けば、外部の検証リゾルバから見て TLSA が検証済みです。
権威サーバーが複数ある場合は、すべてのサーバーの IPv4 と IPv6 のアドレスに対して①〜③を繰り返します。1台だけ古い設定や古いゾーンを返していると、送信側の問い合わせがその1台に当たったときだけ失敗するため、症状が断続的になり原因を見つけにくくなります。DNSViz や internet.nl のメールのテストのような外部の診断サービスも、別の経路から確かめる手段として役立ちます（各サービスの提供内容は変わることがあります）。
鍵の入れ替え期間は応答が大きくなる
普段は収まっていても、鍵を入れ替える期間だけ応答が大きくなることがあります。
- TLSA の入れ替え：新旧と次の鍵で、一時的に3件になる
- DNSSEC の ZSK や KSK の入れ替え：DNSKEY のレコードや署名が一時的に増える
入れ替えの作業前に、増えた状態を想定して①の問い合わせでサイズを確かめておくと、作業中に一部の送信元からのメールだけが遅れる、といった事態を防げます。
WordPress サイトで表に出る症状
自社のドメインで MX を運用し、WordPress のお問い合わせフォームなどの宛先にしている場合、この問題は「一部の送信元からのメールだけ届くのが遅い、または届かない」という形で現れます。大手を含む一部のメール事業者は送信時に DANE を検証しているため（2026年10月現在）、特定の事業者からだけ遅れるときは、TLSA の応答を疑う手がかりになります。
切り分けのために EDNS を止めたり、TCP を閉じたまま運用したりするのは逆効果です。EDNS を止めると DO ビットも運べなくなり、DNSSEC と DANE の前提そのものが崩れます。
まとめ
- DANE の送信側は、MX ホストの TLSA を EDNS0 の DO ビット付きで取得し、検証できないと送信を保留する
- TLSA は
3 1 1を基本に件数を絞り、応答を 1232 バイト程度に収める - 権威サーバーは UDP と TCP の両方で 53 番を受け、すべてのサーバーが同じ応答を返すようにする
- TLSA の無い名前にも、存在しないことの証明を正しく返す必要がある
- 鍵の入れ替え期間は応答が大きくなるため、作業前にサイズを測っておく