サイトは見えるのにメールだけ届かない｜1つのドメイン名に、行き先の行は何本もある

2026年9月17日 08:45

ホームページの制作会社を変えることになりました。

新しい会社にデータを移し、公開日を決めて、ドメイン名の設定を切り替えます。
当日、サイトは新しくなりました。
問題なく見えています。

翌日、取引先から電話が来ます。
「メールが返ってこないんですが」。

サイトとメールは、同じ名前を使っています。
同じ名前なのに、片方だけ止まりました。

この記事では、1つのドメイン名の中に何が書かれているのかを、JPRSの用語辞典とRFCの日本語訳から並べます。
設定画面を触る話ではありません。
制作会社やサービスの担当者に何を頼むか、頼む前に何を書き出しておくかの話です。

この記事は、株式会社日本レジストリサービス（JPRS）が公開している用語辞典とRFC日本語訳、およびさくらインターネットのマニュアルをもとに、2026年9月時点の内容にしています。用語の解説や各社のサービス仕様は改訂されます。実際の設定は、お使いの事業者の説明とあわせて確認してください。

1つのドメイン名には、用途ごとに別の行が書いてある

名前を行き先に変える仕組み

インターネットでは、名前を実際の行き先に変換する仕組みが働いています。
これをDNSといいます。

その変換のもとになる1行1行を、リソースレコードと呼びます。
.jpドメイン名の登録を管理しているJPRSの用語辞典に、こうあります。

DNSにおいて、ドメイン名に関連付けられた情報（レコード）のことです。リソースレコードにはさまざまな種類があり、それぞれに役割と記述のルールが決められています。

種類がある、というところが要点です。

本当に1行ずつ書かれている

比喩ではありません。
同じ解説に、こうも書かれています。

リソースレコードは、ゾーンファイル内においてはテキスト形式で表現され、通常は1行で記述されます。

1つの名前に対して、用途ごとに別々の行が並んでいます。

社内の内線表に近いかもしれません。
同じ会社名でも、代表番号とFAX番号と受付の番号は別の行に書いてあります。
どれか1つを直しても、ほかは直りません。

Webの行き先とメールの行き先は、別のレコードである

サイトを見に行く先

Webを見に行く先は、Aレコードという種類です。
同じ用語辞典から。

ドメイン名に対するIPv4アドレスを指定するリソースレコードです。同じドメイン名に対して複数記述することができます。

IPv4アドレスというのは、インターネット上の住所を表す数字の並びです。
192.0.2.1のような形をしています。

メールを届ける先

メールの行き先は、MXレコードという別の種類です。

mail exchange（メールサーバー、メールを配送するホスト）を指定するためのリソースレコードです。

別の種類で、別の行です。

ここが冒頭の事故の正体です。
制作会社が移ったときに直されたのはAレコードで、MXレコードは古い会社の設定のまま残った、あるいは一緒に消えた。
サイトは見えるのに、メールだけ届かない。
そういう状態になります。

サイトとメールを別々の会社に頼んでいる会社では、珍しい事故ではありません。

優先度の数字は、小さいほうが先

MXレコードには、もう1つ特徴があります。

MXリソースレコードの特徴として、配送における優先度を指定する「プリファレンス（preference）」があり、「配送先ホスト」ごとに指定されます。プリファレンスによる優先度は数字で示され、配送先が複数ある場合には、より小さなプリファレンスを持つホストが優先されます。

数字が小さいほうが先です。
大きいほうではありません。

設定画面で10、20といった数字を見たことがあるかもしれません。
あれは順番です。
同じ解説に挙げられている例では、プリファレンスが10のホストが優先され、そこへの配送に失敗した場合に別のホストを使う、という指定になっています。

目的も書かれています。

これにより、配送するメールサーバーの優先度を指定でき、メールサービスの可用性向上が期待できます。

メールの受け口は複数持てます。
1台止まっても、次に回ります。
サイトのほうとは設計の考え方が違うわけです。

ここで「小さいほうが優先」を逆に覚えていると、予備のつもりで書いた行が本番になります。
設定を確認するときは、数字の大小を必ず見てください。

引っ越しの日に、片方のレコードだけが直される

実務で起きる順番を書いておきます。

1つ目、サイトの制作会社が変わる。
新しい会社が「ここを向けてください」と行き先を伝えてくる。

2つ目、ドメイン名の設定画面を開き、言われたとおりに書き換える。
あるいは、設定一式をまるごと新しい会社に預ける。

3つ目、まるごと預けた場合、新しい会社は自分たちが使う行だけを作る。
メールの行は、こちらが伝えなければ作られない。

4つ目、切り替わる。
サイトは動く。
メールは、古い設定が消えた時点で止まる。

止まった側に気づくまでに時間がかかるのも、この事故の厄介なところです。
届かないメールは、こちらの画面には出てきません。
相手が困って電話をくれるまで分かりません。

