メインコンテンツへスキップ
10種類のDNSレコードタイプの設定構文と実践シナリオを完全解説。A/AAAA/CNAME/MX/TXT/NS/SOA/PTR/SRV/CAAレコードのベストプラクティス、2024年Googleメール認証要件、47日SSL証書ポリシーに対応

DNSレコードタイプ完全ガイド：AレコードからCAAまでの実践設定マニュアル

10種類のDNSレコードタイプの設定構文と実践シナリオを完全解説。A/AAAA/CNAME/MX/TXT/NS/SOA/PTR/SRV/CAAレコードのベストプラクティス、2024年Googleメール認証要件、47日SSL証書ポリシーに対応

• 879 文字 • 5 分
DNSレコードタイプ Aレコード設定 CNAMEレコード MXレコード TXTレコード SPF設定 DKIM DMARC CAAレコード DNS設定

結論： DNSレコードはドメイン名とインターネットサービスを結ぶ橋梁である。A、CNAME、MX、TXT、CAAなどのレコードタイプを正確に設定することで、Webサイトへの正常なアクセス、メールの確実な配信、SSL証明書の安全な発行が実現される。2024年よりGoogleとYahooがSPF/DKIM/DMARCによるメール認証を義務化し、未設定のドメインからのメールは拒否されるリスクが生じている。

ドメイン登録を完了した後、そのドメインを実際に「機能させる」ための核心的な作業がDNSレコードの設定である。Webサイトの構築、企業メールの設定、CDNの導入、ドメイン所有権の確認など、あらゆる場面で各種DNSレコードタイプの理解と正確な設定が求められる。

本ガイドでは、10種類のDNSレコードタイプについて設定構文、適用シーン、よくある落とし穴を一つずつ解説する。併せて2024年メール認証義務化とCA/B Forum最新SSL証明書ポリシーにも対応し、安全かつ効率的なドメイン設定の実現を目指す。

DNSレコードタイプ早見比較表

各レコードを詳しく見る前に、全体像を把握しておこう。

レコードタイプ主な機能値の例使用頻度
Aドメイン → IPv4アドレス192.0.2.1極めて高い
AAAAドメイン → IPv6アドレス2001:db8::1高い
CNAMEドメイン → 別のドメイン（別名）cdn.example.com極めて高い
MXメールルーティングmail.example.com（優先度10）高い
TXTテキスト検証情報v=spf1 include:…極めて高い
NS権威DNSサーバーの指定ns1.cloudflare.com中程度
SOAゾーン管理メタデータシリアル番号/リフレッシュ/リトライ低い
PTRIP → ドメイン（逆引き）mail.example.com中程度
SRVサービスディスカバリ（ホスト+ポート）sip.example.com:5060中程度
CAASSL証明書発行CAの制限letsencrypt.org高い（上昇傾向）

Aレコード：ドメイン名前解決の基盤

Aレコード（Address Record） はDNSシステムにおいて最も基本的かつ使用頻度の高いレコードタイプである。ドメイン名を直接IPv4アドレスにマッピングする。

設定構文

example.com.    3600    IN    A    192.0.2.1

各フィールドの意味：

  • example.com. — ドメイン名（末尾のドットはFQDNを示す）
  • 3600 — TTL（秒単位）。キャッシュの有効期間
  • IN — インターネットクラス
  • A — レコードタイプ
  • 192.0.2.1 — 対象IPv4アドレス

実践シナリオ

シナリオ1：単一サーバーへのポイント

ルートドメインとwwwサブドメインの両方をWebサーバーに向ける：

example.com.      300    IN    A    203.0.113.50
www.example.com.  300    IN    A    203.0.113.50

シナリオ2：ラウンドロビンDNSによる負荷分散

複数のAレコードを設定して簡易的なロードバランシングを実現する：

example.com.    300    IN    A    203.0.113.50
example.com.    300    IN    A    203.0.113.51
example.com.    300    IN    A    203.0.113.52

DNSがラウンドロビン方式で異なるIPを返し、トラフィックを複数サーバーに分散する。

よくある設定ミス

  • TTLを長く設定しすぎる：本番環境の変更前にはTTLを60〜300秒に下げ、移行完了後に3600秒に戻すこと
  • 関連レコードの更新漏れ：サーバーIPを変更する際、すべてのサブドメインのAレコードも確認すること
  • CNAMEとの競合：同一ドメイン名にAレコードとCNAMEレコードを同時に設定することはできない

AAAAレコード：IPv6対応の未来

