![DNSレコードは役割で見分ける](/blog/dns-record-types/hero.avif)

## この記事でわかること

- 実務で関わるDNSレコードは、役割ごとに「サイト表示系」「メール配送系」「運用系」の3グループに整理できること
- A、AAAA、CNAME、MX、TXT、NS、SOA、CAAの各レコードが、それぞれ何を決めているか
- CNAMEをドメイン直下に置けない、TTLを変更前に短くしておくなど、設定時に注意すべきポイント

## DNSレコードとは｜主な種類を一覧で把握する

DNS（ディーエヌエス、Domain Name System）は、インターネット上の住所録の仕組みです。「example.co.jp」のようなドメイン名を、実際のサーバーのIPアドレスやメールサーバー名に変換するために使われます。

その住所録の中身にあたるのが**DNSレコード**です。1つのレコードは「このドメインの、この用途で使う情報はこれです」という1行の宣言で、種類ごとに役割が分かれています。たとえば「ウェブサイトはこのサーバーに置いています」「メールはこのサーバーで受け取ります」「このドメインから正規にメールを送れるのはここだけです」といった情報を、それぞれ別のレコード種類で表現します。DNSの基本仕様はインターネット標準のRFC 1034・RFC 1035で定義されており、現在も同じ枠組みの上でメール認証（SPF・DKIM・DMARC）やSSL証明書の発行制御（CAA）などが追加で動いています。

中小企業で触れる可能性があるレコードは、多く見えても実際は10種類前後に収まります。まずは一覧で全体像を押さえておきます。

![中小企業でよく使うDNSレコード種類の一覧](/blog/dns-record-types/record-types-overview.svg)

ざっくりグループ分けすると、以下の3つです。

- **サイト表示系**: Aレコード、AAAAレコード、CNAMEレコード
- **メール配送系**: MXレコード、TXTレコード（SPF／DKIM／DMARCを格納）
- **運用系**: NSレコード、SOAレコード、CAAレコード、TTL

多くのサイト運営者ではこの中から必要なものだけを使っています。自社サイトとメールを運用しているなら、最低でもA・MX・TXTの3種類は必ずどこかで設定されています。

## サイト表示に使うレコード（A / AAAA / CNAME）

ブラウザで「https://example.co.jp」にアクセスしたとき、どのサーバーが応答するかを決めるのがこのグループのレコードです。

### Aレコード

ドメイン名をIPv4アドレス（例: 203.0.113.10）に対応づけるレコードです。「`www.example.co.jp` はこのIPアドレスのサーバーです」と宣言します。もっとも基本的なレコードで、レンタルサーバーを申し込むと多くの場合は事業者がすでに設定してくれています。

### AAAAレコード

Aレコードと同じ役割を、IPv6アドレス（例: 2001:db8::1）に対して行うレコードです。IPv6に対応したサーバーを使うときに追加します。AレコードとAAAAレコードの両方を設定しておけば、IPv4とIPv6のどちらの環境からもアクセスできます。

### CNAMEレコード

「このドメイン名は、別の正式なドメイン名の別名です」と宣言するレコードです。たとえば `shop.example.co.jp` を `shop.some-ec-service.com` の別名として登録すると、利用者が shop.example.co.jp にアクセスした時点で、DNSが自動的に shop.some-ec-service.com を引き直して実際のIPアドレスまでたどってくれます。

CNAMEには1つ大きな制約があります。**ドメイン直下（zone apex、例: example.co.jp そのもの）にはCNAMEを置けません**。RFC 1034が「CNAMEがあるノードには他のレコードを置いてはならない」と定めているためで、ドメイン直下はNSレコードやSOAレコード、MXレコードと同居する必要があり、CNAMEとは両立しません。

![CNAMEをドメイン直下に置くとNG、サブドメインならOK](/blog/dns-record-types/cname-apex-pitfall.svg)

一部のDNS事業者では「ALIAS」や「CNAMEフラットニング」という独自機能でこの制約を回避していますが、標準機能ではないことを理解した上で使ってください。

## メール配送に使うレコード（MX / TXT）

取引先にメールが届くかどうかを左右するのが、このグループです。設定ミスで「送ったはずのメールが迷惑メール扱い」「Gmailに弾かれる」といった実害が出る領域なので、特に慎重に扱います。

![メール配送に関わるDNSレコードの役割](/blog/dns-record-types/mail-records-flow.svg)

### MXレコード

「このドメイン宛のメールは、このサーバーで受け取ります」と受信先を宣言するレコードです。優先度（数値）を一緒に指定し、数字が小さいほうから順に試されます。Google Workspaceを使うなら `smtp.google.com`、Microsoft 365なら `テナント名.mail.protection.outlook.com` のように、メールサービスが案内する値をそのまま設定します。

MXレコードが間違っていると、そもそも自社宛のメールが届きません。メールサービスを乗り換える際のトラブルが非常に多いので、切り替え作業の前後でMXレコードの値を必ず確認してください。

### TXTレコード（SPF／DKIM／DMARC）

TXTレコードは「任意の文字列」を格納できるレコードで、メール認証の3点セット（SPF・DKIM・DMARC）はすべてこのTXTレコードで設定します。TXTレコードの書式や確認方法の基礎は[TXTレコードとは](/blog/txt-record-basics)で詳しく解説しています。

