SPFだけで足りるのか｜DKIMが必要になる3つの場面と足せないときの選択

診断で「SPFはあるがDKIMが確認できません」と表示されたとき、対応は、あなたの状況で変わります。まず、どれに当たるかを見てください。

• すでにDKIMが設定されている場合があります。この表示は、「DKIMが無い」ではなく「確認できなかった」という意味です。まずここを確かめてください
• 利用中のサービスがDKIMに対応しているなら有効にして公開鍵をDNSに登録します
• サービスがDKIM署名に対応していないならDNS側でできることはありません。SPFとDMARCで守ることになります

そのうえでDKIMを足す必要があるかどうかは送り方で決まります。SPFだけで問題にならない使い方もあればSPFだけでは成立しない使い方もあります。分かれ目になるのは次の3つの場面です。

1. メールが転送されるとき
2. DMARCを p=reject で運用するとき
3. 受信側がSPFとDKIMの両方を要求する規模で送るとき（Gmailなら個人アカウント宛に1日5,000件以上）

以降、まず表示の意味を確かめてからこの3つを順に説明します。

診断の「DKIMが確認できません」は「DKIMが無い」という意味ではありません

この表示が出るのは診断がDKIMのセレクタを特定できなかったときだけです。DKIMが設定されていないと判断できた場合は、別の表示（「DKIMが設定されていない可能性があります」）になります。

セレクタというのはDNSのどこに公開鍵が置いてあるかを示す名前です。公開鍵は、セレクタ名._domainkey.ドメイン名 という場所に登録されるので、セレクタ名が分からないと引きようがありません。そして、この名前は、自由な文字列を使えるため、よく使われる候補を試して見つからなかったことは、そのドメインにDKIMが無いことの証明にはなりません。実際にgoogle.comは、日付をもとにしたセレクタ名を使っており、既定の候補では見つかりません。

確かめる方法があります。問題が起きている送信経路から自分宛にテストメールを送り、届いたメールのソースにある DKIM-Signature ヘッダーの d= と s= を読みます。手順はDKIMセレクタの確認方法で詳しく説明しています。診断ツールは、セレクタ名を指定して再確認することもできます。

ここで署名が見つかったならその経路では署名処理が行われています。ただし署名があることと受信側で検証が通ることは別です。続けて設定したあと、何が出ていれば通っているのかの手順で Authentication-Results を確認してください。

SPFだけで足りるかは、送り方によって分かれます

署名が見つからなかった場合、次に決めるのは「足すべきか」です。判断は、次のようになります。

2行目の「転送を経由する」には、社員の個人アドレスへの自動転送、同窓会や部署あての転送用アドレス、メーリングリストが含まれます。受け取った相手が自分で転送設定をしている場合も同じで、送る側からは見えません。4行目の大量送信は、個人のGmailアカウント宛とOutlook.comなどMicrosoftの個人向けサービス宛が対象です。

3行目と4行目は、後の節でそれぞれ根拠を示します。まず、なぜ転送で差が出るのかを理解するために2つの仕組みが何を見ているのかを整理します。

SPFは送信元のIPを見て、DKIMはメールに付いた署名を見ます

SPFは、そのメールがどのサーバーから送られてきたかを見ます。受信側は、接続してきた相手のIPアドレスを調べ、送信元として名乗られたドメインのDNSに登録された許可リストと照らし合わせます。判断材料は、メールの外側にあります。

DKIMは、メールそのものに付けられた電子署名を見ます。送信側が秘密鍵で署名を作ってヘッダーに埋め込み、受信側は、DNSに公開されている公開鍵でそれを検証します。判断材料は、メールの中にあります。

この違いが転送されたときの結果を分けます。

1つ目: メールが転送されるとき

メールが転送されると最終的な受信側から見た接続元は、転送したサーバーになります。もとの送信サーバーではありません。そのため、もとのドメインのSPFに照らすと許可リストに載っていないIPから来たことになります。

RFC 9989 のセクション7.4は、この状況を具体例つきで説明しています。

When such mail is delivered to the actual recipient mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, as the incoming IP address will be that of "example.edu" or "association.example" and not an IP address authorized by the originating RFC5321.MailFrom domain.

（そうしたメールが実際の受信箱へ配送されるとき、中継したMTAがRFC5321.MailFromのアドレスを書き換えていない限り、SPFの検査は、まず失敗します。受信側から見た接続元IPは、"example.edu" や "association.example" のものであって、もとのRFC5321.MailFromドメインが許可したIPではないからです。）

ここで注意したいのは unless（〜でない限り）の部分です。転送するサーバーが送信者のアドレスを自分のドメインに書き換える方式をとっている場合、SPFの検査自体は、通ります。この書き換えは、RFC 7208 の Appendix D.2 が転送側の対処法として挙げているもので、規格違反ではありません。

