DNS認証とはなんなのか

DNS認証とは、DNSに特定の情報を登録することで、そのドメインに対する管理権限があることを確認したり、メール送信やサービス連携に必要な設定情報を第三者が検証できるようにしたりする仕組みです。

少しやさしく言うと、「そのドメインをちゃんと管理できる人かどうかを、DNSの設定内容で確認する方法」と考えるとわかりやすいです。

たとえば、次のような場面でよく使われます。

• Google Search Consoleでサイトの所有権を確認したいとき
• メール配信サービスで送信ドメイン認証をしたいとき
• SaaSやCDN、SSL証明書の設定でドメイン管理権限を証明したいとき
• 独自ドメインやサブドメインを外部サービスに接続したいとき

つまりDNS認証は、Webサイト運用、メール配信、各種ツール連携などで広く使われる、とても重要な仕組みです。

まずDNSとは何か

DNSは、ドメイン名と各種設定情報を管理する仕組みです。

インターネット上では、人は example.com のようなドメイン名でWebサイトを認識しますが、コンピュータはIPアドレスを使って通信します。

DNSは、その対応関係を管理しています。

たとえば、

• example.com → 192.0.2.1

のように、「このドメインはどこに接続すればよいか」を案内する役割があります。

ただし、DNSに登録できるのはIPアドレスだけではありません。

DNSには、

• 接続先情報
• メール受信先情報
• テキスト情報
• 公開鍵
• ドメイン確認用トークン

なども登録できます。

DNS認証は、こうしたDNS上の情報を使って、ドメインの管理権限や設定の正当性を確認する仕組みです。

DNS認証の基本的な仕組み

一般的な流れはとてもシンプルです。

サービス側が確認用の値を発行する

たとえばGoogleやメール配信サービスが、確認用の文字列や接続先情報を発行します。

例

• google-site-verification=xxxxx
• random-token-12345
• 特定のCNAME接続先

その値をDNSに登録する

ドメイン管理者は、DNS管理画面で指定されたレコードを追加します。

ここでよく使われるのが、

• TXTレコード
• CNAMEレコード

です。

サービス側がDNSを確認する

サービス側がDNS情報を参照して、

• 指定した値が正しく登録されているか
• 指定した接続先になっているか

を確認します。

一致すれば認証完了

正しく設定されていれば、「このドメインを操作できる権限がある」または「このドメインの設定が有効である」と判断され、認証や連携が完了します。

なぜDNSに登録すると確認になるのか

DNS設定を変更できるのは、通常、そのドメインのDNSを管理している人だけです。

つまり、第三者が勝手に

• example.com のTXTレコードを追加する
• example.com のCNAMEを変更する

ことはできません。

そのため、指定された値をDNSに正しく追加できた時点で、そのドメインに対する技術的な管理権限を持っていると判断しやすくなります。

ここでいうのは厳密な法的所有権というより、DNSを変更できる管理権限です。

実務では、社内担当者、制作会社、代理店、情シス部門などがDNSを管理しているケースもあります。

DNS認証はどんなときに使われるのか

DNS認証は、主に次のような場面で使われます。

ドメイン所有権・管理権限の確認

代表例は以下です。

• Google Search Console
• 各種SaaS
• CDN
• セキュリティサービス
• SSL証明書のドメイン検証

「そのドメインを本当に管理できるか」を確認する用途です。

メール送信に関する認証・検証

メール分野では、DNSを使って送信ポリシーや公開鍵を公開し、受信側がそれを参照して検証します。

代表的なのが次の3つです。

• SPF
• DKIM
• DMARC

これらは厳密には役割が異なりますが、いずれもDNSを利用する重要なメール関連設定です。

SPF

「このドメインからメール送信を許可しているサーバーはどれか」を示す設定です。

DKIM

メールに付けた電子署名を検証するための公開鍵をDNSで公開する仕組みです。

DMARC

SPFやDKIMの結果と、Fromドメインとの整合性をもとに、受信側へ取り扱い方の方針を示す仕組みです。

これらを適切に設定することで、

• なりすまし対策
• 迷惑メール判定の軽減
• メール到達率の改善

につながります。

独自ドメインやサブドメインの接続

たとえば、

• LP作成ツール
• フォームツール
• MAツール
• チャットツール
• 会員サイト
• CDN

などに独自ドメインを接続する場合も、DNS設定による確認が行われることがあります。

DNS認証でよく使われるレコードの種類

TXTレコード

最もよく使われるレコードです。

任意の文字列を登録できるため、確認用トークンやポリシー情報を置くのに向いています。

例

Host: @
Type: TXT
Value: google-site-verification=abc123

これは、ルートドメインに対してGoogleの確認用文字列を登録する例です。

CNAMEレコード

ある名前を別のホスト名に向けるレコードです。

サービスによっては、認証や接続確認のためにCNAMEを使います。

例

Host: verify
Type: CNAME
Value: verify.service-example.com

MXレコード

メールの受信先サーバーを指定するレコードです。

これは主にメール受信のための設定であり、ドメイン所有権確認そのものの主役ではありません。

ただしメール運用全体では非常に重要です。

メール関連で使うDNS設定の例

SPF

SPFは通常、TXTレコードとして登録します。

Host: @
Type: TXT
Value: v=spf1 include:_spf.google.com ~all

これは、「指定した送信元からのメールを許可する」というポリシーを表します。

DKIM

DKIMも通常はTXTレコードとして設定します。

Host: selector1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=...

