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の署名はメールのヘッダーに埋め込まれているので、転送されても一緒に運ばれます。同じセクション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など）宛に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）は別の会社が運営する別のサービスで、要件も異なります。

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 の両方を確認する

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