ただし、書き換えても解決しません。DMARCは、「SPFが通ったこと」だけでは合格としないためです。RFC 9989 のセクション4.4.2は、次のように定めています。

DMARC relies solely on SPF validation of the MAIL FROM identity.

（DMARCは、MAIL FROM識別子に対するSPFの検証だけを拠りどころにします。）

そして、合格には、そのMAIL FROMのドメインがメールの差出人欄のドメインと揃っていること（アライメント）が要ります（RFC 9989 のセクション1）。転送側が自分のドメインに書き換えればSPFは通っても差出人欄とは揃わなくなります。

つまり、書き換えない転送ではSPFの検査そのものが失敗しやすく、書き換える転送ではアライメントが失われます。一般的な第三者の転送では、もとのドメインのDMARC合格をSPFで維持することが難しくなります。例外は、あります。転送するサーバーがもとのドメインのSPFに含まれている場合（同じ組織の中での転送など）は、書き換えなくても検査は、通ります。

一方、DKIMの署名は、メールのヘッダー（DKIM-Signature）に埋め込まれているので（RFC 6376 セクション3.5）、転送されても一緒に運ばれます。RFC 9989 の同じセクション7.4は、次のように書いています。

DKIM signatures will generally remain valid in these relay situations.

（こうした中継の状況でもDKIMの署名は、たいてい有効なままです。）

generally（たいてい）であって、常にではありません。転送の途中でメール本文やヘッダーが書き換えられると署名が無効になることがあります。RFC 6376 のセクション3.4は、「Some mail systems modify email in transit, potentially invalidating a signature」（一部のメールシステムは、配送の途中でメールを変更し、署名を無効にすることがあります）と述べ、そのために変更をある程度許容する正規化方式を用意しています。メーリングリストが件名に接頭辞を付けたり、本文末尾に案内を足したりする場合は、この影響を受けます。

また、署名が検証できることとDMARCに使えることも別です。署名した側のドメイン（d=）が差出人欄のドメインと揃っていなければDMARCの合格には使えません。アライメントの詳しい条件は、別の記事で扱います。

なお、DMARCは、検証に成功した複数のDKIM署名のうち1つでも差出人欄と揃っていれば合格とします（RFC 9989 のセクション4.4.1）。転送の途中で署名が追加される場合でももとの署名が残っていれば通る可能性があります。

2つ目: DMARCを p=reject で運用するとき

DMARCの p=reject は、認証に失敗したメールをどう扱ってほしいかを受信側に伝える設定です。これを掲げるドメインについて、RFC 9989 のセクション7.4は、明確な要求を置いています。

It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.

（したがって、"p=reject" を公開するドメインは、DMARCの合格をSPFだけに頼ってはならず、自分のメールに有効なDKIM署名を付けなければなりません。これは、決定的に重要です。）

理由は、1つ目の場面と同じです。転送された時点でSPF側の経路が使えなくなり、DKIMが無ければDMARCは、失敗します。そして、p=reject を掲げていればその失敗したメールは、正規のものであっても拒否されうる状態になります。

このMUST NOTが向けられているのは p=reject を公開するドメインです。p=none や p=quarantine の段階では、SPFだけでもDMARCの合格は、成立します。

ただし、RFC 9989 のセクション8は、これとは別に「DMARCへの完全な参加」の条件を並べており、そこではポリシーの値によらずSPFとDKIMの両方を求めています（「MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain」「MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain」）。p=none のままでも直ちに問題が起きるわけではありませんが、DMARCに完全に参加するにはDKIMが要る、という位置づけです。

補足として、p=reject は、受信側への方針の表明であって、拒否させる命令ではありません。同じセクション7.4は、受信側に対しても「Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain」（メール受信者は、送信ドメインの "p=reject" というポリシーだけを根拠に受信メールを拒否してはなりません）と定めています。実際の扱いは、受信側の判断も含みます。ポリシーを掲げたから必ず拒否される、あるいは掲げなければ安全、という単純な関係ではありません。

DMARCそのものをこれから設定する場合は、DMARCを設定していないリスクと最初に置く設定から読んでください。

実測では、DMARCレコードが見つかった10,114件のうち p=reject を掲げているのは868件（8.6%）でした（Majestic Millionに掲載されている .jp ドメイン19,065件を対象に2026-08-01に測定。データは/data/jp-dmarc-policy-2026-08-01.json、測定は scripts/measure-dmarc-policy.mjs）。この母集団は、被リンクの多い順に並んだ一覧からの抽出で、.jp 全体の無作為抽出ではありません。

3つ目: 受信側が両方を要求する規模で送るとき

