DKIM リプレイ攻撃の仕組みと対策｜署名済みメールを悪用される問題
目次
この記事でわかること
- DKIM リプレイ攻撃の仕組み（署名は有効、宛先だけ変える）
- なぜ DKIM の設計上この攻撃が防げないのか
- 送信側ドメインが取れる現実的な対策（
x=期限 / 配信制御 / 鍵ローテ） - Google が 2023 年以降強化している「リプレイ送信元の評価ペナルティ」
DKIM リプレイ攻撃とは
DKIM（RFC 6376）は メール本文と一部ヘッダ に署名しますが、エンベロープの RCPT TO（宛先） には署名しません。この性質を悪用し、攻撃者が:
- 正規ドメインから 1 通だけ「無害なメール」を取得（無料アカウントで自分宛に送る等）
- その署名済みメールを 数万〜数百万の宛先にそのまま再送（リプレイ）
- 受信側では「正規ドメインの正規署名」と判定され DMARC pass
正規ドメインの「貸し出し」状態になり、配信レピュテーションが汚染されます。
なぜ防ぎにくいか
DKIM の署名は「内容が改ざんされていないこと」を保証するだけで、「この宛先に送ることが許可されているか」は保証しません。RFC の設計上、署名済みメールはどの宛先に送っても署名は有効です。
送信側ドメインの対策
1. x= タグで署名の有効期限を短く
DKIM ヘッダに x=<UNIX 時刻> を入れ、署名の有効期限を「送信から数時間〜1 日」に絞ります。期限後はリプレイされても署名 fail。送信プラットフォーム（SendGrid / Resend / Postmark 等）で設定可能。
2. アカウント取得制限とレート制御
無料アカウントから 1 通取得されることが起点なので、
- 新規アカウントの送信レート制限
- メール認証必須化（電話 / クレカ）
- 1 通目の送信先制限
など、リプレイの種を作らせない設計が重要。
3. 大量配信時の SMTP コネクション制御
短時間に同一メッセージ ID で大量送信を検知して止める。送信プラットフォームの自前監視が必須。
4. 鍵ローテーション
リプレイ被害が判明したら、即座に DKIM 鍵をローテーションし、リプレイされ続けている署名を無効化します。鍵ローテの段取りはDKIM 鍵ローテーションの手順参照。
Google の対応（2023 年以降）
Gmail はリプレイ送信元の IP / 中継経路に対するスパム判定を強化しています。リプレイされた正規ドメインのメールも、送信元 IP（リプレイした攻撃者の IP）と元のドメインのレピュテーション差から spam と判定する精度が上がっています。送信側ドメインの被害は限定的になる方向ですが、それでも署名済みメールが「拡散の燃料」として使われる事実は変わりません。
よくある質問（FAQ）
Q. DKIM リプレイ攻撃を受けている兆候はどう確認しますか？
DMARC 集計レポートで「自社が送っていない IP からの DKIM pass」が継続的に観測されたら高確率でリプレイです。p=none でも rua= を設定していれば XML レポートに送信元 IP が記録されます。DMARC レポートの読み方で IP の絞り込み手順を解説しています。
Q. SPF を強化すればリプレイは防げますか？
防げません。リプレイは「正規メールの再送」なので、SPF が見るのは攻撃者の MTA 送信元 IP です。正規ドメインの SPF レコードに含まれない IP からなら SPF fail になりますが、DKIM のみで DMARC が pass してしまうため、SPF 単独では止まりません。SPF と DKIM の違いも参照。
Q. 鍵ローテだけで対処できますか？
被害発生後の応急処置にはなりますが、根本対処は x= 有効期限とアカウント取得制限の組み合わせです。鍵を回しても、攻撃者が新しい無害メールを 1 通取得すれば同じ手口が再現できます。DKIM 鍵ローテーション自動化で運用負荷を下げる設計例を整理しています。
Q. 鍵長を 2048bit に伸ばせばリプレイは防げますか？
防げません。鍵長は「署名の偽造耐性」を強める対策で、リプレイ（正規署名の再送）には無関係です。ただし 1024bit は別の理由で廃止が進んでおり、DKIM 1024bit 廃止と 2048bit 移行で移行手順を確認してください。
まずは現状を把握しましょう
DKIM の設定状況や鍵長は、無料のドメイン診断で確認できます。リプレイ被害が疑われる場合はお問い合わせからご相談ください。
関連記事: DKIM 鍵ローテーションの手順 / DKIM 1024bit 廃止と 2048bit 移行 / DKIM 検証の仕組み / BYODKIM とは