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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サイトを見に行く先

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

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

メールを届ける先

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

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

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

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

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

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

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

設定画面で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つあります。

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

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

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

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

別名という仕組み

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

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

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

制約も書かれています。

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

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

問題はこの先です。

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

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

理由も書かれています。

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

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

必ず要る行が、2つある

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

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

1つはSOAレコードです。

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

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

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

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

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

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

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

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

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

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

名前だけを見て「うちの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

関連する記事

同じドメイン名に対して発行される証明書の期限は、別の記事で扱っています。
上限がすでに200日まで下がっていることと、自動更新の考え方をまとめています。
https://note.com/yunta_fukurou/n/n30db220f551f

誰が何を設定できるかを書き出す話は、別の記事で扱っています。
共有リンクが転送できることと、退職者のIDが残ることをまとめています。
https://note.com/yunta_fukurou/n/n88b3e264756d

社内から外へ出る入口の設定は、こちらで扱っています。
規格と制度のどちらで使える帯域が決まるかと、選ぶときに見る5項目をまとめています。
https://note.com/yunta_fukurou/n/n3551cc36bb7f

機器を1台足す前に確かめることは、別の記事で扱っています。
ファイアウォールとUTMの違いと、いま入っているもので足りるかの見方をまとめています。
https://note.com/yunta_fukurou/n/n8483037cfd1d

切り替えるときと、閉じるときの段取りは、別の記事で扱っています。
TTLを先に下げる理由と、解約と自社側の削除が別の作業であることをまとめています。
https://note.com/yunta_fukurou/n/n3f98920bc795

サイトの側にも、置く側が決められるのに決めていないことがあります。
PDFを開くか落とすかと、印刷したときの見え方を、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n5f6d9b1c398f

同じサイトでも、こちらでは決められないことがあります。
動画の自動再生と、検索結果に出る見出しを、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n2a3929dd9e07