AAAAレコード の機能はAレコードと同じだが、IPv4ではなくIPv6アドレスを指定する点が異なる。世界的なIPv4アドレスの枯渇に伴い、IPv6の普及が加速しており、Googleの統計では2025年時点で世界のIPv6採用率は45%を超えている。

設定構文

example.com.    3600    IN    AAAA    2001:0db8:85a3::8a2e:0370:7334

ベストプラクティス

AレコードとAAAAレコードの両方を設定するデュアルスタック構成を推奨する。これにより、IPv4とIPv6のどちらのネットワークからもドメインにアクセス可能となる：

example.com.    3600    IN    A       203.0.113.50
example.com.    3600    IN    AAAA    2001:db8::1

CNAMEレコード：柔軟なドメインエイリアス

CNAMEレコード（Canonical Name Record） は、あるドメイン名を別のドメイン名に向ける。本質的に「別名」の関係を作り出す仕組みである。

設定構文

www.example.com.     3600    IN    CNAME    example.com.
blog.example.com.    3600    IN    CNAME    hosting.provider.com.
shop.example.com.    3600    IN    CNAME    shops.myshopify.com.

重要な制約ルール

ルール1：ルートドメイン（Apex）にCNAMEは設定不可

以下の設定は誤りである：

example.com.    CNAME    other.com.    ← RFC 1912違反

ルートドメインにはAレコードを使用する必要がある。CDNやクラウドプラットフォームがCNAME接続を要求する場合は、ALIAS/ANAMEレコード（一部DNSプロバイダが対応）を代替手段として利用できる。

ルール2：CNAMEは他のレコードと共存不可

同一ドメイン名にCNAMEレコードが存在する場合、MX、TXTなど他のレコードタイプを追加することはできない。

AレコードとCNAMEレコードの選択ガイド

シナリオ推奨レコード理由
ルートドメインからサーバーを指定AルートドメインでCNAMEは使用不可
wwwサブドメインCNAME → ルートドメインルートドメインのIP変更に自動追従
CDNサービスへの接続CNAMECDNのIPは動的に変化しうる
SaaSプラットフォームへの接続CNAMEプラットフォームのIPはベンダー管理
IPの精密制御が必要A対象アドレスを直接指定

MXレコード：メールルーティングの要

MXレコード（Mail Exchange Record） は、あなたのドメイン宛に送信されたメールをどのサーバーに配信するかを指定する。

設定構文

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.
example.com.    3600    IN    MX    30    mail3.backup-mx.com.

優先度の数値が小さいほど、優先度が高い。上記の設定では、メールはまずmail1に配信され、mail1が利用不可ならmail2へ、最終手段としてバックアップサーバーに送られる。

主要メールサービスのMX設定

Google Workspace：

example.com.    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365：

example.com.    MX    0    example-com.mail.protection.outlook.com.

よくあるトラブルシューティング

  • メールが届かない：MXレコードが正しいメールサーバーを指しているか、優先度設定が適切か確認する
  • MXの値にIPアドレスを指定：MXレコードの値は必ずドメイン名でなければならない。そのドメイン名に対応するAレコードが別途必要
  • CNAME競合：サブドメインにCNAMEが設定されている場合、そのサブドメインにMXレコードは追加できない

TXTレコード：検証とセキュリティの万能コンテナ

TXTレコード はDNS上に任意のテキスト情報を格納できる。用途が極めて幅広く、現代のドメインセキュリティ設定の中核を担う。

設定構文

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

主な用途

1. SPFレコード（メール送信元偽装防止）

SPF（Sender Policy Framework）は、あなたのドメイン名でメールを送信する権限を持つサーバーを宣言する：

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

構文の解説：

  • include: — サードパーティサービスの送信ドメインを認可
  • ip4: — IPアドレス範囲を直接認可
  • -all — 厳格モード。リストにないサーバーからのメールを全て拒否（推奨）
  • ~all — ソフトフェイル。疑わしいとマークするが直接拒否はしない

重要： 2024年2月より、GoogleとYahooは1日5,000通以上のメールを送信するドメインに対してSPF、DKIM、DMARCの設定を義務化している。未対応のドメインからのメールは拒否またはスパムフォルダに分類される。

2. DKIMレコード（メール署名検証）

DKIM（DomainKeys Identified Mail）は、暗号署名によりメールが改竄されていないことを検証する：

selector1._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

設定手順：

  1. メールサービスプロバイダで鍵ペアを生成
  2. 公開鍵をTXTレコードとしてDNSに登録
  3. 送信されるメールには自動的に暗号署名が付与される
  4. 受信側がDNSから公開鍵を取得し署名を検証

2048ビット以上のRSA鍵の使用を推奨する。

