この記事でわかること

  • SPF が DNS の TXT レコードで「このドメインから送ってよいサーバー」を宣言する仕組み
  • Envelope-From（送信元ドメイン）と From ヘッダーの違いと、SPF が検証する対象
  • 外部攻撃面・メール認証調査で最初に確認する公開情報の一つとしての SPF

SPF の役割（ざっくり）

メールには、表の差出人（From:）のほかに、 配送経路で使われる送信元ドメイン（Envelope-From 等）があります。 SPF は主に後者のドメインについて、 「届いたメールの送信元 IP は、このドメインの管理者が許可したサーバーか？」を問います。

許可リストはドメインの DNS に TXT レコードとして公開されます。 ログイン不要で第三者も読めるため、 外部攻撃面のメール認証調査では、 まず SPF の有無と内容を事実として整理します。

DNS 上ではどう見えるか

代表ドメイン（例: example.co.jp）に、 次のような TXT が載ります（値は一例です）。

v=spf1 include:_spf.example.net ip4:203.0.113.10 ~all

よく出てくる部品は次のとおりです。

記述（例） 意味（平易な表現）
v=spf1 SPF レコードであることの宣言
include: 別ドメインの SPF 定義を取り込む（クラウドメール・SaaS で多い）
ip4: / ip6: 許可する送信元 IP を直接列挙
mx MX レコードのホストから送ることを許可
a ドメインの A レコードから送ることを許可
~all / -all リスト外からの送信を「疑わしい」とする / 拒否する（厳しさが異なる）

1 ドメインに SPF 用 TXT は1 本にまとめるのが原則です。 複数行に分かれている・古いレコードが残っている、といった状態も外部から確認できます。

SPF・DKIM・DMARC の位置づけ

仕組み 主な問い
SPF（本記事） 送信元 IP は許可リストに載っているか
DKIM 署名はドメインの公開鍵で検証できるか
DMARC SPF / DKIM が失敗したメールをどう扱うか（p=）

SPF だけではなりすましを止めきれないことがあります（ SPF だけでは足りない理由）。 それでも SPF は「正規の送信経路が DNS に書かれているか」を見る入口です。

よくある状態

外部攻撃面レビューで「見る」こと（例）

観点 確認する内容（例）
レコード有無 代表ドメインに v=spf1 を含む TXT があるか
末尾の all ~all か -all か（リスト外をどう扱うか）
送信経路の網羅 MX・ゲートウェイ・利用中 SaaS が include / mx / ip4 に含まれるか
DMARC との関係 SPF 失敗時に受信側へどう指示するか（_dmarc の有無・p=）

不審メール 1 通（.eml）から「ヘッダの送信元と SPF 許可リストが整合するか」を見る入口もあります（ 不審メール 1 通）。 報告書の書き方の例は サンプル（架空企業）のメール認証所見を参照してください。

社内対策との境界

社内の迷惑メールフィルタや標的型メール訓練は受信側・社内の話です。 SPF は御社ドメインを装ったメールが取引先の受信箱に届くかに関わる DNS の話です。 レコードの追加・変更や M365 管理画面での設定代行は標準スコープ外です （役割分担は御社・DNS 管理者・メールベンダー側）。

含まないこと（よくある誤解）

調査データは閉域環境内で扱います

御社からお預かりした .eml や調査結果は当社事業所内の閉域環境でのみ保管・処理します。 公開 DNS への問い合わせは発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。

メール認証シリーズの読み順（参考）

  1. 本記事 — SPF とは
  2. SPF だけでは足りない理由
  3. DKIM とは
  4. DMARC がないと何が起きうるか
  5. DMARC を quarantine / reject へ
  6. メールゲートウェイと SPF
  7. 不審メール 1 通から始める
  8. TLS-RPT（SMTP TLS レポート） — 補足