DNSの設定項目の中で、「TXTレコード」は少し地味な存在に見えるかもしれません。
しかし実際には、ドメインの所有権確認・メール認証・スパム対策など、現代のインターネット運用において欠かせない役割を担っています。
この記事では、TXTレコードの意味・主な用途・設定方法について、所有権確認・SPF・ドメインといったキーワードを交えながらわかりやすく解説していきます。
DNS設定を正しく理解したい方にとって、必ず押さえておきたい内容です。
TXTレコードとはドメインに任意のテキスト情報を登録できるDNSレコードのこと
それではまず、TXTレコードの基本的な意味と役割について解説していきます。
TXTレコードの「TXT」は「Text（テキスト）」の略であり、ドメインに対して任意の文字列（テキスト情報）を登録できるDNSレコードです。
もともとはドメインに関するメモや説明文を自由に記載するために設計されたレコードですが、現在ではメール認証・ドメイン所有権確認・セキュリティポリシーの定義など、多彩な用途に活用されています。
TXTレコードは1つのドメインに対して複数設定することが可能であり、用途ごとに独立したレコードとして管理できます。
TXTレコードは「DNSの掲示板」とも例えられます。
ドメインの管理者だけが書き込める性質を活かして、外部サービスやセキュリティシステムがそのドメインの正当性や設定内容を確認するために広く利用されています。
現代のドメイン運用において、TXTレコードはAレコードやMXレコードと並ぶ重要なレコードの一つです。
TXTレコードの基本構造
TXTレコードはホスト名・レコードタイプ・TTL・テキスト値で構成されています。
設定例：
example.com TXT 3600 ”v=spf1 include:_spf.google.com ~all”
この場合、「example.com」というドメインにSPF認証情報を記したテキスト値が登録されています。
テキスト値はダブルクォーテーションで囲まれた文字列として記述します。
1つのTXTレコードに記録できる文字列の長さには上限があり、255文字を超える場合は複数の文字列を連結して記述します。
記述内容はサービスや用途ごとに定められた書式に従う必要があるため、設定前に必ず公式ドキュメントを確認しましょう。
TXTレコードが複数設定できる理由
AレコードやMXレコードと同様に、TXTレコードも1つのドメインに対して複数設定が可能です。
これはSPF・DKIM・ドメイン所有権確認など、異なる目的のテキスト情報を同時に管理する必要があるためです。
ただし、SPFレコードは同一ドメインに複数設定すると認証エラーの原因になるため、SPFは必ず1つのTXTレコードにまとめることがルールとなっています。
複数のメール送信サービスを利用している場合は、include構文を使って1つのSPFレコードに統合することが正しい設定方法です。
TXTレコードの確認方法
設定済みのTXTレコードは以下のコマンドで確認できます。
確認コマンド例（Windowsの場合）：
nslookup -type=TXT example.com
確認コマンド例（Mac・Linuxの場合）：
dig example.com TXT
オンラインツール「MXToolbox」や「Google Admin Toolbox」でも手軽に確認できます。
設定後は必ず確認を行い、意図した内容が正しく登録されているかを検証することが重要でしょう。
TXTレコードの主な用途と活用例
続いては、TXTレコードが実際にどのような場面で使われているかを確認していきます。
TXTレコードの用途は多岐にわたり、それぞれが現代のインターネット運用において重要な役割を担っています。
ドメイン所有権の確認
Google Search ConsoleやGoogle Workspace・Microsoft 365などの外部サービスを利用する際、ドメインの所有者であることを証明するためにTXTレコードが使われます。
サービス側から発行された固有の文字列をTXTレコードとして登録することで、そのドメインの管理権限を持つ正当な所有者であることが確認できます。
| サービス名 | TXTレコードの用途 | レコード例 |
|---|---|---|
| Google Search Console | サイト所有権の確認 | google-site-verification=xxxx |
| Google Workspace | ドメイン所有権の確認 | google-site-verification=xxxx |
| Microsoft 365 | ドメイン所有権の確認 | MS=msxxxxxxxxxxxx |
| Zendesk | ドメイン認証 | zendesk-verification=xxxx |
TXTレコードによる所有権確認は、DNS設定を変更できる者だけが正当な管理者であるという前提に基づいた安全な認証方式です。
SPFレコードによるメール送信元認証
SPF（Sender Policy Framework）は、メールの送信元ドメインを詐称するなりすましメールを防ぐための仕組みです。
SPFの設定内容はTXTレコードとしてDNSに登録し、そのドメインから送信を許可するメールサーバーのIPアドレスや外部サービスを定義します。
受信側のメールサーバーはSPFレコードを参照し、送信元IPアドレスがリストに含まれているかを確認することでなりすましを検出します。
SPFレコードの設定例：
“v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.1 ~all”
「v=spf1」はSPFバージョンを示し、「include」で許可する外部サービスを指定します。
末尾の「~all」はリスト外のサーバーからの送信をソフトフェイル（警告扱い）とすることを意味します。
SPFレコードはメールセキュリティの基本中の基本であり、独自ドメインでメールを送信するすべての事業者が設定すべき項目です。
DKIMレコードによるメール署名の公開鍵登録
DKIM（DomainKeys Identified Mail）は、送信したメールに電子署名を付加することでメールの改ざんを検知する仕組みです。
送信側のメールサーバーが秘密鍵でメールに署名し、受信側は対応する公開鍵を使って署名を検証します。
この公開鍵の情報が、TXTレコードとしてDNSに登録されます。
DKIMレコードの設定例：
ホスト名：selector._domainkey.example.com
値：”v=DKIM1; k=rsa; p=MIGfMA0GCSqGS…”
「selector」はメールサービスごとに異なる識別子で、複数のサービスを使う場合はそれぞれ別のselectorで登録します。
DKIMはメールの内容が送信途中で改ざんされていないことを保証するため、フィッシングメール対策として非常に重要な役割を果たします。
TXTレコードとDMARCの関係
続いては、TXTレコードを使って設定するDMARCの仕組みと重要性について確認していきます。
SPF・DKIMと合わせてDMARCを理解することで、メールセキュリティの全体像が見えてきます。
DMARCとは何か
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPFとDKIMの認証結果に基づいてメールの取り扱いポリシーを定義する仕組みです。
認証に失敗したメールをどう扱うか（何もしない・隔離・拒否）をDNSのTXTレコードとして宣言することで、受信側のメールサーバーに処理方針を伝えます。
さらに認証失敗レポートを受け取るメールアドレスも指定でき、自ドメインのなりすまし状況を把握できます。
DMARCレコードの構造と設定例
DMARCレコードは「_dmarc.ドメイン名」というホスト名でTXTレコードとして登録します。
DMARCレコードの設定例：
ホスト名：_dmarc.example.com
値：”v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com; pct=100″
「p=quarantine」は認証失敗メールを隔離（迷惑メールフォルダへ）することを指定します。
「p=reject」に設定すると認証失敗メールを完全に拒否します。
DMARCのポリシーは「none（監視のみ）→ quarantine（隔離）→ reject（拒否）」の順に段階的に強化するのが一般的な運用方針でしょう。
SPF・DKIM・DMARCの三つの関係
メールセキュリティにおけるSPF・DKIM・DMARCの関係を整理すると、以下のようになります。
| 技術 | 役割 | TXTレコードの使い方 |
|---|---|---|
| SPF | 送信元IPアドレスの正当性を検証 | 許可する送信サーバーをTXTレコードに記載 |
| DKIM | メール内容の改ざん検知 | 公開鍵をTXTレコードに登録 |
| DMARC | SPF・DKIM失敗時の処理ポリシーを定義 | ポリシー情報をTXTレコードに記載 |
SPF・DKIM・DMARCの三つはメールセキュリティの三本柱です。
三つすべてをTXTレコードとして正しく設定することで、なりすましメール・フィッシング・スパムへの対策が大幅に強化されます。
2024年以降、GmailやYahoo!MailではSPF・DKIM・DMARCの設定を送信ドメイン認証の要件として求めており、設定なしではメールが届きにくくなる可能性があります。
TXTレコードのその他の活用例と設定時の注意点
続いては、TXTレコードのその他の活用事例と、設定時に気をつけるべきポイントを確認していきます。
その他のTXTレコード活用例
TXTレコードはSPF・DKIM・DMARC・ドメイン所有権確認以外にも、さまざまな場面で活用されています。
| 用途 | 概要 |
|---|---|
| BIMI（Brand Indicators for Message Identification） | 認証済みメールにブランドロゴを表示させる仕組み |
| Let’s Encrypt DNS-01チャレンジ | SSL証明書取得時のドメイン所有権確認 |
| Keybaseの所有権証明 | 暗号鍵とドメインの紐付けによる本人確認 |
| Adobe・HubSpotなどのSaaS認証 | 各種SaaSサービスのドメイン所有権確認 |
TXTレコードはその汎用性の高さから、今後もさまざまな新しい用途で活用される可能性があるでしょう。
TXTレコード設定時のよくあるミス
TXTレコードの設定でよく発生するミスとして、SPFレコードの二重登録・記述書式のエラー・ダブルクォーテーションの付け忘れなどが挙げられます。
特にSPFレコードを複数設定してしまうと認証が正常に機能しなくなるため、必ず1つのTXTレコードにまとめることを徹底してください。
また、クォーテーション記号の種類（半角・全角）を誤ると値が正しく認識されないため、設定画面への入力時には細心の注意が必要です。
TXTレコードのTTL設定のポイント
TXTレコードのTTLは、用途によって適切な値が異なります。
ドメイン所有権確認用のレコードは一時的に設定するものであれば短めのTTL（300〜600秒）でも問題ありませんが、SPFやDKIM・DMARCなど継続的に参照されるレコードは3600〜86400秒程度が適切でしょう。
設定変更の予定があるレコードは事前にTTLを短縮しておくと、変更後の浸透時間を短縮できます。
TTLの管理もTXTレコードの安定した運用には欠かせないポイントの一つです。
まとめ
この記事では、DNSのTXTレコードの意味・主な用途・DMARCとの関係・設定時の注意点について解説しました。
TXTレコードはドメインに任意のテキスト情報を登録できる汎用的なDNSレコードであり、ドメイン所有権確認・SPF・DKIM・DMARCなど現代のインターネット運用に不可欠な役割を担っています。
特にメールセキュリティの観点では、SPF・DKIM・DMARCの三つをTXTレコードとして正しく設定することが、なりすましやフィッシング対策の基本となります。
GmailやYahoo!Mailなど主要なメールサービスでもこれらの設定が要件化されており、設定の重要性はますます高まっているといえるでしょう。
TXTレコードへの正しい理解と適切な設定が、安全で信頼性の高いドメイン運用の基盤となります。
ぜひ本記事を参考に、自身のドメインのTXTレコードを見直してみてください。