切り替えた当日、どれくらいで反映されるのかは、別の記事で扱っています。
TTLという秒数を先に下げておく段取りと、元に戻すときも同じだけ待つことをまとめています。
https://note.com/yunta_fukurou/n/n3f98920bc795

wwwありと、wwwなしは、別の名前である

新しいサービスを1つ導入したとします。
案内に「このドメイン名を、こちらへ向けてください」と書かれています。

言われたとおりに設定すると、www付きのアドレスでは開きました。
ところが、名刺に刷ってあるwww無しのアドレスでは開きません。

担当者に伝えると、「www無しのほうは、その方法では設定できません」と返ってきます。

嫌がらせではありません。
決まりがあります。

まず、この2つは別の名前である

「www.example.co.jp」と「example.co.jp」は、人間には同じ会社に見えますが、DNSの上では別の名前です。
前の節のAレコードも、それぞれに別々に書きます。

片方だけ設定してあれば、片方でしか開きません。
名刺やパンフレットにwww無しを刷っているのに、設定してあるのがwww付きだけ、という会社は実際にあります。

別の名前だということは、証明書の側にも効いてきます。
鍵マークを出すための証明書は、どの名前に対して出したものかが決まっています。
証明書の期限が短くなり続けている話は、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n30db220f551f

いちばん外側の名前は、位置が違う

扱いの違いが、もう1つあります。

用語辞典に、ゾーンという言葉の説明があります。

DNSにおいて、委任によって作られる管理の単位のことです。

「example.co.jp」という管理の単位があって、その中に「www」やそのほかの名前が置かれている。
そういう入れ子になっています。

いちばん外側は、中の名前とは役割が違います。

別名のレコードは、ほかのレコードと同居できない

別名という仕組み

ここで、もう1つの種類が出てきます。
CNAMEレコードです。

別名に対する正式名を指定するためのリソースレコードです。

自分で行き先を書く代わりに、「この名前は、あちらの名前と同じ扱いにしてください」と書いておく仕組みです。

DNSの名前解決では、CNAMEリソースレコードが見つかった場合、ドメイン名を正式名に置き換えて名前解決を継続します。

外部のサービスを使うときに、これがよく指定されます。
同じ解説にも、現在の主な用途としてCDNが挙げられています。
向こうの行き先は向こうの都合で変わるので、こちらが数字を書き写すと、変わったときに止まります。
別名にしておけば、向こうが変えてもこちらは直さなくて済みます。

制約も書かれています。

ある別名に対する正式名は常に一つであるため、一つの別名に対し、正式名を二つ以上指定することはできません。

1つの別名に対して、正式名は1つ。
ここまでは、そういうものかと思える話です。

混ぜてはいけない、という決まり

問題はこの先です。

DNSの基本を定めた文書に、決まりが書かれています。
JPRSが日本語訳を公開しているRFC 1034から引きます。

ノードにCNAME RRが存在する場合、他のデータは存在すべきでない。

ノードというのは、1つの名前のことだと考えてください。
ある名前に別名の行を書いたら、その名前にはほかの行を書いてはいけない、ということです。

理由も書かれています。

これにより、正式名とその別名でデータが異なることはあり得ないことを保証する。

別名は「あちらと同じ」という意味なので、そこに独自の行が混ざっていると、どちらが本当か分からなくなります。
だから混ぜない。
そういう作りです。

いちばん外側の名前には、別名を置けない

必ず要る行が、2つある

ここまでをつなぐと、冒頭の答えが出ます。

「example.co.jp」という管理の単位のいちばん外側には、あらかじめ置かれている行があります。

1つはSOAレコードです。

ゾーンの起点を示し、ゾーンの管理情報を指定するためのリソースレコードです。SOAリソースレコードは、一つのゾーンに一つだけ記述されます。

もう1つはNSレコードです。

あるゾーンに対する権威（オーソリティ）を持つ権威サーバー（権威DNSサーバー）を指定するためのリソースレコードです。

NSレコードのほうには、こうも書かれています。

ゾーンを委任する際に使用され、複数台の権威サーバーがある場合には、その数だけNSリソースレコードをゾーンファイルに記述する必要があります。

どちらも、その名前に置かれる行です。
そして前の節のとおり、別名の行はほかの行と同居できません。

つまり、いちばん外側の名前には、そもそも別名を置く余地がありません。
www付きのような中の名前になら置けます。
外側には置けない。

これが「www無しのほうは、その方法では設定できません」の中身です。

回避の仕組みはあるが、向け先が限られる

事業者によっては、この制約を回避するための独自の仕組みを用意しています。

さくらインターネットのDNSアプライアンスのマニュアルには、こうあります。

DNSアプライアンスでは、弊社内サービスにおいてALIASレコードを利用した名前解決に対応しています。

