DNSWeb 担当者学習

DNS とは｜Web 担当者向けにわかりやすく解説

2026年4月30日ドメイン番人約 5 分で読めます

この記事でわかること

DNS が「インターネットの電話帳」と呼ばれる理由
業務で名前を見かける主要レコード(A / MX / TXT / CNAME)の役割
設定変更時に必ず知っておきたい TTL と反映時間の考え方

DNS は「ドメインを実体に変換する仕組み」

ホームページにアクセスするとき、ブラウザは https://example.co.jp のような ドメイン名を入力します。ところがインターネット上で実際に通信するには、サーバーの IP アドレス(例: 203.0.113.10)が必要です。

DNS（Domain Name System、ドメインネームシステム）は、この「ドメイン名を IP アドレスに変換する」仕組みです。電話帳に載っている名前から電話番号を探すのとよく似ています。

メールも同じく、[email protected] 宛にメールを送るとき、送信側のサーバーは「example.co.jp のメールサーバーはどこか」を DNS に問い合わせて配送先を決めます。

DNS は名前を実体に変換する仕組み

つまり DNS が止まると、

ホームページが開かなくなる
メールが届かなくなる
取引先のシステム連携(API)も止まる

という状態になります。サーバー本体は動いていても、DNS が壊れると外から見えなくなる、という構造です。

業務で目にする主要レコード

DNS には数十種類のレコードタイプがありますが、中小企業の業務で日常的に出てくるのは次の 4 種類です。それぞれの役割を理解しておけば、サーバー会社や制作会社とのやり取りで困ることはほぼありません。レコードの全体像はDNSレコードの種類をわかりやすく解説も参考になります。

主要 DNS レコードの役割

A レコード

ドメインを IPv4 アドレスに紐づけるレコード。ホームページや Web アプリの公開に使います。example.co.jp → 203.0.113.10 のようなマッピングです。サーバー移転時はここを書き換えます。

MX レコード

そのドメイン宛のメールを どのメールサーバーに届けるか を指定するレコード。Google Workspace を使っているなら Google のメールサーバーを、Microsoft 365 なら Microsoft のサーバーを指定します。MX レコードの詳しい設定はMX レコードの設定方法で扱っています。

TXT レコード

任意のテキストを置けるレコード。実用上は メール認証(SPF / DKIM / DMARC) や、ドメイン所有確認(Google Search Console や Microsoft 365 のドメイン認証)で使います。中小企業がメール到達率の改善に取り組む際、このレコードを触る機会が一番多いはずです。書ける文字数や複数値の扱いといった基本はTXT レコードの基本、メール認証の入口としての位置づけはメール認証(SPF / DKIM / DMARC)とはで取り上げています。

CNAME レコード

別名(エイリアス)を作るレコード。shop.example.co.jp を example.myshopify.com などの SaaS のホスト名に向ける、といった使い方をします。A レコードと同じ階層には併存できないという制約があり、これを知らずに設定してメールが止まる事故が起きやすい論点です。shop. mail. のような サブドメイン をどう設計するかはサブドメインとメール運用の基本に整理しています。

なお A / MX / TXT / CNAME を実際に登録するのは、ドメインに紐づいた ネームサーバー です。「ドメイン管理会社」と「ネームサーバーの管理画面」が別になっているケースは中小企業で非常に多く、設定変更時の混乱の元になります。役割分担と確認方法はネームサーバーとは(Web 担当者向け入門)を参照してください。

TTL と「反映に時間がかかる」の正体

DNS 変更後によく聞く「反映に最大 24〜48 時間かかります」という説明、これには理由があります。

DNS 情報は世界中の キャッシュサーバーに一時保存されており、毎回大元に問い合わせるわけではありません。各レコードには TTL(Time to Live) という値が設定されていて、たとえば 3600(秒)なら「1 時間はキャッシュを使ってよい」という意味になります。

DNS 変更が反映されるまでの流れ

つまり変更直後でも、世界各地のキャッシュサーバーは旧情報を持ち続け、TTL の時間が経過してから新しい情報を取りに来ます。サーバー移転やメール基盤切り替えなど、計画的な変更では 事前に TTL を短くしておく(例: 86400 → 300) のが定石です。

ただし TTL を短くしすぎると DNS サーバーへの問い合わせが増え、応答性能に影響することもあります。普段は 3600〜86400 秒、変更前 1〜2 日だけ 300 秒、というふうに使い分けるのが無理のないバランスです。

やってしまいがちな 3 つのミス

DNS は仕組みがシンプルな反面、誤操作の影響範囲が広く、メール停止やサイト 404 に直結します。中小企業で実際に起きやすいのは次の 3 パターンです。

過去の制作会社が設定したレコードを把握せずに上書き: SPF や DKIM など、メール認証用の TXT レコードを誤って消してしまうと、Gmail への配信性が一気に悪化します
MX レコードを 1 つだけしか設定しない: メールサーバーの冗長化のため、通常は優先度違いで複数の MX を持ちます
A レコードと CNAME を同じホスト名に併設: 仕様違反で、リゾルバによっては解決失敗になります

このうち 1 番のケースは、DMARC 義務化以降のメール到達率低下の主原因のひとつです。詳しくはGmailにメールが届かない時の原因で解説しています。

まずは自社の DNS を可視化する

要点をおさらいします。

DNS は「ドメイン名 → 実体(IP / メールサーバー)」を変換する仕組みで、止まるとサイトもメールも見えなくなる
中小企業で関わるレコードは A / MX / TXT / CNAME の 4 種類が中心。CNAME と A の併存制約だけは要注意
TTL の存在で変更には反映時間が伴う。計画的な変更では事前に TTL を短くしておく
DNS 改ざんを検知する仕組みとして DNSSEC もあわせて知っておくと、レジストラ選定時の比較軸が増えます

「自社のドメインに今どんなレコードが入っているか分からない」「過去の制作会社が設定した TXT レコードが残っているか不安」、そんな場合は、まず無料のドメイン診断で現状を可視化できます。SPF / DKIM / DMARC を含む主要レコードの設定状態を一括でチェックします。

設定変更を伴う作業を専門家に任せたい方は、お気軽にご相談ください。設定前後の動作確認まで人の手で確認しながら進めます。