ネットワーク
DNSレコード設定ガイド
A・MX・TXT・SPF・DKIM・DMARCなど、メール配信やサイト運用に必要なDNSレコードの種類・目的・書式例・注意点を一覧でまとめたリファレンスです。
DNSレコードタイプ一覧
| 種類 | 目的 | 書式例 | 注意点 |
|---|---|---|---|
| Aレコード | ドメイン名をIPv4アドレスに紐づける、最も基本的なレコードです。Webサーバーやメールサーバーの実体がどのIPアドレスにあるかを示します。 | example.com. 3600 IN A 192.0.2.1 |
TTL（この例では3600秒＝1時間）を短くしすぎると権威DNSサーバーへの問い合わせが増えて負荷が上がり、長くしすぎるとIPアドレス変更時の反映が遅れます。 |
| AAAAレコード | ドメイン名をIPv6アドレスに紐づけるレコードです。Aレコードのちょうど「IPv6版」にあたります。 | example.com. 3600 IN AAAA 2001:db8::1 |
IPv6未対応のネットワークでもAレコードを併記しておけばIPv4接続にフォールバックできます（デュアルスタック運用）。 |
| CNAMEレコード | あるホスト名を、別の正規のホスト名の別名（エイリアス）として扱うレコードです。例えば www.example.com を example.com の別名にする場合などに使います。 | www.example.com. 3600 IN CNAME example.com. |
CNAMEを設定したホスト名には他のレコード（MXやTXTなど）を共存させられません（RFC 1034の制約）。またゾーンのルート（@）にはCNAMEを設定できません。 |
| MXレコード | そのドメイン宛のメールをどのメールサーバーが受け取るかを指定するレコードです。優先度（プリファレンス値）付きで複数指定できます。 | example.com. 3600 IN MX 10 mail.example.com. |
優先度は値が小さいほど高くなります。冗長化のため優先度違いで複数台指定するのが一般的です。MXの向き先はCNAMEではなくAレコードを持つホスト名にする必要があります。 |
| TXTレコード | ドメインに任意のテキスト情報を持たせる汎用レコードです。SPF・DKIM・DMARCの他、ドメイン所有権確認など様々な用途に使われます。 | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
1つのドメインに複数のTXTレコードを設定できますが、同じ用途（SPFなど）のレコードを複数置くと解釈エラーになるため1つに統合する必要があります。 |
| SPFレコード（TXTレコードの一種） | そのドメインからのメール送信を許可された送信元サーバー（IPアドレス）を列挙し、なりすましメールを防ぐ送信ドメイン認証の仕組みです。TXTレコードとして設定します。 | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
SPFレコードは1ドメインにつき1つのみ有効です。DNSルックアップの上限（10回）を超えるとエラーになるため include の連鎖に注意しましょう。専用のレコード種別（RRTYPE 99）は2014年に廃止され、現在はTXTレコードのみで表現します。 |
| DKIMレコード（TXTレコードの一種） | メールに電子署名を付与し、送信中に改ざんされていないこと・正当な送信元から送られたことを検証する仕組みです。公開鍵をTXTレコードとして公開します。 | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
ホスト名の先頭（セレクタ部分）はメールサービスごとに異なる文字列が割り当てられます。秘密鍵は送信サーバー側で保持し、DNSには公開鍵のみを公開します。 |
| DMARCレコード（TXTレコードの一種） | SPF・DKIMの検証結果をもとに、認証に失敗したメールをどう扱うか（何もしない・迷惑メール行き・拒否）をポリシーとして宣言し、結果レポートを受け取る仕組みです。 | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
p=none から始めて監視だけを行い、問題がないことを確認してから quarantine・reject へ段階的にポリシーを強化するのが安全な移行手順です。 |
| NSレコード | そのドメイン（ゾーン）の権威DNSサーバーがどれかを示すレコードです。ドメイン全体の名前解決の起点になります。 | example.com. 86400 IN NS ns1.example-dns.com. |
レジストラに登録したネームサーバーとゾーン内のNSレコードが一致していないと、名前解決が不安定になります（レイム・デリゲーション）。 |
| SOAレコード | ゾーンの管理情報（プライマリサーバー・管理者メール・シリアル番号・再試行間隔など）を保持する、ゾーンに必ず1つ存在する必須レコードです。 | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
ゾーンファイルを更新したらシリアル番号を必ずインクリメントしないと、セカンダリサーバーへの変更反映（ゾーン転送）が行われません。 |
| CAAレコード | そのドメインに対して証明書を発行できる認証局（CA）を制限し、意図しないCAによる不正な証明書発行を防ぐレコードです。 | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
CAAレコードが1つも存在しない場合はどのCAでも発行可能とみなされます。ワイルドカード証明書用には issuewild タグを別途指定する必要があります。 |
| PTRレコード | IPアドレスからホスト名を逆引きするレコードです（Aレコードの逆方向）。逆引きゾーン（in-addr.arpa / ip6.arpa）に設定します。 | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
多くのメールサーバーは、逆引きPTRが未設定・Aレコードと不一致の送信元からのメールを迷惑メール判定・拒否するため、メール送信サーバーには必須級の設定です。 |
Tips
- SPF・DKIM・DMARCの設定に迷ったら、まず「SPF/DKIM/DMARCレコードチェック」ツールで現在のレコードを診断してから、本ページの書式例と見比べると効率的です。
- TTLは通常のレコードなら1時間（3600秒）程度が無難ですが、DNS移行作業の直前だけ300秒程度に短縮しておくと、切り替え後の反映がスムーズになります。
- TXTレコードの値は255文字を超えると複数の文字列に自動分割されることがあるため、コピー＆ペースト時に引用符の数がずれていないか確認しましょう。
- メールアドレスの形式そのものをチェックしたい場合は、「メールアドレス形式チェック」ツールも合わせて使うと確認漏れを防げます。
- 新しいメール配信サービスを導入する際は、まずDMARCを p=none で運用してレポートを1〜2週間確認し、問題がないことを確かめてから本番のポリシーに切り替えると安全です。
よくある質問
SPFは「どのサーバーから送信されたか」というIPアドレスの正当性を検証する仕組みで、DKIMは「メールの内容が改ざんされていないか」を電子署名で検証する仕組みです。両方が合格して初めて、送信ドメイン認証として十分な効果を発揮します。
法的な必須要件ではありませんが、GmailやYahoo!メールなど主要な受信サーバーは大量送信者に対しDMARC設定を事実上必須化しており、未設定だと迷惑メール判定や配信拒否のリスクが高まります。
MXの向き先がCNAMEになっている、優先度の値を誤って設定している、あるいはメールサーバー側でそのドメイン宛のメールを受け付ける設定になっていないことが主な原因として考えられます。
IPアドレスが固定でドメイン直下（@）に設定したい場合はA/AAAAレコード、他のホスト名のエイリアスとして扱いたい場合（CDNのURLを指す等）はCNAMEを使うのが基本です。
通常運用では1時間（3600秒）前後が一般的です。サーバー移行やDNS切り替えの直前だけ300秒程度に短縮しておくと、切り替え後の反映が早くなります。
余談ですが ― DNSレコードとメール認証の歴史
DNSはドメイン名とIPアドレスを結びつける仕組みとして知られていますが、実際にはA・AAAAレコード以外にも多くの種類が定義されており、それぞれが異なる役割を担っています。特にメール配信の世界では、MX・TXT（SPF/DKIM/DMARC）・PTRといった複数のレコードが連携して初めて「なりすましでない正当なメール」と判定される仕組みになっており、どれか1つでも欠けると迷惑メールフォルダ行きや配信拒否のリスクが高まります。
送信ドメイン認証の歴史を振り返ると、SPFは2000年代前半に迷惑メール対策として提案され、その後メール本文の改ざん検知を目的としたDKIMが2007年頃に標準化されました。しかし両者はそれぞれ単独では「認証に失敗した場合にどう扱うか」を定めておらず、その空白を埋めるために2012年にDMARCが登場しました。DMARCはSPF・DKIMの結果を統合的に評価し、失敗時のポリシーと結果レポートの仕組みを提供する、いわば「認証の司令塔」的な存在です。
DNSレコードの中には歴史的経緯で仕様が変わったものもあります。例えばSPF専用のレコードタイプ（RRTYPE 99）は2006年のRFCで一度定義されましたが、実装上の混乱を招いたため2014年にRFC 7208で正式に廃止され、現在はTXTレコードのみでSPFを表現するのが標準です。同様にDKIMやDMARCも専用のレコードタイプを持たず、すべてTXTレコードの中に特定の書式（v=DKIM1、v=DMARC1で始まる文字列）を埋め込む形で実装されている点も、DNSの拡張性の高さを物語っています。