3. DMARCレコード（認証ポリシーとレポート）

DMARC（Domain-based Message Authentication, Reporting & Conformance）は、SPF/DKIM認証に失敗したメールの処理方法を受信側に指示する：

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"

段階的な導入戦略を推奨：

フェーズポリシー説明推奨期間
監視p=noneレポート収集のみ。配信に影響なし2〜4週間
隔離p=quarantine認証失敗メールを迷惑メールフォルダへ2〜4週間
拒否p=reject認証に通らないメールを完全拒否長期運用

4. ドメイン所有権の確認

Google Search Console、クラウドプラットフォーム、各種SaaSサービスではTXTレコードによるドメイン所有権確認が頻繁に求められる：

example.com.    TXT    "google-site-verification=abcdefg12345"
example.com.    TXT    "v=verify; service=example-saas; id=123456"

NSレコード：権威DNS委任

NSレコード（Name Server Record） は、対象ドメインの権威ある名前解決を担うDNSサーバーを指定する。

設定構文

example.com.    86400    IN    NS    ns1.cloudflare.com.
example.com.    86400    IN    NS    ns2.cloudflare.com.

NSレコードを変更するケース

  • DNSプロバイダの変更：レジストラのデフォルトDNSからCloudflare、AWS Route 53など専門DNSサービスへの移行
  • サブドメインの委任：特定サブドメインの名前解決を別のDNSサーバーに委任
api.example.com.    NS    ns1.api-dns-provider.com.
api.example.com.    NS    ns2.api-dns-provider.com.

SOAレコード：ゾーンファイルのメタデータ

SOAレコード（Start of Authority） は、DNSゾーンの管理情報を格納する。各ゾーンに1つだけ存在する。

設定構文

example.com.    SOA    ns1.example.com. admin.example.com. (
    2026052201    ; シリアル番号（YYYYMMDD+連番の形式を推奨）
    7200          ; リフレッシュ間隔（秒）
    3600          ; リトライ間隔
    1209600       ; 有効期限
    86400         ; ネガティブキャッシュTTL
)

通常のユーザーがSOAレコードを手動で変更する必要はなく、DNSプロバイダが自動管理する。ただし、シリアル番号の仕組みを理解しておくとDNS同期の問題をトラブルシューティングする際に役立つ。ゾーンファイルを変更するたびにシリアル番号をインクリメントしなければ、セカンダリサーバーは更新を取得しない。

PTRレコード：逆引きDNS

PTRレコード（Pointer Record） はIPアドレスからドメイン名への逆引き解決を行う。A/AAAAレコードの「鏡像」ともいえる存在である。

設定構文

IPv4の逆引き解決では、IPアドレスのオクテットを逆順にし.in-addr.arpaサフィックスを付加する：

50.113.0.203.in-addr.arpa.    PTR    mail.example.com.

PTRレコードが重要な理由

メール配信がPTRレコードの最も重要な用途である。主要メールプロバイダ（Gmail、Outlook、Yahoo Mail）は、送信元IPのPTRレコードが送信ドメインと一致するかを検証する（FCrDNS検証）。PTRレコードが未設定または不一致のメールサーバーからのメールは、拒否されるかスパム判定を受ける可能性が高い。

PTRレコードの設定は、IPアドレスの割当元（通常はVPS/クラウドサーバープロバイダ）のコントロールパネルで行う。

SRVレコード：サービスディスカバリプロトコル

SRVレコード（Service Record） は、特定サービスを提供するホストとポートを指定する。VoIP、インスタントメッセージング、ゲームサーバーなどで利用される。

設定構文

_service._protocol.example.com.    SRV    priority weight port target

実際の例：

_sip._tcp.example.com.       SRV    10 60 5060 sip1.example.com.
_xmpp._tcp.example.com.      SRV    5  0  5222 xmpp.example.com.
_minecraft._tcp.example.com.  SRV    0  5  25565 mc.example.com.

代表的な利用場面

  • Microsoft Teams / Skype for Business：SRVレコードで通信サーバーを発見
  • SIP電話システム：VoIPデバイスがSIPサーバーを自動的に特定
  • XMPP / Jabber：IMクライアントがチャットサーバーを発見
  • ゲームサーバー：Minecraftなどのゲームでカスタムポートへの接続を実現

CAAレコード：SSL証明書発行の制御

CAAレコード（Certificate Authority Authorization） は、自ドメインのSSL/TLS証明書の発行を許可する認証局（CA）を指定する。証明書の誤発行を防ぐ重要なセキュリティ対策である。

設定構文

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:security@example.com"

