DNSレコードの種類をわかりやすく｜中小企業向け
目次
この記事でわかること
- 中小企業の実務で関わる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種類前後に収まります。まずは一覧で全体像を押さえておきます。
ざっくりグループ分けすると、以下の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とは両立しません。
一部のDNS事業者では「ALIAS」や「CNAMEフラットニング」という独自機能でこの制約を回避していますが、標準機能ではないことを理解した上で使ってください。
メール配送に使うレコード（MX / TXT）
取引先にメールが届くかどうかを左右するのが、このグループです。設定ミスで「送ったはずのメールが迷惑メール扱い」「Gmailに弾かれる」といった実害が出る領域なので、特に慎重に扱います。
MXレコード
「このドメイン宛のメールは、このサーバーで受け取ります」と受信先を宣言するレコードです。優先度（数値）を一緒に指定し、数字が小さいほうから順に試されます。Google Workspaceを使うなら smtp.google.com、Microsoft 365なら テナント名.mail.protection.outlook.com のように、メールサービスが案内する値をそのまま設定します。
MXレコードが間違っていると、そもそも自社宛のメールが届きません。メールサービスを乗り換える際のトラブルが非常に多いので、切り替え作業の前後でMXレコードの値を必ず確認してください。
TXTレコード（SPF／DKIM／DMARC）
TXTレコードは「任意の文字列」を格納できるレコードで、メール認証の3点セット（SPF・DKIM・DMARC）はすべてこのTXTレコードで設定します。
| 用途 | 記述例 | 役割 |
|---|---|---|
| SPF | v=spf1 include:_spf.google.com ~all |
自社から正規にメールを送れるサーバーを宣言 |
| DKIM | v=DKIM1; k=rsa; p=MIGfMA0... |
メールに電子署名を付けて改ざんを検知 |
| DMARC | v=DMARC1; p=none; rua=mailto:... |
認証失敗したメールの扱いと集計レポートの送信先を指定 |
SPFは SPFレコードの設定方法｜書き方と確認の手順 で、DKIMは DKIM設定の確認方法｜中小企業向けわかりやすく で、DMARCは 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サーバーが自動生成するため手で触ることは通常ありません。
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つの方法 も参考にしてください。
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は変更前に短くしておくなど、知っていれば防げる落とし穴がある
自社ドメインでこれらのレコードが正しく設定されているかは、無料の診断ツール で数秒で確認できます。SPF・DKIM・DMARCの設定状況や、よくあるリスクをまとめてチェックできるので、まずは現状の棚卸しから始めてみてください。
「自社のDNSレコードを見たけれど何が書いてあるのか判断できない」「メール移行を控えているが不安」といった場合は、お問い合わせ から専門家にご相談いただけます。設定内容の確認から移行計画の立案まで、人の手でサポートします。