TXTレコードとSRVレコードは、同じドメインの中で問題なく併用でき、同じ名前に両方を置くこともできます。併用でつまずくのは、どちらを「どの名前」に置くかと、管理画面の入力欄に名前を正しく入れられているかの2点です。この記事では、2つのレコードがよく一緒に使われる場面（メールクライアントの自動設定、クラウドサービスの導入、DNS-SDによるサービスの案内）を例に、ゾーンの書き方、よくある誤り、dig を使った確認方法を説明します。
SRVとTXTの役割の違い
2つのレコードは、役割がはっきり分かれています。
- SRVレコード: 「このサービスは、どのホストの何番ポートで提供しているか」を案内します。名前は
_サービス名._プロトコル.ドメインの形で、値は優先度・重み・ポート・ターゲット（ホスト名）の4つです。 - TXTレコード: 任意の文字列を載せるレコードです。SPFやDMARCのようなメール認証、ドメインの所有確認、サービスの付加情報など、用途ごとに決まった書式の文字列を置きます。
SRVはサービスの「場所」、TXTは「認証や設定の情報」と覚えておくと、どちらに何を書くかで迷いにくくなります。どちらもCNAMEとは違い、同じ名前にほかの種類のレコードと並べて置けます。同じ名前にCNAMEを置くと、SRVもTXTも置けなくなる点には注意してください。
アンダースコアで始まる名前
SRVの名前（_submission._tcp など）と、DMARCのTXT（_dmarc）やDKIMのTXT（selector._domainkey）は、どちらもアンダースコアで始まるラベルを使います。この形は「この名前は特定の用途のためのもの」という目印で、RFC 8552 で登録の仕組みが定められています。
併用の場面では、SRVとTXTの多くがこのアンダースコア付きの名前に並ぶことになります。管理画面によってはホスト名の欄でアンダースコアを入力できない、または警告が出ることがあるので、入力できない場合はDNSサービスのサポート情報を確認してください。
場面1：メールクライアントの自動設定とメール認証
メールクライアントに受信・送信サーバーを案内するSRVレコードは RFC 6186 と RFC 8314 で定められています。送信ドメイン認証のTXTレコードと組み合わせると、ゾーンは次のようになります。
; メールクライアント向けの案内（SRV）
_submissions._tcp.example.com. 3600 IN SRV 0 1 465 mail.example.com.
_submission._tcp.example.com. 3600 IN SRV 0 1 587 mail.example.com.
_imaps._tcp.example.com. 3600 IN SRV 0 1 993 mail.example.com.
; 提供していないサービスは、ターゲットを "." にして「無い」ことを示す
_imap._tcp.example.com. 3600 IN SRV 0 0 0 .
_pop3._tcp.example.com. 3600 IN SRV 0 0 0 .
; 送信ドメイン認証（TXT）
example.com. 3600 IN TXT "v=spf1 mx ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"SRVの値は「優先度 重み ポート ターゲット」の順です。優先度は小さいほど先に使われ、同じ優先度の中では重みの比率で振り分けられます。ターゲットにはA/AAAAレコードを持つホスト名を書き、末尾にドット（.）を付けます。
ただし、メールクライアントがSRVを参照するかどうかは製品によって異なります。独自の自動設定の仕組みを優先するクライアントも多いため、SRVを置けば自動設定がすべてのクライアントで効く、とは考えないでください。SPFやDMARCのTXTは、SRVの有無とは関係なく、メールの到達性に影響します。WordPressからのメール送信にも関わるのはこちらのTXTの方です。
場面2：クラウドサービスの導入
グループウェアや通話サービスなどを導入するとき、管理画面から「ドメイン所有確認のTXT」と「サービス用のSRV」をまとめて登録するよう求められることがあります。この場合は、サービスの管理画面に表示された値をそのまま使うのが原則です。必要なレコードの種類や値はサービス側の仕様変更で変わることがあるため、古い手順書や他人のブログの値を流用せず、導入時点の公式の案内を確認してください（2026年10月現在）。
所有確認のTXTは、ドメインの頂点（example.com）に置くよう指示されることが多く、SPFのTXTと同じ名前に並びます。TXTは同じ名前に複数置けるので、既存のSPFを書き換えずに、新しいTXTを1行追加します。
場面3：DNS-SDでサービスを案内する
DNS-SD（RFC 6763）は、ネットワーク上のサービスをDNSで見つけるための仕組みで、SRVとTXTを対にして使います。サービスの個々の提供元（インスタンス）ごとに、同じ名前でSRVとTXTを置きます。
; サービスの一覧（PTR）
_http._tcp.example.com. 3600 IN PTR docs._http._tcp.example.com.
; インスタンスの場所（SRV）と付加情報（TXT）を同じ名前に置く
docs._http._tcp.example.com. 3600 IN SRV 0 0 443 web.example.com.
docs._http._tcp.example.com. 3600 IN TXT "path=/manual/"DNS-SDではTXTは付加情報が無い場合でも置くことになっており、key=value の形で情報を並べます。SRVとTXTが同じ名前に並ぶ典型的な例です。
よくある誤り
1. ドメイン名が二重に付いている
管理画面の名前の欄にはドメインを省いた部分（_submission._tcp）を入れる仕様なのに、_submission._tcp.example.com まで入れてしまい、実際の名前が _submission._tcp.example.com.example.com になる誤りです。SRVでもTXTでも起こります。dig で意図した名前を問い合わせて答えが無ければ、まずこれを疑います。
2. SRVのターゲットがCNAMEやIPアドレスになっている
SRVのターゲットは、A/AAAAレコードを直接持つホスト名でなければなりません（RFC 2782）。IPアドレスは書けず、CNAMEの名前を指すことも認められていません。クライアントによっては動くこともありますが、動作は保証されないため、ターゲットのホスト名にA/AAAAを置きます。
3. 管理画面の欄の分け方を取り違えている
SRVの入力画面は、サービス名・プロトコル・優先度・重み・ポート・ターゲットを別々の欄に分けていることが多く、欄の名前や並び順はサービスごとに違います。サービス名の欄にアンダースコアを付けるかどうかも画面によって異なります。登録後に dig で実際の名前と値を確かめるのが、もっとも手堅い見分け方です。
4. TXTの書式の誤り
SPFのTXTが同じ名前に2行以上あると、SPFの検証は失敗します。SPFは1つの v=spf1 にまとめます。また、TXTの1つの文字列は255バイトまでなので、DKIMの公開鍵のような長い値は複数の文字列に分けて1つのレコードに入れます。管理画面が自動で分割するかどうかはサービスによって違います。
5. ワイルドカードのTXTが意図せず答えている
*.example.com にTXTを置いていると、存在しない名前への問い合わせにそのTXTが返ることがあります。アンダースコア付きの名前の確認で、想定外のTXTが返ったら、ワイルドカードの設定を見直します。
設定後の確認方法
登録したら、名前ごとに問い合わせて、値と名前が意図どおりかを確かめます。
# SRV の確認（優先度 重み ポート ターゲット の順に表示される）
dig _submission._tcp.example.com SRV +short
dig _imaps._tcp.example.com SRV +short
# TXT の確認（SPF は1行だけか）
dig example.com TXT +short
dig _dmarc.example.com TXT +short
# SRV のターゲットが A/AAAA を持つか（CNAME が返らないか）
dig mail.example.com A +short
dig mail.example.com AAAA +short
# ポートが実際に開いているか
nc -vz mail.example.com 587ポートの確認では、TLSで接続できるかまで見たい場合に openssl s_client -connect mail.example.com:993 のようなコマンドも使えます。DNSの値が正しくても、サーバー側でサービスが待ち受けていなければ接続できないため、DNSとサーバーの両方を確かめることが大切です。変更前には、既存のレコードを書き出して控えておくと、誤って消したときに戻せます。
まとめ
- SRVは「サービスの場所」、TXTは「認証や付加情報」。同じドメインでも同じ名前でも併用できるが、同じ名前にCNAMEは置けない
- メールでは、SRVはクライアントへの案内、SPF・DMARCのTXTは到達性に関わる。SRVへの対応はクライアントによって異なる
- クラウドサービスの導入では、管理画面に表示された最新の値を使い、SPFは書き換えずに所有確認のTXTを追加する
- ドメインの二重付与、SRVのターゲットのCNAME・IP、SPFの重複、長いTXTの分割が主な誤り
- 登録後は
digで名前と値を確かめ、SRVのターゲットとポートが実際に応答するかまで確認する