--- title: "SPF・DKIM・DMARCを確認できないときの調べ方" description: "設定済みのSPF・DKIM・DMARCを確認ツールで検出できないとき、入力ドメイン、DKIMセレクタ、DNSの登録名、キャッシュを順番に切り分ける方法を解説します。" date: 2026-08-01 category: メール tags: [DKIM, DMARC] related_links: [mail-auth, dns] draft: false --- SPF・DKIM・DMARCを設定したのに確認できない場合は、レコードの値より先に、どのDNS名を調べたかを確認します。3つの設定は同じ場所に置かれていません。 SPFは対象ドメイン直下、DKIMはセレクタを含む`_domainkey`配下、DMARCは`_dmarc`配下のTXTレコードです。入力ドメインと完全な問い合わせ名を先に直すと、反映待ちなのか設定場所の間違いなのかを早く切り分けられます。 ## 最初に3つの問い合わせ名を分ける 確認ツールで「見つかりません」と出たときは、次の完全なDNS名が実際に公開されているかを見ます。`example.com`を設定対象とした場合の違いは次のとおりです。 | 認証方式 | 問い合わせるTXTレコード名 | 見つける目印 | |---|---|---| | SPF | `example.com` | `v=spf1`で始まる値 | | DKIM | `._domainkey.example.com` | 公開鍵を示す`p=`を含む値 | | DMARC | `_dmarc.example.com` | `v=DMARC1`で始まる値 | DNS管理画面の「ホスト名」欄は、サービスによって入力方式が異なります。`_dmarc`だけを入れる画面へ完全な名前を入れると、`_dmarc.example.com.example.com`のようにドメインが二重になる場合があります。保存後のレコード一覧で、最終的な完全名を確認してください。 ## 入力ドメインを確認する [メール認証チェッカー](/mail-auth/)へは、URLではなく設定対象のドメインを入力します。`https://`、`www`、メールアドレスのユーザー名は付けません。`user@example.com`を確認するなら、まず`example.com`を使います。 ただし、実際に届いたメールの認証結果を調べる場合は、3方式が参照するドメインが一致しないこともあります。DMARCは表示上のFromドメインを基準にします。DKIMはメールヘッダーの`d=`、SPFは通常Return-Pathに現れる送信元ドメインを確認してください。ツールへ一つのドメインを入れただけで、送信サービスが使う全ドメインを自動発見できるわけではありません。 ## SPFはドメイン直下を確認する SPFが見つからないときは、`example.com`のTXTレコードに`v=spf1`で始まる値があるかを確認します。DNS管理画面では、ルートを`@`や空欄で表すことがあります。 [SPFの現行仕様であるRFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html)では、SPFポリシーを対象となるDNS名のTXTレコードとして公開します。同じ名前に複数の`v=spf1`レコードがある状態は正しい分割ではなく、SPFの恒久エラーになるため、1つへ整理が必要です。他の用途のTXTレコードが同居すること自体は問題ありません。 ルートではなく`www.example.com`へSPFを登録しても、`example.com`を送信元とする確認では見つかりません。設定した値を読み直す前に、DNS一覧の名前列を確認する方が早いです。 ## DKIMはセレクタから調べる DKIMはドメインだけでは問い合わせ先が決まりません。送信システムが指定したセレクタを使い、`._domainkey.`というTXTレコード名を作ります。 たとえば受信したメールの`DKIM-Signature`に`d=example.com; s=google;`とあれば、問い合わせ先は`google._domainkey.example.com`です。[DKIMのRFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html)でも、`d=`のドメインと`s=`のセレクタからこの名前を組み立てることが定められています。 セレクタが分からないときは推測せず、メールサービスの設定画面かテスト送信したメールのソースを確認します。Google Workspaceでは既定値が`google`ですが、別の値を指定した環境もあります。[Google WorkspaceのDKIM設定ヘルプ](https://support.google.com/a/answer/174124?hl=ja)では、管理画面に表示されたDNSホスト名を使う方法が案内されています。受信メールの`s=`から確認することもできます。 ## DMARCは`_dmarc`と親側を確認する DMARCは、表示上のFromドメインに`_dmarc.`を付けたTXTレコードから調べます。`user@example.com`なら、最初の問い合わせ先は`_dmarc.example.com`です。 現在のDMARC仕様は[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)です。対象ドメインでポリシーが見つからない場合は、DNSの階層を上がって適用候補を探索します。そのため、サブドメインに個別レコードがなくても、親ドメイン側のDMARCポリシーが表示される場合があります。 反対に、`_dmarc.www.example.com`だけへ登録しても、`example.com`のFromドメイン用レコードにはなりません。確認したいメールアドレスの`@`より後ろと、レコード名の末尾が対応しているかを見直します。 ## 待つべき状態か設定ミスかを分ける 「DNSの反映待ち」という説明だけで長く待つ前に、権威DNSと公開DNSを分けて確認します。権威DNSはそのドメインの正本を返し、公開DNSはTTLの間、その回答をキャッシュします。 権威DNSに新しいレコードがなければ、待っても公開されません。レジストラの管理画面ではなく、現在のNSレコードが示すDNSサービスへ登録したかを確認します。権威DNSにはあり、公開DNSだけが古い場合は、TTLや空回答のキャッシュが切れるまで時間が必要な可能性があります。 [Google Public DNSのトラブルシューティング](https://developers.google.com/speed/public-dns/docs/troubleshooting)では、未期限切れの古い回答や、権威ネームサーバー間でゾーン情報が一致しない場合の確認方法が案内されています。TTLが更新反映に影響する仕組みは[CloudflareのTTL解説](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)でも確認できます。特定の待ち時間を決め打ちせず、どちらのDNSにレコードがあるかを見た方が確実です。 ## 最短の順番で確認する 未検出の原因を早く絞るには、内容の修正より先に問い合わせ先を上から確認します。順番を変えると、正しい値を間違った場所へ何度も登録し直すことがあります。 1. URLや`www`を除き、設定対象のドメインを確認する 2. SPF、DKIM、DMARCそれぞれの完全な問い合わせ名を作る 3. DKIMはメールヘッダーまたは管理画面から正しいセレクタを得る 4. 現在のNSが示す権威DNSにTXTレコードがあるか確認する 5. 公開DNSで同じ値が見えた後に、レコード内容を点検する ここまで確認してレコードが見えるのに認証が失敗する場合は、未検出ではなく値や送信設定の問題へ段階が変わります。3方式の役割から見直す場合は[SPF・DKIM・DMARCの仕組み](/article/spf-dkim-dmarc)を参照してください。 まず[メール認証チェッカー](/mail-auth/)へ設定対象のドメインと正しいDKIMセレクタを入力します。見つからない項目だけを[DNSレコード確認ツール](/dns/)で完全な名前から調べます。これで入力違い、登録場所の間違い、キャッシュ待ちを順番に切り分けられます。