Googleは、送信者向けの要件を2段階に分けています（メール送信者のガイドライン、2026-08-06に確認）。

つまり、通常の送信量であればGmail宛の要件は、SPFだけでも満たせます。ここで「SPFだけでは届かなくなる」と書くのは正確ではありません。ただし、要件を満たすことと確実に受信箱へ届くことは別で、要件は、最低限の条件です。

5,000件という数え方には、知っておいたほうがよい点が3つあります（Gmailの送信者ガイドラインに関するよくある質問、2026-08-06に確認）。

• 数えるのは個人のGmailアカウント宛だけです。「メール送信者のガイドラインは、Google Workspace アカウントに送信するメールには適用されません」と案内されています。取引先の独自ドメイン宛が大半ならその分は、入りません
• サブドメインからの送信も合算されます。「同じプライマリ ドメインから送信されたメールは、上限である 5,000 件の計算にカウントされます」とあり、example.jp と news.example.jp から2,500件ずつ送れば合わせて一括送信者とみなされます
• 一度その区分に入ると戻りません。「一括送信者のステータスに有効期限はありません。一括送信者として分類されたメール送信者は、恒常的に一括送信者として分類されます」と明記されています

両方を求めるのはGoogleだけではありません。Microsoftは、Outlook.comをはじめとする同社の個人向けメールサービス（Hotmail、Live.com、MSNなど）宛に、同じFromドメインで5,000件以上を送る場合について、「Publish SPF and DKIM records for the domain: Both SPF and DKIM checks must pass」（ドメインのSPFとDKIMのレコードを公開すること。SPFとDKIMの検査は、両方が通る必要があります）と案内しています（Fix NDR error "550 5.7.515" in Outlook.com、2026-08-06に確認）。DMARCの公開も求めています。

米国のYahoo Mailも大量送信者には「Implement both SPF & DKIM」と「Publish a valid DMARC policy with at least p=none」を求めています（Yahoo Sender Hub、2026-08-06に確認）。通数の基準は、このページには書かれていません。

もう1つ、日本語の記事でしばしば「GmailとYahoo!が義務化した」とまとめられますが、要件の中身は、同じではありません。LINEヤフーが運営するYahoo!メール（@yahoo.co.jp）は、「SPFかDKIM、もしくはDMARCの認証を導入・判定クリアしていないメールは迷惑メールと判定したり、受信を拒否したりする場合があります」と案内しており（迷惑メールへの取り組み、2026-08-06に確認）、DKIMを単独で求めてはいません。通数による基準も、このページには書かれていません。米国のYahoo Mail（@yahoo.com）は、Yahoo Inc. が運営する別のサービスで、要件も異なります。

DKIMはDNSに値を1つ足すだけでは設定できません

ここまでで足したほうがよいと判断できたとして、SPFと同じようにはいきません。手順の形が違います。

SPFは、DNSにレコードを1本書けば公開できます。送信元を洗い出す作業は、要りますが、DNSの外に用意するものはありません。

DKIMは、鍵の組を作るところから始まります。署名に使う秘密鍵は、メールを送るサービスの側が持ち、DNSに登録するのはそれと対になる公開鍵です。一般的な事業者のサービスを使っている場合、最初の作業は、DNSの管理画面ではなく、メールを送っているサービスの管理画面になります。そこでDKIMを有効にすると鍵が発行され、DNSに登録する値が表示されます。自分でメールサーバーを立てている場合は、鍵を自分で生成して先に公開することもできます。

登録する値の形もサービスによって、違います。公開鍵そのものをTXTレコードとして登録させるところもあればサービス側が用意した名前へのCNAMEを登録させるところもあります（Amazon SESなどが後者です）。どちらになるかは、発行元が決めるので、一般的な形を推測して書くことはできません。

本サイトの診断がこの表示に対して、コピーできる設定値を出さないのはこの構造によるものです。値を生成できるのはドメインの状態だけで決まるレコード（SPFやDMARCなど）に限られ、DKIMは、発行元が出した値に依存します。それらしい値を自信ありげに出せば貼り付けたのに動かないという結果を招きます。

サービスごとの設定場所は、事業者別ガイドにまとめてあります。鍵の長さを選べる場合は、DKIMの鍵長は1024bitで足りるのかも参照してください。

DKIMを足せないときにすること

利用しているサービスがDKIM署名に対応していないことがあります。この場合、DNS側でできることはありません。公開鍵を登録しても署名する側がいなければ意味を持ちません。

そのときは、SPFとDMARCで守ることになります。SPFで送信元を正しく列挙し、DMARCを設定して認証結果を活かす指示を出す形です。これは有効な運用で、診断もこの状態を誤りとしては、扱いません。