続けて、対応するサービスではいちばん外側の名前を使えると書かれています。
ここで見落とせないのが「弊社内サービスにおいて」という条件です。

つまり、この仕組みがあっても、向け先はその事業者が挙げているサービスに限られる場合があります。
外部のサービスから「いちばん外側を別名で向けてください」と言われたときに、そのまま使えるとは限りません。

名前だけを見て「うちのDNSはALIASに対応しているから大丈夫」と答えると、そこで食い違います。
対応しているサービスの一覧まで見てください。

頼む前に、ドメイン名の1枚の表を作る

防ぎ方は、難しくありません。
いまの設定を先に書き出しておくことです。

1つ目、いまそのドメイン名で何を使っているかを並べる。

ホームページ、メール、社内からだけ見える何か、外部サービスに預けている名前。
使っているものを全部書きます。

2つ目、それぞれの行き先が、どの会社のものかを書く。

サイトはA社、メールはB社、というふうに。
ここが1社にまとまっていない会社ほど、事故が起きます。

3つ目、切り替えを頼むときに、その表を渡す。

「サイトだけ変えてください、ほかは触らないでください」と口頭で言うのではなく、触らない行を紙で示します。

4つ目、外部サービスの案内に「別名で設定してください」とある場合、対象がどの名前かを見る。

中の名前を指定されているなら、そのまま設定できます。
いちばん外側を指定されているなら、この記事の6つ目の節の話になります。

5つ目、切り替えた当日、サイトだけでなくメールも試す。

社外のアドレスから自社宛てに1通送って、届くことを確かめます。
送信ではなく受信を試すのが要点です。

この表は、1回作れば次の切り替えでも使えます。
作るのに半日もかかりません。

誰が何を設定できるかを書き出す作業は、アカウントの側でも同じです。
共有リンクと退職者のIDをどう棚卸しするかは、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n88b3e264756d

まとめ

1つのドメイン名には、用途ごとに別々の行が書かれています。
これをリソースレコードといい、種類ごとに役割と書き方が決められていて、ゾーンファイルの中では通常1行で記述されると説明されています。

Webを見に行く先はAレコード、メールの配送先はMXレコードで、別の種類です。
片方を直しても、もう片方は直りません。

MXレコードには優先度の数字があり、より小さいプリファレンスを持つホストが優先されると明記されています。
複数の受け口を持たせて、届かなければ次に回す仕組みです。

制作会社の切り替えでサイトの行だけが直され、メールの行が残ったり消えたりすると、サイトは見えるのにメールだけ届かない状態になります。

www付きとwww無しは別の名前で、それぞれ設定が要ります。

別名の仕組みであるCNAMEレコードは、1つの別名に指定できる正式名が1つだけとされています。
そしてDNSの基本文書には、ある名前に別名の行がある場合、ほかのデータは存在すべきでないと書かれています。

ドメイン名のいちばん外側には、ゾーンの起点を示す行と、権威を持つサーバーを指定する行が置かれます。
そのため、そこには別名を置けません。

回避のための独自の仕組みを持つ事業者もありますが、向け先が自社サービスに限られる場合があります。
対応しているサービスの一覧まで確かめます。

頼む前に、いま何を使っていて、それぞれの行き先がどの会社のものかを1枚に書き出します。
当日は受信を試します。

皆さんの会社のドメイン名は、いくつの用途に使われているでしょうか。
書き出したものはありますか。

参考・引用元

リソースレコードの種類

JPRS用語辞典「リソースレコード（RR）」（株式会社日本レジストリサービス） https://jprs.jp/glossary/index.php?ID=0165
JPRS用語辞典「Aリソースレコード（Aレコード）」（同上） https://jprs.jp/glossary/index.php?ID=0161
JPRS用語辞典「MXリソースレコード（MXレコード）」（同上） https://jprs.jp/glossary/index.php?ID=0163

別名と、いちばん外側の名前

JPRS用語辞典「CNAMEリソースレコード（シーネームリソースレコード）」（同上） https://jprs.jp/glossary/index.php?ID=0212
JPRS用語辞典「ゾーン」（同上） https://jprs.jp/glossary/index.php?ID=0142
JPRS用語辞典「SOAリソースレコード」（同上） https://jprs.jp/glossary/index.php?ID=0194
JPRS用語辞典「NSリソースレコード」（同上） https://jprs.jp/glossary/index.php?ID=0146
RFC 1034「ドメイン名 - 概念と機能」日本語訳（JPRSによる公開、原文1987年11月） https://jprs.jp/tech/material/rfc/RFC1034-ja.txt

事業者の独自の仕組み

さくらインターネット「DNS(アプライアンス)」（さくらのクラウドマニュアル、2026年6月15日更新） https://manual.sakura.ad.jp/cloud/appliance/dns/index.html

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40