ここで登録するのは公開鍵です。

実際には、送信側サーバーが秘密鍵でメールに署名し、受信側がDNS上の公開鍵でその署名を検証します。

そのため、DKIMはDNSにTXTを置くだけで完了するものではなく、送信側の署名設定も必要です。

DMARC

DMARCもTXTレコードとして設定します。

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:report@example.com

これは、受信側に対して「DMARCのポリシー」や「レポート送信先」を示す設定です。

DNS認証とメール認証の関係

この2つは混同されやすいですが、少し整理すると理解しやすくなります。

DNS認証

一般的には、DNSレコードを使って

• ドメインの管理権限
• 接続先の正当性
• 設定ポリシー
• 公開鍵情報

などを確認・検証する仕組み全般を指して使われることが多い言葉です。

メール認証

SPF、DKIM、DMARCのように、DNSを利用してメールの正当性や取り扱い方を判断するための仕組みです。

つまり、

• DNS認証は広い概念
• メール認証はその中でもDNSを活用する重要な実務領域

と考えると整理しやすいです。

実際の設定例：Google Search ConsoleのDNS確認

たとえばGoogle Search Consoleでドメイン確認を行う場合は、次のような流れになります。

Googleが確認用TXT値を発行する

google-site-verification=xxxxxxxx

DNS管理画面でTXTレコードを追加する

• ホスト名: @ または空欄
• 種別: TXT
• 値: google-site-verification=xxxxxxxx

※ DNS管理画面によっては、@ ではなく空欄を使う場合があります。

DNS反映を待つ

DNSはすぐに反映されることもありますが、キャッシュやDNSプロバイダの仕様によって時間がかかることもあります。

Search Consoleで確認する

Google側が指定の値を確認できれば、認証完了です。

DNS認証のメリット

サイト構成に左右されにくい

HTMLファイルアップロードやmetaタグ設置と比べて、サーバーやCMSの構成に依存しにくいのが強みです。

ドメイン単位で確認しやすい

URL単位ではなく、ドメイン全体やサブドメイン単位での管理確認に向いています。

外部サービス連携で広く使われる

メール、SaaS、CDN、SSL、分析系ツールなど、非常に多くのサービスで使われています。

DNS認証の注意点

反映に時間がかかることがある

設定直後は正しく入力していても認証されないことがあります。

これはDNSキャッシュやTTLの影響によるものです。

入力ミスが起きやすい

よくあるミスには次のようなものがあります。

• ホスト名を間違える
• @ と空欄の使い分けを誤る
• 値のコピーミスをする
• サブドメイン用の設定をルートドメインに入れてしまう
• DNS管理先を間違える
• 既存レコードを上書きしてしまう

DNSの管理場所を間違えやすい

Webサーバーの管理画面と、DNSの管理画面は別であることがよくあります。

たとえば、

• ドメインはお名前.com
• DNSはCloudflare
• サーバーはエックスサーバー

のように分かれていることがあります。

この場合、DNS認証の設定は実際に権威DNSを管理している場所で行う必要があります。

DNS認証でよくあるつまずき

レコードを追加したのに認証されない

よくある原因は次の通りです。

• まだ反映されていない
• 設定箇所が違う
• ホスト名が違う
• 値が一部欠けている
• 引用符や余計な文字が入っている
• DNSの管理先が別だった

「@」とは何か

@ は一般的に、ルートドメインそのものを意味します。

たとえば example.com では、

• www → www.example.com
• mail → mail.example.com
• @ → example.com

というイメージです。

ただし、DNSサービスによっては @ ではなく空欄で指定する場合もあります。

TXTレコードは複数あってよいのか

基本的に、TXTレコード自体は複数あって問題ありません。

実際、ドメイン確認用トークン、SPF、DMARCなどが並ぶことはよくあります。

ただし注意点があります。

同じホスト名に v=spf1 で始まるSPFポリシーを複数置くのはNG です。

つまり、

• TXTレコードが複数あること自体は普通
• ただしSPFポリシーは同一ホスト名で1つにまとめる必要がある

という理解が正確です。

DNS認証とSSL認証の違い

この2つも混同されやすいポイントです。

DNS認証

DNSレコードを使って、ドメイン管理権限や設定情報を確認するものです。

SSL証明書

HTTPS通信のための暗号化証明書です。

両者は別物ですが、SSL証明書の発行時に、「このドメインを本当に管理しているか」を確認する方法のひとつとしてDNSが使われることがあります。

つまり、

• DNS認証は確認手段
• SSL証明書は暗号化のための証明書

という関係です。

まとめ

DNS認証とは、DNSに登録した情報をもとに、ドメインの管理権限や設定の正当性を確認・検証する仕組みです。

主な用途は、

• ドメイン所有権や管理権限の確認
• メール送信ポリシーや署名検証情報の公開
• 外部サービスとの独自ドメイン連携

です。

特に覚えておきたいポイントは次の通りです。

• ドメイン確認ではTXTやCNAMEがよく使われる
• メールではSPF、DKIM、DMARCが重要
• DNS管理先を間違えると設定しても反映されない
• TXTレコードは複数あってもよい
• ただし同一ホスト名のSPFポリシーは複数置いてはいけない
• 反映には時間がかかることがある

DNS認証は一見地味ですが、Web運用・メール運用・ツール連携の土台になる非常に重要な設定です。

仕組みを理解しておくと、トラブル時の切り分けもしやすくなります。

以上、DNS認証とはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。