digでTXTを引いたらDMARCとDKIMが丸ごと抜けていた

自分のドメインに .htaccess でリダイレクトを1行足す作業をする前に、壊してはいけないレコードを把握しようとして dig を打ちました。

dig example.com TXT +short

返ってきたのは SPF と site verification の2本。「TXT は2本。メール系は SPF だけ気をつければいい」と判断しました。

実際は TXT が10本ありました。

見えていた	SPF 1本 ＋ verification 1本 = 2本
実際	10本（SPF 4・DKIM 4・DMARC 1・verification 1）

なぜ返らなかったのか

dig は正しく動いています。聞いた名前に、正しく答えていました。

dig example.com TXT が返すのは example.com という名前に付いている TXT だけです。そして DMARC と DKIM は、別の名前に置かれています。

レコード	置かれている名前
SPF	example.com（そのまま）
DMARC	_dmarc.example.com
DKIM	<selector>._domainkey.example.com

抜けていたのは _dmarc と default._domainkey、それにサブドメイン3つ分の DKIM でした。

「見えなかった」のではなく、見ていない名前があったというのが正確なところです。

個別に引くこともできる

名前が分かっていれば、それぞれ引けます。

dig _dmarc.example.com TXT +short
dig default._domainkey.example.com TXT +short

ただし DKIM のセレクタ名は総当たりできません。default 以外にもサービスごとに独自のセレクタが使われるので、名前を知らないと引きようがない。

ゾーン全体を取得する AXFR という仕組みもありますが、これは通常拒否されます（誰でもゾーン情報を丸ごと取れてしまうため）。

結局、全体を見るには DNS の管理画面かゾーンファイルを開くしかありませんでした。

半分以下しか把握できていなかった

管理画面を開いたら、レコードは全部で 37本ありました。

A 16本 / MX 8本 / TXT 10本 / NS 3本

dig から組み立てた把握は十数本だったので、半分以下です。

何が危なかったか

メール系が SPF・DKIM・DMARC の3点セットで4ドメイン分組んでありました。それを「SPF だけ気をつければいい」という理解で触るところだったわけです。

特に DMARC は、消えてもすぐには気づけません。rua=mailto: で自分宛にレポートが飛ぶ設定になっているので、届かなくなったことに気づくまで時間がかかります。SPF が壊れればメールが弾かれてすぐ分かりますが、DMARC はそうならない。

名前を1つ指定した時点で、全体を見たことにはならない

dig を打った目的は「壊してはいけないものを把握する」ことでした。範囲を確認する作業だったのに、その作業自体で範囲を狭く取っていたことになります。

コマンドは正しく、出力も正しく、ただ問いが狭かった。ここが自分にとっては引っかかりどころでした。確認のコマンドを打つときは、それが何を返さないかのほうを先に見ておくと安全そうです。