Webサーバー・メールサーバー・DNSの違い｜制作者が説明できるインフラ基礎

「サーバーを引っ越したらメールが届かなくなった」「DNSって結局何をしているの？」は、Web制作の現場で何度も出る質問です。サイトの見た目は新しくなったのに、社内の info@ だけ静かになる。原因の多くは、Webサーバーとメールサーバーと DNS を、同じ「サーバー」という言葉で扱ってしまうことです。

先に結論です。DNS は行き先を教える案内、Webサーバーはページを出す店舗、メールサーバーは手紙を預かる郵便局です。この3つは同じドメイン名を使えても、別の機械に向けられます。違いを説明できることが、リニューアルやドメイン移管で事故を減らす第一歩です。

この記事では、フリーランスのWebディレクター兼エンジニアとして、サイト公開とメール受信を別ホストに分けてきた立場から、例えとレコードの切り分け、職種別の確認項目を整理します。固有の社名や被害額は出しません。制作で繰り返される型です。

例え話で一発理解：3つの役割分担

DNS（電話帳・案内所）

example.com は人が覚える名前です。ブラウザもメールソフトも、実際には数字の住所（IPアドレス）や「どの郵便局か」（MX）を知る必要があります。DNS はその対応表です。ネームサーバーは、対応表を置いている本棚の場所です。本棚を丸ごと別会社に移すのが「ネームサーバー変更」。本棚はそのままで、1行だけ書き換えるのが「レコード編集」です。

Webサーバー（店舗・展示場）

HTML、CSS、画像、Next.js や WordPress の公開ファイルを置き、ブラウザの「このページを見せて」に答えます。静的・Jamstack サイトなら、Vercel のようなホスティングが店舗にあたります。Aレコード（と、必要なら CNAME、AAAA）が、ドメイン名をこの店舗の住所に結びます。

メールサーバー（郵便局・ポスト）

送受信とメールボックスの保管です。Google Workspace、Microsoft 365、レンタルサーバー付属のメールは、いずれも「郵便局」です。MXレコードが、info@example.com の手紙をどの郵便局へ運ぶかを決めます。店舗の住所（Aレコード）と、郵便局の宛先（MX）は、同じである必要はありません。

失敗しやすい移行と、レコードを分けた移行

悪い例：Webの引っ越しで、メールまで止まる

旧レンタルサーバーでサイトもメールも動かしていた。リニューアルでサイトだけ新ホストへ。作業者が「ドメインの向き先を新サーバーに」と、ネームサーバーごと切り替える。新しいゾーンにはサイトの A しかなく、MX が無い、あるいは MX がサイトと同じホストを指している。社内メールが届かなくなる型です。

もう一つ多いのが、MX を example.com 自身にしたまま、ルートの A だけ新ホスト（CDN）に変えることです。MX が「自分自身」だと、手紙はサイト用の IP に届きます。そこにはメールボックスが無いので、送信側では成功に見えても、受信箱は空です。mail.example.com が CNAME でルートを見ている場合も、同じ穴に落ちます。

良い例：A だけ変えて、MX は既存の郵便局のまま

メールは今のレンタルサーバー（または Google / Microsoft）のままにする、と先に決める。DNS のゾーンは、メール側が編集できる場所に置くか、少なくとも MX と SPF を残す。サイト公開ではルート（または www）の A / CNAME だけを新ホストへ。メール用に mail の A を旧メールサーバーの IP に置き、MX を mail.example.com にする。Web は新店舗、手紙は昔の郵便局、という状態です。切替中もメールは動き続けます。「1秒も止まらない」を契約で約束する必要はありませんが、サイト切替とメール切替を同じ作業にしないことが安全です。

【職種別】現場で押さえるポイント

Webディレクター / 営業：ヒアリングと権限

着工前に聞くことは、デザインより先に次です。

• メールはどこで受信しているか（レンタルサーバー付属 / Google Workspace / Microsoft 365 / 別会社）
• ドメインは誰のアカウントか。ネームサーバーを変えられる人は誰か。ゾーン編集だけできる人は誰か
• SPF / DKIM / DMARC をすでに入れているか（フォーム送信や一斉配信があるか）

ミニ事例です。メールを聞かずにネームサーバーを新サーバー指定へ変更し、ゾーンが初期化されて MX が消える型があります。対して、切替前に現在のレコードをテキストで全部控え、メール担当と「触る行 / 触らない行」を表にした現場は、公開日にメール問い合わせが来ません。