| 用途 | 記述例 | 役割 |
|---|---|---|
| SPF | `v=spf1 include:_spf.google.com ~all` | 自社から正規にメールを送れるサーバーを宣言 |
| DKIM | `v=DKIM1; k=rsa; p=MIGfMA0...` | メールに電子署名を付けて改ざんを検知 |
| DMARC | `v=DMARC1; p=none; rua=mailto:...` | 認証失敗したメールの扱いと集計レポートの送信先を指定 |

SPFは [SPFレコードの設定方法｜書き方と確認の手順](/blog/spf-setup-guide) で、DKIMは [DKIM設定の確認方法｜Web 担当者向けわかりやすく](/blog/dkim-verification) で、DMARCは [DMARC とは？仕組みと中小企業が今すぐやるべき対応を 5 分でわかる入門](/blog/what-is-dmarc) でそれぞれ詳しく解説しています。2024年2月のGmail送信者ガイドライン強化以降、1日5,000通以上を送る組織ではこの3点セットが事実上の必須条件になっています。

なおTXTレコードには、メール認証以外にもドメイン所有権の確認（Google Search ConsoleやMicrosoft 365のドメイン認証など）や、BIMI（ブランドロゴ表示）の設定で使われる場面があります。1つのドメインに複数のTXTレコードを並べることができるため、役割が違えば共存しても問題ありません。

## 見落としやすい運用系レコード（NS / SOA / CAA / TTL）

普段は意識しないものの、トラブル時に確認が必要になるレコード群です。

### NSレコードとSOAレコード

NSレコード（ネームサーバーレコード）は「このドメインの正式な情報は、どのDNSサーバーが持っているか」を宣言します。ドメインを取得した直後にレジストラ（例: お名前.com、Xserver Domain）側で設定され、Cloudflareやレンタルサーバーなどに任せる場合はそこで指定されたネームサーバー名をNSに登録します。

SOAレコード（Start of Authority）はゾーンの管理情報（管理者メール、更新頻度、シリアル番号など）をまとめたレコードで、DNSサーバーが自動生成するため手で触ることは通常ありません。プライマリ DNS からセカンダリ DNS への複製（DNS ゾーン転送）は SOA の Serial/Refresh を起点に動きます。詳細は [AXFR（DNS ゾーン転送）とは](/blog/soa-record-zone-transfer) を参照。

NSの指定先を間違えると、ドメイン全体が引けなくなります。ネームサーバーの切り替えは「手順書なしに感覚でやらない」のが鉄則です。

### CAAレコード

CAAレコード（Certification Authority Authorization）は「このドメインに対するSSL証明書を発行できる認証局はここだけです」と指定するレコードです。RFC 8659で標準化され、2017年9月以降は全ての公的な認証局（CA）がSSL証明書を発行する前にCAAを確認することが義務づけられています。

Let's Encryptだけに発行を許可したい場合は `0 issue "letsencrypt.org"` のように記述します。CAAを設定していないドメインは「どのCAでも発行可」と扱われるので、セキュリティ要件が厳しい場合は設定しておくと、なりすまし証明書の発行リスクを下げられます。SSL証明書全般については [SSL証明書の有効期限を確認する3つの方法](/blog/ssl-expiration-check) も参考にしてください。

### TTL（Time To Live）

TTLは「このレコードの情報を、世界中のDNSサーバーが最大何秒キャッシュしてよいか」を指定する値で、各レコードに付随するパラメータです。一般的には以下が目安になります。

- 普段: 3,600秒（1時間）〜86,400秒（1日）程度
- 変更作業の前: 作業の1〜2日前に300秒（5分）などに短縮
- 変更後: 問題がないことを確認してから元の長さに戻す

TTLを事前に短くしておかないと、古い値のキャッシュが世界中に残り続け、切り替え直後に一部のユーザーだけ「メールが届かない」「サイトが見られない」といった状態が数時間から1日続くことがあります。メールサービスの移行やサーバー引っ越しの際には必ず確認してください。

## まとめと、現状を把握する次の一歩

- DNSレコードは「サイト表示系（A／AAAA／CNAME）」「メール配送系（MX／TXT）」「運用系（NS／SOA／CAA／TTL）」に整理すると見通しが良くなる
- メール配送系のTXTレコード（SPF／DKIM／DMARC）は、Gmail送信者ガイドライン強化以降ビジネス上の必須設定
- CNAMEはドメイン直下に置けない、TTLは変更前に短くしておくなど、知っていれば防げる落とし穴がある

自社ドメインでこれらのレコードが正しく設定されているかは、[無料の診断ツール](/diagnose) で数秒で確認できます。SPF・DKIM・DMARCの設定状況や、よくあるリスクをまとめてチェックできるので、まずは現状の棚卸しから始めてみてください。

「自社のDNSレコードを見たけれど何が書いてあるのか判断できない」「メール移行を控えているが不安」といった場合は、[お問い合わせ](/contact) から専門家にご相談いただけます。設定内容の確認から移行計画の立案まで、人の手でサポートします。