Aレコード・CNAME・MX・TXTの違いと使い分け

Aはドメイン名とIPv4アドレスを結び付ける設定、CNAMEは別名、MXはメールの受信先、TXTは認証などに使う文字列です。同じDNSの画面へ登録しますが、それぞれ役割が違います。

例えば、Webサーバーだけ変えるならAやCNAMEが関係し、メールをGoogle Workspaceなどへ移すならMXと認証用のTXTなどが関係します。以下では、入力する値の例と、間違えやすい使い方を説明します。

レコードは名前・種類・値・TTLを一組で読む

DNS管理画面には、ホスト名・種別・内容・TTLなどの入力欄があります。ホスト名は問い合わせ対象です。種別は値の解釈方法、内容は実際の接続先や文字列を示します。

TTLは回答をキャッシュしてよい時間です。画面によってはホスト名を「名前」、内容を「値」または「データ」と表示します。

ドメイン直下を@で表す画面もありますが、@はDNS上の共通レコード名ではなく、管理画面がルート名を表すための記号です。wwwだけを入力すると自動的にドメイン名が補われる画面もあれば、www.example.jpまで必要な画面もあります。提供元の入力例が完全な名前か、画面が末尾のドメインを補うかを確認してください。

4種類の基本的な対応は次のとおりです。値は説明用であり、実際の設定には契約先が発行した値を使います。

TTLの単位は通常秒ですが、選択式の管理画面もあります。変更前に短くすれば古い回答が残る時間を抑えられます。ただし、すでにキャッシュされた回答は、設定時のTTLが満了するまで残る可能性があります。

Aレコードは名前をIPv4アドレスへ向ける

Aレコードは、ドメイン名をIPv4アドレスへ結び付けます。Webサイトでよく使われますが、Aレコードそのものに「Web専用」という意味はありません。指定した名前への問い合わせに、IPv4アドレスを返すレコードです。IPv6アドレスには別のAAAAレコードを使います。

example.jpとwww.example.jpは別の名前です。ドメイン直下のAレコードを変更しても、wwwが別のAレコードを持っていれば自動では変わりません。反対に、wwwがドメイン直下を参照するCNAMEなら、参照先のAレコード変更が結果へ反映されます。

サーバー移転でAレコードを変更するときは、新サーバーに対象ドメインを設定し、HTTPSとコンテンツを確認してから値を変えます。IPアドレスだけを先に変更すると、サーバーがそのドメインを受け付けず、別サイトやエラーが表示される場合があります。

CNAMEはURL転送ではなく別名を作る

CNAMEは、ある名前を別の正式な名前へ結び付けます。たとえばwww.example.jpをexample.jpの別名として扱う用途です。値に入れるのはホスト名であり、https://example.jp/service/のようなURLやパスではありません。ブラウザのアドレスを別URLへ転送したい場合は、Webサーバー側のリダイレクトを使います。

RFC 1034とRFC 2181では、CNAMEを置いた名前に他種類のデータを共存させないことが示されています。wwwにCNAMEとTXTを同時に置く、といった構成は避けます。DNSSECの署名用レコードなどプロトコル上の例外はありますが、一般の管理画面で利用者が混在させるものではありません。

ドメイン直下にはMXやTXTなども置くため、標準的なCNAMEと両立しません。DNS事業者によってはALIAS・ANAME・CNAME flatteningなどの独自機能があります。標準CNAMEと同じ仕様だとは限りません。利用条件と返されるレコードを公式マニュアルで確認します。

MXは受信メールを渡すサーバーを決める

MXレコードは、独自ドメイン宛のメールをどのサーバーへ配送するかを示します。値には優先度とメールサーバーのホスト名を登録します。RFC 5321では、優先度の数値が小さい配送先を先に扱います。管理画面が優先度を別欄に分けている場合は、値へ重ねて書きません。

MXの配送先へIPアドレスを直接入れることはできません。さらに、配送先のホスト名はCNAMEの別名ではなく、AまたはAAAAでアドレスへ解決できる名前が必要です。複数のMXを指定された場合は、任意に減らさないでください。優先度もサービスの案内どおりに登録します。

MXを変更しても、過去の受信メールやメールソフトの設定は移りません。また、メールの送信元を認証するSPF・DKIM・DMARCも別のレコードです。実際の切り替えでは「MXレコード変更前後に確認するメール停止防止チェックリスト」の順番で、新しい受信箱を先に用意します。

TXTは名前と文字列で用途が決まる

TXTは文字列を保持する汎用レコードです。「TXTを追加する」という指示だけでは、何の設定か判断できません。ドメイン直下のSPFとselector._domainkeyに置くDKIM公開鍵は別用途です。

_dmarcに置くDMARCや外部サービスの所有確認もあります。名前と値の書式を合わせて用途を見分けます。

SPFは、そのドメインを送信元として利用できるサーバーを示します。RFC 7208では、対象となる名前に複数のSPFポリシーが見つかると評価できません。メールサービスを追加するときは、v=spf1で始まるTXTをもう一本作るのではなく、既存の送信経路を確認したうえで一つのポリシーへ反映します。

DKIMは送信メールの署名を検証する公開鍵です。セレクターが異なれば複数のTXTを併用できます。DMARCは_dmarcという別名にポリシーを置き、SPFまたはDKIMの結果とFromドメインの整合を使います。これらは同じTXTでも役割が違うため、複数サービスの値を一つの文字列へ連結しません。

よくある取り違え

CNAMEへURLを書いても、別ページへの転送にはなりません。MXを変えても、過去メールは新しいサーバーへ移りません。TXTも、異なるサービスの値をまとめて一本にすれば良いわけではありません。

設定後に確認する種類も同じです。AならA、MXならMXを問い合わせます。管理画面に保存した値が返らない場合は、現在使われているDNSと、編集したDNSが違うこともあります。

値が正しくても、古い回答がキャッシュに残る場合があります。何度も値を変える前に、編集先のネームサーバーとTTLを見ると切り分けやすくなります。設定に使うのは、この記事の例示値ではなく、契約先が自社の環境向けに発行した値です。