ただし、1つ制約が残ります。この構成では p=reject に引き上げないでください。前の節で見たとおり、p=reject をSPFだけに頼って運用することは、RFC 9989 のセクション7.4がMUST NOTで禁じています。転送を経由した正規のメールが拒否されうるためです。まず p=none にとどめ、レポートで実態を見てから p=quarantine を検討してください。p=quarantine でも転送を経由した正規のメールが迷惑メールとして扱われる可能性は、残ります。

送信サービスを乗り換えるかどうかは、この記事では扱いません。判断材料としては、転送を経由する宛先がどれだけあるか、p=reject まで引き上げる予定があるか、Gmail宛の送信量が1日5,000件を超えるか、の3点になります。

設定したあと、何が出ていれば通っているのか

DNSに公開鍵を登録したことと実際に送ったメールの署名が検証できることは別です。登録しただけで確認を終えないでください。見るのは次の2つです。

1つ目は、DNSに公開鍵が見えるかどうかです。本サイトの診断にドメインを入れ、DKIMの項目が「問題なし」になることを確認します。セレクタを特定できないと表示された場合は、サービスの管理画面に出ていたセレクタ名を指定して再確認してください。登録した直後は、リゾルバに古い応答が残っていて見つからないことがあります。その場合の切り分けは、DNSが反映されないときの確認方法にあります。

2つ目は、実際に送ったメールが検証されるかどうかです。設定した送信経路から自分宛にテストメールを送り、届いたメールのソースにある Authentication-Results ヘッダーを見ます。ここに dkim=pass と署名したドメインを示す header.d= があなたのドメインになっていれば通っています。次のような行です。

Authentication-Results: mx.example.com;
       dkim=pass header.d={あなたのドメイン} header.i=@{あなたのドメイン} header.s={セレクタ名};
       spf=pass smtp.mailfrom={あなたのドメイン};
       dmarc=pass header.from={あなたのドメイン}

dkim=pass が出ていても header.d= が送信サービスのドメインになっている場合、その署名は、DMARCには使えません。差出人欄のドメインと揃っている必要があります。サービス側の設定で自分のドメインで署名する形（独自ドメインでのDKIM設定）に変えられるかを確認してください。

dkim=fail や dkim=none が出た場合の原因の切り分けは、この記事では扱いません。セレクタが見つからないのか、公開鍵の値が壊れているのか、署名が有効化されていないのかで対処が変わります。

実測: この診断と同じ方法で探して、公開鍵が見つかったのは5,304件でした

Majestic Millionに掲載されている .jp ドメイン19,065件について、本サイトの診断と同じ手順でDKIMの公開鍵を探した結果、見つかったのは5,304件でした（2026-07-27に測定。データは/data/jp-email-auth-2026-07.json、測定は scripts/measure-dkim-keys.mjs）。

この数値から「DKIMを使っているドメインは、5,304件だ」とは言えません。理由は、2つあります。

1つは、探索の方法に偏りがあることです。この測定は、MXレコードとSPFレコードから利用中のメール基盤を推定し、その基盤でよく使われるセレクタ名を試しています。基盤を判定できなかったドメインや固有のセレクタ名を発行する方式のドメインでは、設定されていても見つかりません。この記事が扱っている表示が出るのはまさにその場合です。

もう1つは、DNSに公開鍵があることといま送っているメールがその鍵で署名されていることが別だという点です。RFC 6376 のセクション3.1は、鍵を入れ替える際に古い鍵と新しい鍵を並行して公開する手順を認めており、公開されている鍵が使われていないこともあります。

言えるのは「診断と同じ経路で探して見つかった数」までです。母集団も被リンクの多い順に並んだ一覧からの抽出で、規模の大きい組織に偏っています。

まとめ

診断が「SPFはあるがDKIMが確認できません」と出したとき、順に確かめることは、次のとおりです。

1. 本当に設定されていないのかをテストメールの DKIM-Signature ヘッダーで確かめる
2. 設定されていなければ転送を経由する宛先があるか、p=reject を使うか、個人のGmailやOutlook.com宛が1日5,000件以上あるかを見る
3. どれかに当てはまるなら送信サービスの管理画面でDKIMを有効にし、表示された値をDNSに登録する
4. サービスが対応していないならSPFとDMARCで守る。ただし p=reject にはしない
5. 登録したら、DNSでの公開と実メールの Authentication-Results の両方を確認する

SPFのほうも設定していない場合は、この記事の前提から外れます。DMARCレコードがあるのにSPFもDKIMも無い状態については「DMARCが機能しない状態です」と出たときを読んでください。DKIMが本当に無いのかを先に確かめたい場合は「DKIMが設定されていない可能性があります」と出たときで扱っています。

自分のドメインの現在の状態は、診断ツールで確認できます。DKIMのセレクタを指定して調べることもできます。