タグの説明：

  • issue — 通常の証明書の発行を許可するCA
  • issuewild — ワイルドカード証明書の発行を許可するCA
  • iodef — 不正な発行試行時の通知先メールアドレス

今すぐCAAレコードを設定すべき理由

CA/B Forumは2025年4月にBallot SC-081v3を可決した。 SSL証明書の有効期間が段階的に短縮される：

施行時期最長有効期間影響
2026年3月200日証明書更新の頻度が増加
2027年3月100日自動更新が事実上必須に
2029年3月47日完全な自動化への依存

証明書更新頻度の大幅な増加により、自動化された発行フローが標準となる。CAAレコードを設定することで、自動化プロセスの中で許可されたCAのみが証明書を発行できるようになり、セキュリティ上の脆弱性を防止できる。

推奨設定パターン

Let’s Encrypt無料証明書を使用する場合：

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:admin@example.com"

複数のCAを同時に利用する場合：

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issue "digicert.com"
example.com.    CAA    0 issue "sectigo.com"

DNSレコード設定の判断フロー

具体的な要件に対して適切なレコードタイプを選択するためのフローチャート：

Webサイトへのアクセスを可能にしたい

  • ルートドメイン → Aレコード（サーバーIPを指定）
  • wwwまたは他のサブドメイン → CNAME（ルートドメインまたはCDNを指定）
  • IPv6アクセスが必要 → AAAAレコードも追加

メールを設定したい

  • メールルーティング → MXレコード
  • 送信認証 → TXTレコード（SPF + DKIM + DMARC）
  • メールサーバーの逆引き検証 → PTRレコード

ドメイン所有権を証明したい

  • Google / Microsoftなどのプラットフォーム認証 → TXTレコード

セキュリティを強化したい

  • SSL証明書発行の制限 → CAAレコード
  • DNSデータの完全性保護 → DNSSEC

特定サービスに接続したい

  • VoIP / IM / ゲーム → SRVレコード
  • CDN / SaaSプラットフォーム → CNAMEレコード

完全構築例：ドメインのDNS設定をゼロから行う

Nameslinkで新しいドメインを取得した直後の、完全なDNS設定フローを紹介する。

ステップ1：Webサイトの基本解決

example.com.       300    IN    A       203.0.113.50
example.com.       300    IN    AAAA    2001:db8::50
www.example.com.   300    IN    CNAME   example.com.

ステップ2：メールシステムの設定

; MXレコード
example.com.    MX    10    mail.example.com.
mail.example.com.    A    203.0.113.25

; SPF
example.com.    TXT    "v=spf1 ip4:203.0.113.25 include:_spf.google.com -all"

; DKIM
selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=公開鍵の内容"

; DMARC
_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

ステップ3：セキュリティ強化

; CAA - 証明書発行CAの制限
example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:admin@example.com"

ステップ4：TTL戦略

  • 安定運用時：TTLを3600秒（1時間）に設定
  • 変更予定前：事前にTTLを60〜300秒に引き下げ
  • 変更完了後：問題がないことを確認してから3600秒に復元

DNSトラブルシューティングツール

DNS設定が反映されない場合や異常が発生した場合に、以下のツールで原因を特定する。

コマンドラインツール

digコマンド（推奨）：

# Aレコードの確認
dig example.com A

# 特定のDNSサーバーを指定して問い合わせ
dig @8.8.8.8 example.com MX

# 完全な解決パスの追跡
dig +trace example.com

# TXTレコードの確認
dig example.com TXT

# CAAレコードの確認
dig example.com CAA

nslookupコマンド：

nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CAA example.com

オンライン検出ツール

ドメインの名前解決状態や利用可能なTLDをすばやく確認したい場合は、Nameslinkドメイン検出ツールが便利である。1,500種類以上のTLDに対応し、ミリ秒単位で検出結果を返す。DNS設定の前にドメインの状態を確認する用途に適している。

よくある問題の診断

症状考えられる原因確認方法
サイトにアクセスできないAレコードの誤り、または未反映dig example.com A
メールが届かないMXレコードの設定誤りdig example.com MX
メールが迷惑メールに入るSPF/DKIM/DMARCが未設定dig example.com TXT
SSL証明書の発行に失敗CAAレコードによる制限dig example.com CAA
DNS変更が反映されないTTLキャッシュの有効期限内TTL時間の経過を待つか、キャッシュをクリア

TTL設定のベストプラクティス

TTL（Time To Live）はDNSレコードがキャッシュされる期間を決定し、DNS変更の反映速度に直接影響する。

