TXTレコードとは｜わかりやすく例つき解説
目次
この記事でわかること
- TXTレコードは「DNSに任意の文字列を載せるための汎用的な箱」であること
- SPF、DKIM、DMARC、ドメイン所有確認の4つの代表的な使い道と、それぞれの書き方の違い
- 設定時に注意したい255文字制限と、複数のTXTを共存させるときの考え方
TXTレコードとは｜DNSに文字列を置ける汎用の箱
TXTレコードは、DNS（ディーエヌエス、Domain Name System）に任意の文字列を載せるためのレコードです。AレコードがIPアドレスを、MXレコードがメールサーバーを宣言するのに対して、TXTレコードは「このドメインに、この文字列を関連づけておきます」とだけ宣言します。
ポイントは、TXTレコード自体は中身の意味を決めていないということです。値として書かれた文字列を「どう解釈するか」は、その文字列を読む側のソフトウェアが決めます。たとえば値の先頭が v=spf1 で始まっていればメールサーバー側がSPFとして読み、v=DKIM1 で始まっていればDKIMの公開鍵として読みます。同じTXTレコードでも、書く内容によってまったく違う役割を担います。
DNSレコード全体の中での位置づけは、別記事のDNSレコードの種類をわかりやすくで全体像を把握しておくと理解しやすくなります。本記事ではそのうちのTXTレコードに絞って、よく使われる4つの用途を順に見ていきます。
4つの代表的な使い方
実務でTXTレコードに触れる場面は、ほぼ次の4つに集約されます。それぞれ別ものに見えても、同じTXTレコードという器を使い分けているだけです。
1. SPF（エスピーエフ、Sender Policy Framework）
SPFは「このドメインから正規にメールを送ってよいサーバーはどこか」を宣言する仕組みです。受信側のメールサーバーは、届いたメールの送信元IPアドレスを、ドメインに登録されたSPFのTXTレコードと照合し、許可された送信元かを判定します。
設定例（ドメイン直下に登録）:
v=spf1 include:_spf.google.com ~all
Google Workspaceでメールを送る場合の典型的な書き方です。SPFレコードの仕様や注意点はSPFとは｜Web 担当者向けの入門ガイドでまとめています。
2. DKIM（ディーキム、DomainKeys Identified Mail）
DKIMは、送信側がメールに電子署名を付け、受信側が公開鍵で検証する仕組みです。その公開鍵を載せるのがTXTレコードです。
設定例（ホスト名は セレクタ._domainkey）:
google._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
google の部分は「セレクタ」と呼ばれ、メールを送るサービスごとに異なります。Google Workspaceなら google、Microsoft 365なら selector1 のように、提供元の指示通りに設定します。
3. DMARC（ディーマーク、Domain-based Message Authentication, Reporting and Conformance）
DMARCは、SPFとDKIMの結果を踏まえて「認証に失敗したメールをどう扱ってほしいか」を受信側に伝える仕組みです。
設定例（ホスト名は _dmarc）:
_dmarc TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
p=none は「監視のみ、通常配送する」という意味で、最初の段階ではここから始めるのが安全です。詳しくはDMARCとは｜なぜ今ほぼ必須なのかを参照してください。
4. ドメイン所有確認
Google Workspace、Microsoft 365、各種SaaSにドメインを登録する際、「このドメインの管理権限を本当に持っていますか？」と確認するためにTXTレコードが使われます。
設定例:
google-site-verification=abc123XYZ...
v= で始まる認証用のレコードと違い、所有確認用は固定文字列がそのまま値になっているのが特徴です。SSL証明書の自動発行で使われるLet's EncryptのDNS-01認証も、同じくTXTレコードに一時的なトークンを置いて検証します。
設定時に押さえておきたい3つのポイント
1文字列は255文字まで、それを超えるなら複数文字列に分割
TXTレコードの1つの文字列は255文字までという仕様上の制限があります。DKIMのように公開鍵が長くなる場合、255文字を超えるなら複数の文字列に分けてダブルクォートで連結します。多くのDNS管理画面（Cloudflare、お名前.comなど）は、長い値を貼り付けると自動で分割してくれるので、利用者が手動で分ける必要はほとんどありません。
同じホスト名に複数のTXTを共存できる
ドメイン直下にSPFのTXTと所有確認のTXTを両方登録するなど、同じホスト名に複数のTXTレコードを並べることは仕様上問題ありません。ただし、SPFの行を2つ書いてしまうと多くの実装でエラー（permerror）になり、メールが認証失敗します。SPFの行は必ず1ドメインにつき1本にまとめるのが鉄則です。
TTL（ティーティーエル）は変更前に短くしておく
TTLはレコードのキャッシュ保持時間です。値を更新しても、世界中のDNSサーバーが古い値を持ち続けている間は新しい値が反映されません。設定変更を予定している場合は、変更の数時間前にTTLを300秒（5分）程度に短くしておくと、切り替えが素早く済みます。デフォルトのTTLは事業者によって3,600秒（1時間）や86,400秒（24時間）に設定されていることが多く、何も意識しないまま変更すると数時間〜1日ほど反映が遅れる可能性があります。
まずは現状確認から始める
TXTレコードを実際に追加・編集する場所は、ドメインのDNSを管理している事業者の管理画面です。Cloudflareで管理しているならCloudflareの「DNS」メニュー、お名前.comでDNSも管理しているならお名前.comの「DNS設定」メニュー、レンタルサーバーに預けているなら各社のサーバー管理画面、というように分かれます。「ネームサーバーがどこを向いているか」で、編集すべき画面が決まります。レジストラの画面でレコードを書いても、ネームサーバーがCloudflareを向いていれば反映されません。
DKIMの公開鍵やDMARCのポリシーは、後から少しずつ整えていくものです。まずは「自社のドメインに、いまどのTXTレコードがあるのか」を確認するところから始めるのが安全です。設定済みのSPFがあるか、DKIMのセレクタはどれが使われているか、DMARCはまだ未設定か。それらを把握できれば、追加で必要なTXTが何かが見えてきます。社内で確認しづらい場合は、外部の事業者で運用代行を頼む選択肢もあります。具体的にはドメイン管理を外注するという選択肢で考え方を整理しています。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。