さくらインターネットのネームサーバーで複数のドメインを管理するときは、「どのドメインが実際にさくらのネームサーバーを使っているか」を一覧にし、全ドメインに共通するレコードの型を決め、変更のたびにコマンドでまとめて確認する、という3つを仕組みにしておくと破綻しにくくなります。この記事では、管理画面での運用を前提に、ドメインが10件、50件と増えても取り違えや設定漏れを防ぐための手順を説明します。
この記事は一般的な画面構成で説明しますが（2026年10月現在）、管理画面の項目名や画面構成は変更されることがあるため、実際の表記はさくらインターネットのサポートサイトで確認してください。API や Terraform でゾーンを自動管理したい場合は、さくらのクラウドの DNS サービスを使う方法があり、この記事の最後で判断の目安を示します。
管理画面で編集できる＝効いている、ではない
複数ドメインの運用で最も多い事故は、「さくらの管理画面でレコードを直したのに何も変わらない」というものです。原因の多くは、そのドメインのネームサーバーがさくらを向いていないことです。
さくらのコントロールパネルでは、ドメインを契約していればゾーンの編集画面を開けます。しかし、レジストラ側でネームサーバーが別の事業者（レンタルサーバーの DNS や Cloudflare など）に設定されていれば、インターネットから参照されるのはそちらのレコードです。さくら側をいくら編集しても応答には反映されません。
まず、管理しているドメインごとに、権威を持っているネームサーバーを確認します。
dig +short example.com NS
dig +short example.jp NSさくらインターネットのネームサーバーを使っている場合、一般的には ns1.dns.ne.jp と ns2.dns.ne.jp が返ります（サービスによって異なることがあります）。ここで別の名前が返ったドメインは、さくらの画面で編集しても効かないので、一覧で区別しておきます。
手順1：ドメインの棚卸し表を作る
ドメインが増えると、契約・ネームサーバー・用途がばらばらになります。次の項目を表計算ソフトなどで1行1ドメインにまとめます。
- ドメイン名と取得したレジストラ（さくら以外で取得したものも含める）
- 現在のネームサーバー（上の dig の結果）
- 用途（WordPress サイト、メール専用、リダイレクト用、予約のみ など）
- Web の向き先（サーバーの IP アドレスや CNAME 先）
- メールの扱い（MX の向き先、SPF・DMARC の有無）
- 更新期限と自動更新の設定
- 担当者や依頼元
この表を作る過程で、「誰も使っていないのに更新だけ続いているドメイン」や「メールを送っていないのに SPF がないドメイン」が見つかることがよくあります。特に後者は、なりすましメールに使われるのを防ぐため、送信しないことを示すレコードを入れておく価値があります。
手順2：全ドメイン共通のレコードの型を決める
ドメインごとに思いつきでレコードを作ると、同じ目的なのに書き方が違うレコードが増え、後から確認しにくくなります。用途ごとに「標準のレコード一式」を決めておきます。
例えば、WordPress サイトを公開してメールも使うドメインなら、次のような型が考えられます。
@ A 203.0.113.10
www CNAME example.com.
@ MX 10 mail.example.com.
@ TXT "v=spf1 include:_spf.example.net ~all"
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
@ CAA 0 issue "letsencrypt.org"メールを送受信しない予約用ドメインなら、次のような型にします。
@ TXT "v=spf1 -all"
_dmarc TXT "v=DMARC1; p=reject;"値は例です。IP アドレス、SPF の include 先、CAA の認証局は自分の環境に合わせて置き換えます。CAA は証明書を発行する認証局を制限するレコードで、使っている認証局を入れ忘れると証明書の更新が止まるため、追加する前に現在の証明書の発行元を確認してください。
型を文書にしておくと、新しいドメインを追加するときも、担当者が変わったときも、同じ基準で設定と確認ができます。
手順3：変更前に現在のレコードを控える
さくらの管理画面での変更は、基本的にドメインごとの手作業です。間違えたときに戻せるよう、変更前に現在の応答を記録しておきます。
#!/usr/bin/env bash
# domains.txt に1行1ドメインで書いておく
out="dns-snapshot-$(date +%Y%m%d-%H%M).txt"
while read -r d; do
[ -z "$d" ] && continue
for t in NS A AAAA MX TXT CAA; do
echo "== $d $t" >> "$out"
dig +short "$d" "$t" @ns1.dns.ne.jp >> "$out"
done
echo "== www.$d CNAME" >> "$out"
dig +short "www.$d" CNAME @ns1.dns.ne.jp >> "$out"
done < domains.txt
echo "saved: $out"権威サーバーを @ns1.dns.ne.jp のように直接指定しているのは、キャッシュの影響を受けずに「さくら側の現在の設定」を取るためです。ネームサーバーがさくら以外のドメインは、ここでは意図した結果になりません。棚卸し表で分けておいたのはこのためです。
なお、dig では管理画面にあるレコードをすべて列挙することはできません（名前とタイプを指定して聞くため）。_dmarc やサブドメインなど、型で決めた名前は対象に加えておきます。管理画面の表示も画面キャプチャなどで残しておくと、戻すときの手がかりになります。
手順4：変更はドメイン単位で区切り、その都度確かめる
複数のドメインに同じ変更（サーバー移転による A レコードの書き換えなど）を入れるときは、一度にすべてを変えず、影響の小さいドメインから順に進めます。
- 変更する予定のレコードの TTL を、作業の前日までに短めの値に下げておく（さくらの管理画面で TTL を指定できる場合）
- 1ドメインを変更し、権威サーバーに直接問い合わせて新しい値が返るか確認する
- サイトの表示やメールの送受信を確かめる
- 問題がなければ次のドメインへ進む
dig +short example.com A @ns1.dns.ne.jp
dig +short example.com A @ns2.dns.ne.jpns1 と ns2 の両方で同じ値が返れば、さくら側の反映は済んでいます。その後、利用者が実際に新しい値を受け取るまでには、変更前の TTL の分だけ時間がかかることがあります。
手順5：定期的に一括確認する
設定したまま放置すると、ネームサーバーの変更や契約の失効に気づかないことがあります。手順3のスクリプトを月に1回程度実行し、前回の結果と比べます。
diff dns-snapshot-20260901-1000.txt dns-snapshot-20261001-1000.txt意図しない差分があれば、誰がいつ変えたのかを確認します。差分がゼロでも、更新期限が近いドメインがないかは棚卸し表で確認しておきます。
管理画面だけで続けるか、さくらのクラウドへ移すか
ドメインが十数件程度で、変更が年に数回なら、管理画面と上記の確認手順で十分に運用できます。一方、次のような状況なら、さくらのクラウドの DNS サービスに移して API や Terraform で管理することを検討します。
- 同じ変更を多数のドメインへ頻繁に入れる
- 変更の履歴とレビューを Git で残したい
- サーバーの構築と DNS の設定を一緒に自動化したい
さくらのクラウドの DNS は、ゾーンを作成すると割り当てられるネームサーバーをレジストラに登録して使います。既存の DNS とはネームサーバー名が異なるため、移行時はレコードをすべて移してから切り替える手順になります。料金体系や機能の詳細は公式の案内で確認してください。
まとめ
- さくらの管理画面で編集できても、ネームサーバーがさくらを向いていなければ効きません。最初に dig で NS を確認します。
- 1行1ドメインの棚卸し表を作り、レジストラ、ネームサーバー、用途、期限を管理します。
- 用途ごとに標準のレコード一式を決めておくと、追加や確認の基準がそろいます。
- 変更前に権威サーバーへの問い合わせ結果を控え、ドメイン単位で区切って変更し、ns1 と ns2 の両方で確かめます。
- 頻繁な一括変更や履歴管理が必要になったら、API で操作できる DNS への移行を検討します。