MX と SPF は別のレコード
MX レコードは「このドメイン宛メールをどこで受け取るか」を示します。 SPFは「このドメインから送ってよいサーバーはどれか」を示します。 受信と送信で経路が異なるのが普通で、 SPF だけ整っていても足りない理由の一つがここです。
問題になりやすいのは、
実際にメールを送るサーバー（ゲートウェイ・フィルタ・レガシー MX）が
SPF の include / mx / ip4 に含まれていない状態です。
正規送信が SPF 失敗扱いになったり、逆にリスト外からのなりすましを止めにくかったりします。
現場で多い構成
- クラウドメール + ゲートウェイ — M365 / Google の前段にフィルタ SaaS
- 送信専用サービス — マーケメール・通知メールが別ベンダー
- BEC 対策・なりすまし検知 — 第三者 MX またはルーティング変更
- 移行の途中 — 旧 MX が DNS に残り SPF だけ新環境向け
管理画面では「メールは動いている」のに、 DNS を第三者視点で見ると送信経路が SPF に書かれていない、 というギャップが報告書に残ります。
サンプル報告書の所見（F-14 / F-19 / F-20）
架空の報告書サンプルでは、次のように整理しています。
- F-14（中） — MX ホスト
mx1.example.co.jpが SPF 本文に未記載。mx機構もincludeも見当たらない - F-19（低） — メールゲートウェイ一覧。MX 1 件、第三者 0 件、SPF 未記載 1 件。ベンダー別の推奨を表で提示
- F-20（低） — MX は存在するが SPF に
mx機構なし（includeのみの構成の可能性）
推奨アクションは「実際の送信経路を SPF に含める」「各ベンダーの SPF/DKIM 手順と DMARC 強化」など、 DNS とベンダー設定の突合が中心です。
MX と SPF — 確認するときのポイント
「SPF 設定済み」だけでは不十分なことがあります。 次の 3 点を押さえると、社内での共有やベンダーとの打合せがスムーズになります。
- 「メール受信の向き先（MX）」と「送信を許可するサーバー一覧（SPF）」は別帳簿
- フィルタや BEC 対策を入れたあと、DNS の更新が追いついていない可能性
- 修正は多くの場合、DNS 管理者とメールベンダーの役割分担
外部攻撃面レビューで「見る」こと（例）
| 観点 | 確認する内容（例） |
|---|---|
| MX | レコードの向き先ホスト名・優先度 |
| SPF | include / mx / ip4 と MX ホストの対応 |
| DKIM | ゲートウェイ経由送信時のセレクタ有無（DKIM） |
| DMARC | 認証失敗時のポリシー（p=） |
含まないこと（よくある誤解）
- MX 変更・SPF レコード編集の代行
- メールゲートウェイ管理画面へのログイン、ルール設定
- なりすましメールの送信テスト
- 社内メールログの全件調査
調査データは閉域環境内で扱います
調査結果は閉域環境内のみで保管・処理します。 公開 DNS への問い合わせは発生します。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。