DKIM の役割（ざっくり）
DKIM（DomainKeys Identified Mail）は、 送信側がメールの一部に署名し、 受信側が DNS に公開された公開鍵で検証します。 「このドメインが、この内容を送ったと宣言しているか」の手がかりになります。
DNS には selector._domainkey.example.co.jp のような
TXT レコードが載り、
第三者もレコードの有無と内容を読めます（外部攻撃面のメール認証の一部）。
SPF・DKIM・DMARC の位置づけ
| 仕組み | 主な問い |
|---|---|
| SPF | 送信元 IP は許可リストに載っているか |
| DKIM | 署名はドメインの公開鍵で検証できるか（改ざんされていないか） |
| DMARC | SPF / DKIM が失敗したメールをどう扱うか（p=） |
SPF だけでは足りない典型例の一つが、 転送メールで SPF が壊れるが DKIM は通るパターンです。 そのため DMARC 強化の前に、 正規送信経路ごとに DKIM が有効かを揃える、という話が現場でよく出ます（ p=none から quarantine へ）。
よくある状態
- DKIM 未設定 — SPF と DMARC だけ。署名による裏付けが無い
- セレクタが複数 — クラウドメール + ゲートウェイ + マーケツールで別セレクタ
- 古いセレクタが DNS に残る — 移行後の更新漏れ
- ゲートウェイ経由で署名が付かない — SPF とのズレとセットで発見
外部攻撃面レビューで「見る」こと（例）
| 観点 | 確認する内容（例） |
|---|---|
| レコード有無 | 代表セレクタの TXT が DNS に存在するか |
| サービスとの対応 | M365 / Google / ゲートウェイ各社が案内するセレクタ名との一致 |
| DMARC との関係 | SPF 失敗時に DKIM だけ通る設計になっているか（公開 DNS からは間接的な手がかり） |
受信した .eml 1 通から「DKIM-Signature ヘッダと DNS が一致するか」を見る依頼もあります（ 不審メール 1 通）。
含まないこと（よくある誤解）
- DKIM 鍵の生成・DNS への公開代行
- メールベンダー管理画面での DKIM 有効化
- 署名偽造の実証、ペンテスト
- 第三者ドメインへの調査
調査データは閉域環境内で扱います
.eml および調査結果は閉域環境内のみで保管・処理します。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。