フロントエンド / インフラ担当：レコードの使い分けと TTL

• ネームサーバー変更: 案内所の運営会社を変える。ゾーンの中身が丸ごと入れ替わることがある
• A: ホスト名を IPv4 へ。サイトのルートを新ホストへ出すときに使う
• CNAME: 別名。www をルートやホストへ向ける。同じ名前に CNAME と MX / A は同居できない
• MX: メールの配送先ホスト。必ず A（または他ホスト）へ解決できる名前にする
• TXT: SPF やドメイン所有確認。Resend などの外部送信は、ルートではなく指定サブドメイン（例: send）に置くことが多い

SSL（証明書）は、新しい Web サーバーが「そのドメインのページを出している」と証明されたあとに安定します。DNS がまだ旧 IP を返す TTL のあいだは、証明書の発行や https の確認が環境によって分かれます。切替の数日前に、関係するレコードの TTL を短くしておくと、切り戻しも含めて待ち時間が短くなります。TTL を下げずに切ると、キャッシュが残る拠点だけ旧サイト、という時間が発生します。

メールの信頼性は、受信の MX とは別に、送信の SPF / DKIM / DMARC です。サイトのフォームを外部の配信 API から送る場合、Web サーバーの IP を SPF に足すだけでは足りず、そのサービスの案内どおりのホスト（よくあるのは送信用サブドメイン）に TXT と DKIM を置きます。認証に通っても迷惑メールには入り得ますが、通っていないと届きにくさは増えます。

実務のゾーンの型です（値は例です。ホストの案内を正とします）。

; Web（店舗）は新ホスト
example.com.          300  IN  A      203.0.113.10

; メール（郵便局）は別ホスト。mail を CNAME でルートへ向けない
mail.example.com.     300  IN  A      198.51.100.20
example.com.          300  IN  MX  0  mail.example.com.

; サイト用 www
www.example.com.      300  IN  CNAME  example.com.

; 受信メール用 SPF（既存の郵便局を残す）
example.com.          300  IN  TXT    "v=spf1 include:_spf.example-mail.example ~all"

; 外部のフォーム送信（案内どおり send サブドメインへ）
send.example.com.     300  IN  MX  10 feedback-smtp.example.net.
send.example.com.     300  IN  TXT    "v=spf1 include:amazonses.com ~all"

ミニ事例です。TTL 86400 のまま A を切り替え、半日たっても「まだ古いサイト」と言われる型があります。48時間前に TTL を 300 前後へ下げ、切替後に様子を見て戻す、が扱いやすいです。

Web担当者 / 運用：契約の切れ目

ドメイン、Web ホスティング、メールは請求が別であることが多いです。担当が辞めると、お名前.com に入れない、cPanel のパスワードが分からない、が同時に起きます。台帳に、契約者メール、2要素認証の避難先、更新月を1枚にして共有します。数字や顧客名は載せなくてよいです。

一次切り分けは短いです。ブラウザでサイトは開くがメールだけ届かないなら DNS の MX / メールサーバー。メールは来るがサイトが古いなら A / CDN。両方ダメならネームサーバーかドメイン期限です。サポートに「サーバーが落ちた」と一括しない方が、復旧は速いです。

クライアントへ先に伝えること

リニューアルは店舗の内装と場所の話で、郵便局の契約変更ではありません。メールアドレスの @ 以降が同じでも、手紙の運び先は MX が決める、と図で話すと伝わります。DNS の反映にはタイムラグがあるので、切替時刻を営業のピークに置かない合意も先に取ります。休日夜間が必ず正しいわけではなく、メール担当が確認できる時間が条件です。

Web・メール・DNS 移行＆公開前確認チェックシート

まとめ：案内所・店舗・郵便局を混ぜない

Webサーバー、メールサーバー、DNS は、同じドメインの下でも役割が違います。リニューアルで触るのは多くの場合、店舗の住所（A）だけです。案内所を引っ越す（ネームサーバー変更）と、郵便局の宛先（MX）まで空になることがあります。違いを説明できると、トラブル予防だけでなく、クライアントからの質問に答えられます。

サイト公開とメール受信を分けた移行、ドメイン周りの確認は、相談・お問い合わせからどうぞ。いまのレコード一覧が分かれば、触ってよい行から整理できます。