SPF・DKIM・DMARCを確認できないときの調べ方

SPF・DKIM・DMARCを設定したのに確認できない場合は、レコードの値より先に、どのDNS名を調べたかを確認します。3つの設定は同じ場所に置かれていません。

SPFは対象ドメイン直下、DKIMはセレクタを含む_domainkey配下、DMARCは_dmarc配下のTXTレコードです。入力ドメインと完全な問い合わせ名を先に直すと、反映待ちなのか設定場所の間違いなのかを早く切り分けられます。

最初に3つの問い合わせ名を分ける

確認ツールで「見つかりません」と出たときは、次の完全なDNS名が実際に公開されているかを見ます。example.comを設定対象とした場合の違いは次のとおりです。

DNS管理画面の「ホスト名」欄は、サービスによって入力方式が異なります。_dmarcだけを入れる画面へ完全な名前を入れると、_dmarc.example.com.example.comのようにドメインが二重になる場合があります。保存後のレコード一覧で、最終的な完全名を確認してください。

入力ドメインを確認する

メール認証チェッカーへは、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では、SPFポリシーを対象となるDNS名のTXTレコードとして公開します。同じ名前に複数のv=spf1レコードがある状態は正しい分割ではなく、SPFの恒久エラーになるため、1つへ整理が必要です。他の用途のTXTレコードが同居すること自体は問題ありません。

ルートではなくwww.example.comへSPFを登録しても、example.comを送信元とする確認では見つかりません。設定した値を読み直す前に、DNS一覧の名前列を確認する方が早いです。

DKIMはセレクタから調べる

DKIMはドメインだけでは問い合わせ先が決まりません。送信システムが指定したセレクタを使い、<selector>._domainkey.<domain>というTXTレコード名を作ります。

たとえば受信したメールのDKIM-Signatureにd=example.com; s=google;とあれば、問い合わせ先はgoogle._domainkey.example.comです。DKIMのRFC 6376でも、d=のドメインとs=のセレクタからこの名前を組み立てることが定められています。

セレクタが分からないときは推測せず、メールサービスの設定画面かテスト送信したメールのソースを確認します。Google Workspaceでは既定値がgoogleですが、別の値を指定した環境もあります。Google WorkspaceのDKIM設定ヘルプでは、管理画面に表示されたDNSホスト名を使う方法が案内されています。受信メールのs=から確認することもできます。

DMARCは_dmarcと親側を確認する

DMARCは、表示上のFromドメインに_dmarc.を付けたTXTレコードから調べます。user@example.comなら、最初の問い合わせ先は_dmarc.example.comです。

現在のDMARC仕様はRFC 9989です。対象ドメインでポリシーが見つからない場合は、DNSの階層を上がって適用候補を探索します。そのため、サブドメインに個別レコードがなくても、親ドメイン側のDMARCポリシーが表示される場合があります。

反対に、_dmarc.www.example.comだけへ登録しても、example.comのFromドメイン用レコードにはなりません。確認したいメールアドレスの@より後ろと、レコード名の末尾が対応しているかを見直します。

待つべき状態か設定ミスかを分ける

「DNSの反映待ち」という説明だけで長く待つ前に、権威DNSと公開DNSを分けて確認します。権威DNSはそのドメインの正本を返し、公開DNSはTTLの間、その回答をキャッシュします。

権威DNSに新しいレコードがなければ、待っても公開されません。レジストラの管理画面ではなく、現在のNSレコードが示すDNSサービスへ登録したかを確認します。権威DNSにはあり、公開DNSだけが古い場合は、TTLや空回答のキャッシュが切れるまで時間が必要な可能性があります。

Google Public DNSのトラブルシューティングでは、未期限切れの古い回答や、権威ネームサーバー間でゾーン情報が一致しない場合の確認方法が案内されています。TTLが更新反映に影響する仕組みはCloudflareのTTL解説でも確認できます。特定の待ち時間を決め打ちせず、どちらのDNSにレコードがあるかを見た方が確実です。

最短の順番で確認する

未検出の原因を早く絞るには、内容の修正より先に問い合わせ先を上から確認します。順番を変えると、正しい値を間違った場所へ何度も登録し直すことがあります。

1. URLやwwwを除き、設定対象のドメインを確認する
2. SPF、DKIM、DMARCそれぞれの完全な問い合わせ名を作る
3. DKIMはメールヘッダーまたは管理画面から正しいセレクタを得る
4. 現在のNSが示す権威DNSにTXTレコードがあるか確認する
5. 公開DNSで同じ値が見えた後に、レコード内容を点検する

ここまで確認してレコードが見えるのに認証が失敗する場合は、未検出ではなく値や送信設定の問題へ段階が変わります。3方式の役割から見直す場合はSPF・DKIM・DMARCの仕組みを参照してください。

まずメール認証チェッカーへ設定対象のドメインと正しいDKIMセレクタを入力します。見つからない項目だけをDNSレコード確認ツールで完全な名前から調べます。これで入力違い、登録場所の間違い、キャッシュ待ちを順番に切り分けられます。