シナリオ推奨TTL理由
安定稼働中のサーバー3600〜86400秒DNSクエリを削減しアクセスを高速化
変更予定あり60〜300秒切替の待機時間を短縮
ロードバランシング60〜300秒ヘルスチェックへの迅速な応答
メール関連レコード3600秒メールルーティングには安定性が必要
CDN接続CDNの推奨値に従う通常300〜600秒

重要な原則： 計画的なDNS変更を行う際は、少なくとも1 TTL周期分の時間を事前に確保してTTLを引き下げておくこと。例えば現在のTTLが86400秒（24時間）であれば、少なくとも24時間前にTTLを300秒に変更し、その後にIPアドレスの変更を実行する。

よくある質問（FAQ）

DNSレコードの変更後、反映までどのくらいかかるのか

反映時間は、変更前のレコードのTTL値に依存する。 旧レコードのTTLが3600秒であれば、グローバルで最長1時間の待機が必要となる。実際には各階層のDNSキャッシュの存在により、完全な世界的反映には24〜48時間を要する場合がある。計画的な変更前には事前にTTLを引き下げることを推奨する。

AレコードとCNAMEレコードはどう使い分けるべきか

ルートドメインにはAレコードのみ使用可能、サブドメインにはCNAMEを優先する。 CNAMEの利点は、ターゲットアドレスが変更された際にサブドメインのレコードを個別に更新する必要がない点にある。ただし、同一ドメイン名にMXレコードやTXTレコードも設定する必要がある場合、そのドメイン名にCNAMEは使用できない。

SPFレコードが10回のDNSルックアップ制限を超えた場合の対処法

SPF標準では最大10回のDNSルックアップに制限されている（include/a/mxなどの機構が各1回とカウントされる）。 解決策としては以下がある：複数のincludeをip4/ip6による直接指定に統合する、SPFフラッテニングツールを使いネスト先ドメインをIPリストに展開する、異なる送信サービスを異なるサブドメインに分離する。

MXレコードを設定したのにメールが届かないのはなぜか

MXレコードの値はIPアドレスではなくドメイン名でなければならず、かつそのドメイン名に対応するAレコードが必要である。 また、MXの優先度設定が正しいか（数値が小さいほど優先度が高い）、ファイアウォールでポート25/587/993が開放されているかを確認すること。

CAAレコードは必ず設定しなければならないのか

CAAレコードの設定は義務ではないが、強く推奨される。 2017年以降、CAは証明書発行前にCAAレコードの確認が義務付けられている。CA/B ForumによるSSL証明書有効期間の47日への段階的短縮を受け、自動化された証明書更新が常態化する中、CAAレコードは未認可のCAによる誤発行を効果的に防止する。CAAレコードが未設定の場合、任意のCAがそのドメインの証明書を発行できてしまう。

まとめとアクションリスト

DNSレコードの設定は一見複雑に思えるが、核となるロジックを理解すればほとんどのシナリオに対応できる。以下に最も重要なアクションポイントをまとめる。

今すぐ確認すべきこと： 自ドメインにSPF、DKIM、DMARCが設定されているか。2024年2月以降、GoogleとYahooはメール認証未設定のドメインに対して厳格なフィルタリングを適用している。dig yourdomain.com TXT および dig _dmarc.yourdomain.com TXT で現在の状態を確認しよう。

近い将来の計画： CAAレコードを追加し、SSL証明書の発行CAを制限する。証明書有効期間が段階的に47日まで短縮される中、自動発行に対するセキュリティ防護の重要性が増している。

継続的なメンテナンス： DNSレコードを定期的に監査し、使用されていないレコードを削除してDNSゾーンファイルを整理する。四半期ごとのチェックを推奨し、すべてのレコードが正しいターゲットを指していることを確認すること。

新しいドメインの取得を検討している場合は、購入前にNameslinkドメイン評価ツールで総合的な価値を評価しておくことを推奨する。SEOウェイト、ブランド性、文字数など22項目の指標に基づいた分析は、DNS設定戦略の策定にも参考となる。

データソースと参考文献：

  • RFC 1035 — Domain Names: Implementation and Specification (IETF, 1987)
  • RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email (IETF, 2014)
  • RFC 6844 — DNS Certification Authority Authorization (CAA) Resource Record (IETF, 2013)
  • RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) (IETF, 2000)
  • CA/Browser Forum Ballot SC-081v3 — Reducing Validity Period of Subscriber Certificates (2025年4月可決)
  • Google Email Sender Guidelines — Bulk Sender Requirements (2024年2月施行)
  • Internet Society Global IPv6 Deployment Report (2025)

関連記事