SPF が担う役割
SPF（Sender Policy Framework）は、ドメインの DNS に 「このドメインのメールは、これらのサーバーから送ってよい」と書く仕組みです。 受信側は送信元 IP がリストに載っているかを照合します。
管理画面でクラウドメールを有効にすると SPF 用の TXT が案内されることが多いですが、
案内どおりに入っているか・送信経路すべてをカバーしているかは、
ご依頼・契約ごとに DNS を見て確認する必要があります。
前の記事で触れたDMARCとは別のレイヤーです。
「SPF あり」でも起きうること
SPF レコードが存在しても、次のような状態では なりすましメールが届きやすいことがあります。
- DMARC がない / p=none のまま — SPF 認証に失敗しても、受信側が拒否する指示が DNS にない
- ~all（ソフトフェイル） — リスト外からの送信を「疑わしい」とマークするだけで、拒否とは限らない
- 送信経路の漏れ — マーケティング SaaS・請求システム・旧 MX など、実際に使うサーバーが SPF に未記載
- DKIM 未設定 — SPF が転送で壊れた経路でも、DKIM が通れば DMARC 判定に使える場合がある（逆に DKIM も無いと選択肢が減る）
- From と Envelope-From のズレ — 表示上の差出人と SPF が照合するドメインが一致しないメールは、受信側の解釈が分かれる
つまり SPF は「許可リスト」の一部にすぎず、 認証失敗時にどうするか（DMARC）と 改ざん検知（DKIM）が揃って初めて、 なりすまし抑止の仕組みとして整います。
現場で多いパターン
| DNS 上の状態（例） | 意味（平易な表現） |
|---|---|
| SPF のみ、DMARC なし | 送信元リストはあるが、なりすましを止めるルールが未公開 |
SPF ~all |
リスト外からの送信を完全には拒否していない（移行期の設定が残っていることも） |
| include が多段 | 委譲先ベンダー追加時に更新漏れが起きやすい。誰が DNS を触るか要確認 |
| MX ホストが SPF 未記載 | メールゲートウェイから送る経路が許可リストに載っていない可能性（サンプル報告書 F-14 参照） |
報告書での書き方の例は サンプル（架空企業）の メール認証・MX / SPF 整合性の所見を参照してください。
社内対策・ベンダー設定との境界
メールゲートウェイのスパムスコアや、社内向けの標的型メール訓練は 受信側・社内の話です。 SPF / DMARC の DNS レコードは、 御社ドメインを装ったメールが取引先の受信箱に届くかに効きます。
外部攻撃面レビューでは、権限のない第三者が DNS から読める事実として SPF・DKIM・DMARC を整理します。 レコードの追加・変更や M365 管理画面での設定代行は標準スコープ外です （役割分担は御社・DNS 管理者・メールベンダー側）。
含まないこと（よくある誤解）
- DNS レコードの変更代行や、送信テストメールの大量配信
- 社内メールボックスへの侵入調査
- 第三者ドメイン・無許可資産へのスキャン
- ログイン突破までの侵入実証（ペンテストは別契約）
調査データは閉域環境内で扱います
御社からお預かりした .eml や調査結果は当社事業所内の閉域環境でのみ保管・処理します。 公開 DNS への問い合わせは発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 調査画面のログインはお渡しせず、報告書（PDF 等）を基本メールで納品します。
次に見るべきこと
SPF の事実整理のあと、多くの場合は次の順で優先度を整理します。
- 送信経路の網羅 — 実際に使う SaaS・MX・通知メールが SPF / DKIM に載っているか
- DMARC の有無と p= — 未設定ならなりすましリスクの説明から
- ポリシー強化 —
p=noneから quarantine / reject へ段階的に
入口は外部攻撃面全体の地図づくりからでも、 不審メール 1 通の DNS 整理からでも構いません。 詳細はお問い合わせください。