## この記事でわかること

- 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レコードの種類をわかりやすく](/blog/dns-record-types)で全体像を把握しておくと理解しやすくなります。本記事ではそのうちのTXTレコードに絞って、よく使われる4つの用途を順に見ていきます。

![TXTレコードの代表的な4つの用途](/blog/txt-record-basics/txt-uses-overview.svg)

## 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 担当者向けの入門ガイド](/blog/spf-basics-smb)でまとめています。

### 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:reports@example.co.jp"
```

`p=none` は「監視のみ、通常配送する」という意味で、最初の段階ではここから始めるのが安全です。詳しくは[DMARCとは｜なぜ今ほぼ必須なのか](/blog/what-is-dmarc)を参照してください。

### 4. ドメイン所有確認

Google Workspace、Microsoft 365、各種SaaSにドメインを登録する際、「このドメインの管理権限を本当に持っていますか？」と確認するためにTXTレコードが使われます。

設定例:

```
google-site-verification=abc123XYZ...
```

`v=` で始まる認証用のレコードと違い、所有確認用は固定文字列がそのまま値になっているのが特徴です。SSL証明書の自動発行で使われるLet's EncryptのDNS-01認証も、同じくTXTレコードに一時的なトークンを置いて検証します。

![TXTレコード設定例の対比](/blog/txt-record-basics/txt-examples-table.svg)

## 設定時に押さえておきたい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が何かが見えてきます。社内で確認しづらい場合は、外部の事業者で運用代行を頼む選択肢もあります。具体的には[ドメイン管理を外注するという選択肢](/blog/domain-management-outsource)で考え方を整理しています。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。