Exchange の SPF チェック：Exchange での SPF レコードの確認、公開、および修正方法

2025年5月、 マイクロソフトは、 。適切な認証を行わずに1日あたり5,000通以上のメッセージをOutlook.comまたはHotmail.comに送信しているドメインの場合、それらのメッセージは受信トレイに届くことはありません。

GoogleとYahooは2024年2月、同様の要件を導入した。 2024年2月に導入した。Googleのメールセキュリティチームによると、この以前の対策により、Gmailユーザーが受信する認証されていないメッセージは約75%減少した。

脆弱な電子メール認証を直接悪用する「ビジネスメール詐欺」は、 FBI IC3インターネット犯罪報告書（2023年）によると、2023年に報告された被害額は29億ドルに達した。 

Exchange環境における問題は、SPFの失敗が黙って発生してしまう点です。Exchange Onlineでは、レコードに問題が生じても通知は行われません。合格率を表示する標準のダッシュボードも存在しません。多くのチームは、ユーザーからメールがバウンスしていると苦情が寄せられたり、マーケティング部門から開封率が急落したと報告があったりするなど、数週間経ってから初めてその事実を知るのです。

このガイドでは、ExchangeのSPFレコードを確認する4つの方法、Exchange Online、オンプレミス、ハイブリッド環境の各構成で正しいレコードを公開する方法、および最も一般的な SPFエラー （多くの中堅企業でSPFが機能しなくなる原因となる「10件のルックアップ制限」を含む）の修正方法、Exchange Onlineが内部で実際にSPFをどのように評価しているか、そして一度確認して放置するのではなく、SPFを継続的に監視する方法について解説します。

ExchangeのSPFレコードを確認する方法（手順解説）

SPFレコードを確認するには、4つの確実な方法があります SPFレコードを確認する確実な方法が4つあります。最速のものから最も包括的なものまでです。手っ取り早く確認したい場合は方法1を、運用状況を継続的に把握したい場合は方法4をご利用ください。

方法 1：SPF 照会ツールを使用する（最も速い方法）

1. 任意のSPFチェッカーを開いてください（ PowerDMARC SPFチェッカー は無料で、登録も不要です）
2. ドメイン名（例：yourdomain.com。http:// などのプレフィックスは含めないでください）を入力し、 
3. 出力を確認する

この検索では、いくつかのSPF検証結果が返されます。各出力フィールドの意味と、結果を確認する際に注意すべき点について説明します： 

レコードの解析結果が正常で、照合件数が6件であっても、正当な送信元が欠落している可能性があります。SPFチェッカーはDNS内の情報を検証しますが、どのIPアドレスが許可されるべきかまでは判断できません。

方法 2: Microsoft 365 管理センターで確認する

Microsoft 365 管理センターにサインインします。[設定] → [ドメイン] の順に選択し、対象のドメインを選択して、[DNS レコード] に移動します。「Microsoft Exchange」セクションで、TXT レコードのステータスが「OK」になっていることを確認してください。

ステータスが「無効なエントリ」と表示される場合、SPFレコードが存在しないか、必要な「include:spf.protection.outlook.com」という記述が含まれていません。これは、管理ポータルを離れることなくSPFを確認する最も手っ取り早い方法です。

方法 3: コマンドラインで確認する (nslookup / dig)

サーバー側のトラブルシューティングや、ブラウザからアクセスできない状況では、コマンドラインから直接ドメインのSPF TXTレコードを照会することができます。

次のいずれかのコマンドを実行してください： 

# Windows

nslookup -type=txt yourdomain.com

# Linux 

/ macOSdig txt yourdomain.com +short

出力には生のTXTレコードが表示されます。「v=spf1」で始まる行を探してください。そのような行が2つある場合は、複数のSPFレコードが存在することになり、これは即座にPermErrorとなります。他の作業を行う前に、これを修正してください。

方法 4：DMARC 集計レポートによる確認（最も信頼性の高い方法）

Gmail、Yahoo、Microsoft、Mail.ru、地域のISPなどの受信側からの集計レポートでは、単一のテストメッセージだけでなく、ドメインから送信されたすべてのメールにおけるSPFの合格率・不合格率が表示されます。これが、SPFの状態を継続的かつ包括的に把握する唯一の方法です。

rua=タグを指定してDMARCを発行している場合、すでにこれらのレポートは収集されています。多くの組織でレポートは取得されていますが、解析用のプラットフォームがなければ生のXMLは読み取れないため、実際に内容を確認しているのはごく一部に過ぎません。

PowerDMARCはこれらのレポートを毎日取り込み、送信元ごとの合格率・不合格率、DNSルックアップの追跡、および新たな不正送信者が現れた際の通知など、SPFに特化した分析結果を専用のダッシュボードに表示します。

方法 5: Exchange メッセージのヘッダーによる確認（実環境での検証）

実際の受信者がSPFをどのように評価しているかを確認するには：

• ご自身のドメインから外部のアドレス（個人のGmailアカウントでも構いません）にテストメールを送信してください。
• メッセージを開き、完全なヘッダーを取得してください。Outlookの場合：「ファイル」→「プロパティ」→「インターネットヘッダー」。OWAまたはGmailの場合：「ソースを表示」または「オリジナルを表示」。
• 「Authentication-Results」ヘッダーを探し、「spf=」フィールドを見つけてください。

以下は、注釈を付した該当するヘッダーの表示例です：

認証結果： 

spf=合格（送信元IPアドレスは40.107.22.83）  

smtp.mailfrom=yourdomain.com;  

dkim=pass（署名が検証されました）  

header.d=yourdomain.com;  

dmarc=pass action=none  

header.from=yourdomain.com;  

compauth=pass reason=100

spf=pass と表示された場合、送信元のIPアドレスがSPFレコードによって承認されていることが確認されます。spf=fail、spf=softfail、またはspf=permerror と表示された場合は、その具体的な結果から何が問題なのかがわかります：

• spf=fail: 送信元のIPアドレスがSPFレコードに一切記載されていません。
• spf=softfail: 該当のIPアドレスは承認されていませんが、レコードで「-all」の代わりに「~all」が使用されています。
• spf=permerror: SPFレコードに構造上の問題があります（ルックアップ数が10回を超えている、レコードが複数存在する、構文エラーなど）。

有効なExchange SPFレコードの例

Exchange Online (M365) で SPF レコードを公開する方法

Exchange OnlineのSPFレコードを公開するのは簡単です。しかし、必要な情報を正しく設定する段階で、多くのチームが失敗してしまいます。

ステップ1：すべての承認済み送信元を特定する

DNSの設定を変更する前に、ドメインを代表してメールを送信するすべてのシステムを点検してください。多くの組織では、対象となるシステムの数を30～50％過小評価しています。

• Microsoft 365 / Exchange Online → include:spf.protection.outlook.com
• マーケティングオートメーション（HubSpot、Mailchimp、Marketo、Pardot）→ それぞれ独自のインクルードファイルがあります
• CRM（Salesforce、Microsoft Dynamics）→ ベンダーのSPFドキュメントを確認してください
• トランザクションメール（SendGrid、Amazon SES、Postmark、Mailgun） → ベンダー固有のインクルード
• ヘルプデスク／チケット管理（Zendesk、Freshdesk、ServiceNow） → ベンダー固有の設定
• 人事・給与（BambooHR、Gusto、Workday） → 通知が自社ドメインから送信されているか確認する
• 従来のオンプレミスサーバー → IPv4：パブリックIPアドレスを持つ

これまで知らなかった送信者を発見する最も確実な方法は DMARC集計レポートです。あなたのドメインを名乗って送信しているすべての正当な（および不正な）送信元がそこに表示されます。

ステップ2：SPFレコードを作成する

バージョンタグから始め、承認済みソースを追加し、修飾子で終わります。

M365の基本例：

v=spf1 

include:spf.protection.outlook.com -all

HubSpotとSendGridを導入している典型的な中堅企業：

v=spf1 

以下を含める:spf.protection.outlook.com 

以下を含める：_spf.hubspot.com 

include:sendgrid.net -all

構築中にDNSルックアップの回数をカウントしてください。「include:」、「a:」、「mx:」、「ptr:」、「exists:」の各メカニズムが1回のルックアップを発生させます。「ip4:」および「ip6:」のメカニズムはカウントされません。ネストされた「include:」もカウント対象となります。これは、「include:spf.protection.outlook.com」自体が、Microsoftのインフラストラクチャを経由して処理されるため、内部でさらに2～4回のルックアップを消費するからです。

ステップ3：DNSにレコードを登録する

公開の手順はDNSプロバイダーによって多少異なりますが、基本的な流れは同じです：

一貫して使用する設定：

• レコードタイプです：TXT
• ホスト／名前: @（または空白。プロバイダによって異なります）
• TTL：テスト中は3600（1時間）、安定後は86400（24時間）

重要: ドメインごとにSPFレコードは1つだけにしてください。2つ目のv=spf1 TXTレコードは、検出されるのを待つだけのPermErrorとなります。DNSプロバイダーのプロビジョニングプロセスで、サービスを追加した際にレコードが自動作成される場合は、直ちに重複がないか確認してください。

ステップ4：公開されたレコードを確認する

• DNSの反映には5～60分ほどかかります（TTLやプロバイダーによって異なります）。
• 方法1の手順に従ってSPFルックアップを再度実行し、レコードが正しく解決されることを確認してください。
• M365 管理センターを確認してください（方法 2）。TXT ステータスが「OK」になっているはずです。
• 外部アドレスにテストメッセージを送信し、ヘッダーに「spf=pass」と表示されているか確認してください。
• DNS検索回数が10回未満であることを確認してください。

手動でレコードを作成したくない場合は、 PowerDMARC SPF ジェネレーター は、送信元を指定するだけで、適切な形式のレコードを出力します。

ハイブリッド Exchange 環境向けの SPF：オンプレミス + クラウド

ハイブリッド Exchange 環境では、電子メールが Microsoft 365 とオンプレミス環境の両方から同時に送信される可能性があるため、SPF の管理が大幅に複雑になります。特に移行期間中は、すべての送信経路が適切に処理されない限り、メールの送信経路が重複し、SPF チェックが検出されないまま失敗することがよくあります。

ハイブリッド環境の課題：2つのメール経路、1つのSPFレコード

ハイブリッド環境では、送信メールは次の3つの異なる経路を経由して送信されます：

• Exchange Onlineに直接接続：M365でホストされているメールボックスの場合
• オンプレミスのExchangeサーバーまたはEdge Transportサーバー：オンプレミスに残っているメールボックス用
• スマートホストまたはサードパーティのリレー：メールがパブリックインターネットに到達する前に外部経由でルーティングされる場合

各経路では、受信サーバーに対して異なる送信元IPアドレスが提示されます。SPFは、どの経路が意図されていたかには関与せず、実際に確認されたIPアドレスが承認されているかどうかのみを確認します。ドメインごとに1つのSPFレコードしか許可されないため、両方の経路を単一のSPFレコードでカバーする必要があります。

ハイブリッド Exchange 向けの SPF の構築方法

両方の認証パスを含めてください：

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ip4:203.0.113.11 -all

オンプレミスのIPアドレスとは、メールサーバーがインターネットへ送信する際に使用する対外向けアドレスを指し、内部のRFC 1918アドレスではありません。Edge Transportサーバーの送信コネクタ、および対外向けIPアドレスを決定するNATやファイアウォールのルールを確認してください。地理的な冗長性がある場合や複数の送信経路がある場合は、メールの送信元となり得るすべての対外向けIPアドレスをレコードに含める必要があります。

移行期間中のSPF（過渡状態）

段階的な移行またはカットオーバー移行では、メールボックスが両方の場所に存在し、メールがどちらの経路からも送信される期間が生じます。SPFは、その期間全体を通じて両方の経路をカバーする必要があります。

• 移行を開始する前に： SPFレコードが、オンプレミスのIPv4エントリと「include:spf.protection.outlook.com」の両方をカバーしていることを確認してください。
• 移行中は： 両方の認証設定はそのままにしておきます。DMARCの集計レポートを通じてSPFの合格率を監視してください。ルーティングの変更によりメールが予期せぬ経路を通るようになった場合、ユーザーが気付く前にレポートでその変化が確認できます。
• 移行完了後： オンプレミスのIPv4エントリを削除してください。SPFに古いIPアドレスを残しておくことはセキュリティ上のリスクとなります。もしそれらの古いIPアドレスがISPやクラウドプロバイダーによって再割り当てされた場合、新しいテナントがあなたのドメインとして認証済みメールを送信できてしまう可能性があります。

移行中に「切り替えがほぼ完了した」という理由でオンプレミスのIPアドレスを削除してしまうのは、よくある間違いです。たった1つのメールボックスが旧経路を経由し続けているだけで、そのユーザーのメール認証が機能しなくなる可能性があります。

Exchange のサブドメイン：SPF は継承されない

多くのハイブリッド組織が直面する重要な注意点として、サブドメインは親ドメインのSPFレコードを継承しないという点があります。もし marketing.yourdomain.com が別のESPを通じてメールを送信する場合、独自のSPF TXTレコードが必要です。ワイルドカードSPFレコードはプロトコルでサポートされていません。メールを送信するすべてのサブドメインは、DNSルートに独自のv=spf1レコードを公開する必要があります。

つまり、サブドメインを活用することは、SPFの負荷を分散させるための効果的な戦略でもあります。マーケティングメールは marketing.yourdomain.com 経由で、トランザクションメールは mail.yourdomain.com 経由で送信することで、各サブドメインに独自の10回のルックアップ枠を確保できます。これはRFCに準拠しており、メール配信事業者（ESP）からも広くサポートされ、企業環境でも広く採用されています。

Exchange Onlineはテナント内メールのSPFを確認しますか？

いいえ。Exchange Onlineでは、テナント内のメッセージは内部メールとして扱われるため、SPF評価は行われません。異なるテナント間（信頼されたパートナー組織間であっても）のメッセージについては、そのメールがパブリックなメールルーティング経路を経由するため、SPFチェックの対象となります。

1つのM365テナント内に複数のドメインを持つ組織の場合、各ドメインには独自のSPFレコードが必要です。CNAMEを使用してドメイン間でレコードを共有することは標準的な手法ではなく、確実に機能するとは限りません。

Exchangeでよく見られるSPFエラーとその解決方法

以下のトラブルシューティングの各シナリオは、すべて「症状 → 原因 → 解決策」という同じ診断の流れに従っています。

PermError: DNS 検索回数が多すぎます

• • 症状： SPFがPermErrorを返す。受信者がメールを迷惑メールとして処理したり、拒否したりする可能性がある。DMARCのアラインメントに失敗する。
  • 原因: SPFレコード内のDNSルックアップが10回を超えている（ネストされたインクルードを含む）。これは、複数のSaaSサービスを利用している組織において、最も一般的なSPFエラーの原因です。

• 修正手順（5つのステップ）：

• • ステップ 1: ネストされたインクルードを再帰的にカウントするSPFチェッカーを使用して、現在のルックアップ数を監査してください。
  • ステップ 2: 使用しなくなったサービスの不要なインクルードを削除します。
  • ステップ3： ベンダーのIPアドレスが安定しており、文書化されている場合は、「include:」を「ip4:」に置き換えてください。
  • ステップ4： 送信量が多い非企業系送信元（マーケティング、トランザクション）を、独自のSPFレコードを持つサブドメインに移行します。
  • ステップ 5: それでも10を超える場合は、PowerSPFなどのツールを使用してSPFフラット化またはマクロを実装し、インクルードをIPv4エントリに自動解決させ、ベンダーがIPアドレスを変更した際にもレコードを最新の状態に保つようにしてください。

変更前・変更後の例：

以前（14回の検索：PermError）：

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

（7回の検索：制限未満）：

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce と Zendesk を mail.yourdomain.com# Freshdesk はフラット化された IPv4 エントリに置き換えられました# a および mx メカニズムは削除されました（明示的な include と重複するため）

複数のSPFレコードが見つかりました

• 症状： SPFチェッカーが「複数のSPFレコード」エラーを返す。すべてのSPF評価が失敗する。
• 原因： 同じドメインに対して、v=spf1 で始まる TXT レコードが 2 つ以上存在しています。これは、SaaS ベンダーのプロビジョニングプロセスにより、管理者が気付かないうちに 2 つ目のレコードが作成された場合に、よく発生します。
• 修正： 1つのレコードに統合してください。1つのレコード内に複数の include: および ip4: メカニズムを含めることは可能ですが、ドメインごとに v=spf1 TXT レコードは1つだけです。重複しているエントリを削除してください。

新しいSaaSツールを追加した後にSPFが機能しなくなった

• 症状： 新しく追加したツールからのメールがSPF検証に失敗します。また、この新しいインクルードにより総ルックアップ数が10を超えた場合、他の送信者でも問題が発生する可能性があります。
• 原因： 新しいサービスの「includes:」がSPFに追加されていなかったか、追加した際にルックアップ制限を超過しました。
• 解決策： インクルードを追加し、その後、ルックアップの合計数を再確認してください。もし10を超えている場合は、インクルード自体ではなく、ルックアップの数が問題です。上記の5ステップのワークフローを適用してください。

ハイブリッド Exchange で SPF が失敗（オンプレミス IP アドレスが欠落）

• 症状： オンプレミスのExchangeから送信されたメールはSPF検証に失敗するが、M365から送信されたメールは通過する。
• 原因： オンプレミスサーバーの対外向けIPアドレスがSPFレコードに含まれていません。これは、管理者がExchange OnlineのSPFを更新したものの、オンプレミスへの経路でもメールがルーティングされていることを忘れてしまった場合、特に部分的な移行後に頻繁に発生します。
• 修正方法： オンプレミスのすべての送信元IPアドレスに対して、ip4:x.x.x.x を追加してください。メールがエッジトランスポートサーバー、スマートホスト、またはサードパーティのリレーを経由する場合、そのリレーのパブリックIPアドレスも追加する必要があります。

Exchange Onlineへの移行後にSPFが機能しなくなる

• 症状： 移行後のメールは、すべてSPF検証に失敗しています。
• 原因： DNSが依然として旧オンプレミスIPを指している、spf.protection.outlook.comが追加されていない、または移行中にメールが予期しない経路を経由している。
• 修正方法： 移行期間中は、SPFレコードに旧（オンプレミス）および新（Exchange Online）の両方の認証パスが含まれていることを確認してください。すべてのメールボックスの移行が完了したことを確認してから、旧エントリを削除してください。移行中は、DMARC集計レポートで状況を監視してください。これにより、受信者の視点からメールがどの経路を通っているかが正確に把握できます。

SPFは通過したのに、メールがスパムフォルダに入ってしまう

• 症状： ヘッダーには spf=pass と表示されているが、メッセージは受信者の迷惑メールフォルダに振り分けられる。
• 原因： SPFは多くのシグナルの一つに過ぎません。送信者のレピュテーション、コンテンツ、DKIM、またはDMARCに問題がある可能性があります。これらのいずれかが、SPFが正常に通過している場合でも、その結果を覆す可能性があります。
• 修正： DKIMのアライメント、DMARCポリシー、送信者のレピュテーション（ブラックリスト登録状況、ドメインの運用期間、直近の送信量の変化）、およびコンテンツやリンクのレピュテーションを確認してください。 PowerDMARCのDomain Analyzer は、これらすべてについて、1回のスキャンで評価結果を返します。

転送メールではSPFが機能しない

• 症状： 自動転送されたメッセージ、メーリングリストのメール、またはトランスポートルールによってルーティングされたメッセージがSPF検証に失敗する。
• 原因： 転送サーバーのIPアドレスが、元の送信者のSPFレコードに含まれていません。これは設定ミスではなく、SPFのアーキテクチャ上の制限です。
• 修正方法： 転送されたメールにおけるSPFの失敗を、想定された動作として扱うようにします。ドメインに対してDKIMが適切に構成されていることを確認してください。DKIM署名は転送後も維持されるため、SPFが失敗した場合でも、DKIMアラインメントを通じてDMARCの検証に合格することが可能です。Exchange OnlineのARC（Authenticated Received Chain）は、信頼された転送チェーン全体で認証結果を維持します。

Exchange Onlineが実際にSPFの結果をどのように処理しているか（ブラックボックスの仕組みを解説）

多くのExchange管理者が同じ疑問を抱えています。Exchange Online Protection（EOP）は、SPFエラーを実際にはどのように扱っているのでしょうか？ある情報源では、ハードフェイルは自動的に拒否されることを意味するとされています。一方で、SPFはスパム判定の軽微な指標に過ぎないと指摘する声もあります。ここでは、その実際の仕組みについて解説します。

マルチシグナル・パイプライン（SPFは単なる入力の一つに過ぎない）

Exchange Online Protection は、SPF のみに基づいて配信の可否を決定するわけではありません。SPF は、以下の要素を含む複合的な認証評価の一要素にすぎません。

• SPFの結果： 合格、不合格、ソフト失敗、中立、PermError、またはTempError
• DKIMの結果： 合格、不合格、またはなし
• DMARCの結果： ヘッダーの「From」ドメインとSPFまたはDKIMの照合結果に基づく
• 送信者のレピュテーション: IPレピュテーション、ドメインレピュテーション、過去の送信パターン
• スパム信頼度（SCL）スコア：マイクロソフトの内部スコアで、-1（安全な送信者）から9（スパムと判定される可能性が高い）までの範囲
• コンテンツフィルタリング： キーワード、URLの信頼性、添付ファイルの分析

EOPがメッセージの最終的な処理を決定する際には、個々のプロトコルではなく、統合された認証結果が用いられます。

EOPが各SPFの結果をどのように処理するか

PermErrorは、EOPが完全なSPF失敗とほぼ同様に扱う重大なエラーであり、これがDMARCに波及して認証機能を完全に機能不全に陥らせます。これが、10回のルックアップ制限が構造的な脆弱性となる理由です。

Exchange内でSPFの結果を確認する方法

網羅性の順に、3つの場所を挙げると：

• メッセージヘッダー（Authentication-Results）： EOPによって処理されるすべてのメッセージには、評価された送信ドメインおよびIPアドレスとともに、spf=pass/fail/softfail/permerror/temperrorというスタンプが付けられます。
• Exchangeのメッセージトレース： 配信状況、送信元IP、受信者、および最終的な処理結果が表示されますが、SPF評価の結果は目立つように表示されません。SPFの状態を確認するためにメッセージトレースのみに頼っている場合、手探りの状態です。
• DMARC集計レポート（RUA）： 世界中の受信サーバーがお客様のSPFをどのように評価しているかを示す唯一のデータソースです。RUAレポートでは、お客様のメールを処理するすべての受信サーバーについて、IPごと、送信元ごとのSPF合格率および不合格率が表示されます。

EOP での SPF ハードフェイルの適用設定

デフォルトでは、Exchange Online は SPF の結果を総合スコアに反映しますが、SPF のみを理由にメッセージを拒否することはありません。EOP が SPF に基づいて明示的にメッセージにフラグを立てるように設定するには SPFハードフェイル メッセージをスパムとしてマークするように明示的に設定するには：

Exchange Online 管理センターで、[保護] → [スパムフィルター] → [詳細オプション] の順に移動し、「SPF レコード: ハードフェイル」のスイッチを [オン] に設定します。または、次の PowerShell コマンドレットを実行します:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

2026年のExchange環境におけるSPFのベストプラクティス

• デフォルトの指定子として「-all」（ハードフェイル）を使用してください。DMARCと組み合わせた場合、「-all」が標準となります。唯一の例外は、DMARCが導入される前の初期導入期間です。
• 「+all」は絶対に使用しないでください。これを使用すると、インターネット上のすべてのユーザーがあなたのドメイン名でメールを送信できるようになってしまいます。レコードに「+all」が含まれているのを発見した場合は、重大なセキュリティインシデントとして扱ってください。
• M365をご利用の場合は、送信メールがサードパーティのゲートウェイを経由する場合でも、必ず spf.protection.outlook.com を指定してください。Exchange Online では、カレンダーの招待状、自動返信、配信不能通知 (NDR)、開封確認が生成され、これらは Microsoft のインフラストラクチャから直接送信されます。
• SPFレコードは少なくとも四半期に1回は監査してください。SaaSベンダーはIPアドレス範囲を変更することがあります。また、マーケティングチームがIT部門に連絡せずに新しいツールを導入することもあります。四半期ごとの監査を行うことで、PermErrorが発生する前に設定のずれを早期に発見できます。DMARCレポートによる継続的な監視を行えば、設定のずれをリアルタイムで把握できます。
• SPFは、DKIMおよびDMARCと併せて導入してください。SPFだけでは、ヘッダーの「From」フィールドのなりすましを防ぐことはできません。また、DKIMだけでは、エンベロープ送信者の検証は行われません。ヘッダーの「From」ドメインとSPFまたはDKIMの整合性を確認するDMARCの適用によってのみ、包括的な保護が実現されます。
• 主要な受信事業者すべてが定める送信者要件に準拠してください。2026年には、Google、Yahoo、Microsoft、Appleの各社が、大量送信者に対してSPF + DKIM + DMARCの採用を義務付ける予定です。2025年3月から適用が義務付けられるPCI DSS v4.0では、フィッシング対策としてこれら3つの要件を明示的に求めています。

SPFを継続的に監視する方法 

「SPFを設定済み」の組織と、実際にSPFによって保護されている組織との間にある最大の違いは、監視体制にあります。一度の設定は簡単ですが、その後の数ヶ月間にわたって発生する「サイレント・フェイル」を検知できるかどうかが、機能するメール認証と理論上のメール認証を分ける鍵となります。

なぜSPFの一回限りの確認では、誤った安心感を生み出してしまうのか

SPFレコードは常に変動しています。その理由は、ベンダーが許可されたIP範囲を変更したり、インクルードチェーンが異なるIPに解決されたりするためです。また、そのうちの1つがルックアップ制限を超えてしまう可能性もあります。チームがSPFを更新せずに新しいSaaSツールを追加したり、移行作業によって送信メールのルーティングが変更され、それがDNSに反映されない場合もあります。さらに、組織が数年前に使用を中止したサービスに関する古いエントリが残っていることもあります。

SPFの継続的なモニタリングとは

4つの構成要素があり、それぞれが特定の故障モードに対応しています：

• 世界中の受信サーバーから毎日収集されるDMARC集計レポート。これらは、お客様のメールを処理したすべての受信サーバーにおける、IPごと、送信元ごとのSPF結果を示しています。PowerDMARCはこれらのデータを自動的に収集し、送信元ごとの合格率・不合格率、DNS照会回数の追跡、および過去の推移を示す専用のSPF分析ダッシュボードに表示します。
• SPFの失敗が閾値を超えた瞬間、新しい不正な送信元が検出されたとき、またはDNSの変更がレコードに影響を与えた際に、自動的にアラートが送信されます。 PowerDMARCのPowerAlerts は、これらの通知をメール、Slack、またはDiscord経由で配信し、営業時間中に適切なチームが問題を確認できるようにします。
• SPFの自動フラット化 サードパーティプロバイダーがIPアドレスを変更した際に更新される。 PowerSPF は、`include:` チェーンを IPv4 エントリに変換し、手動での DNS 編集なしに、レコードのルックアップ回数を常に 10 回未満に抑えます。
• ブラックリストおよびレピュテーションの監視. 送信元のIPアドレスがブロックリストに登録されてしまうと、SPFは通過しても配信率は低下します。統合されたレピュテーション監視機能により、SPFだけでは検出できない配信失敗の原因を特定できます。

特にMSPの皆様へ：クライアントのベンダーがIPアドレス範囲を変更した場合、クライアントのメール機能が停止する前にその事実を把握できます。 

PowerDMARCのMSPダッシュボードは、単一の画面からすべてのクライアントドメインにわたるSPF監視を一元的に行え、テナントごとの詳細分析も可能です。これにより、SPF管理は事後対応型の対応策から、製品化されたサービスラインへと変革されます。

15日間の無料トライアルを開始して、ぜひご自身でお試しください。 

よくあるご質問

Exchange Online で SPF レコードを確認するにはどうすればよいですか？

PowerDMARC SPF CheckerなどのSPF検索ツールを使用し、ドメインを入力して、レコード、構文、および検索回数を確認してください。また、Microsoft 365 管理センターの [設定] → [ドメイン] → [DNS レコード] からも確認できます。受信側での確認については、外部に送信したテストメッセージの Authentication-Results ヘッダーを確認してください。

Microsoft 365 にはどのような SPF レコードが必要ですか？

最低限、v=spf1 include:spf.protection.outlook.com -all を設定してください。その他の送信サービス（HubSpot、SendGrid、Salesforce、Zendesk）を利用している場合は、-all の前にそれらの include を追加してください。各 include 内のネストされたルックアップを含め、DNS ルックアップの合計数が 10 未満になるようにしてください。

レコードは正しく設定されているはずなのに、なぜSPFが失敗するのでしょうか？

よくある原因：DNS 照会が 10 回の上限を超えている（PermError）、同じドメインに複数の SPF レコードが存在する、メールが転送されている（SPF は設計上、転送時に機能しなくなる）、またはベンダーが許可された IP 範囲を変更した際に通知がなかった場合などです。具体的な spf= の結果については、Authentication-Results ヘッダーを確認してください。

-all と ~all の違いは何ですか？

-all（ハードフェイル）は、受信側に許可されていないIPアドレスからのメッセージを拒否または失敗とするよう指示します。~all（ソフトフェイル）はより寛容な設定です。2026年にはDMARCが導入され、修飾子にかかわらずDMARCポリシーによって適用が制御されるようになります。まだDMARCを導入していない場合、-allの方がはるかに強力な保護を提供します。

「include:spf.protection.outlook.com」は、DNSルックアップを何回実行しますか？

Microsoftのインクルードは1回のルックアップとしてカウントされますが、これによって連鎖的に発生するネストされたインクルードにより、さらに約2～4回のルックアップが消費されます。正確な回数は、Microsoftによるインフラの更新に伴い変動します。必ず、ネストされたルックアップを再帰的にカウントするチェッカーを使用して確認してください。

SPFだけでメールのなりすましを防ぐことはできるのでしょうか？

いいえ。SPFだけでは、表示される「From:」アドレス（ヘッダーのFrom）のなりすましを防ぐことはできません。SPFは、エンベロープ送信者（Return-Path）の検証のみを行います。包括的な保護を実現するには、メッセージレベルの署名を行うDKIMに加え、整合性を確保するためのDMARCが必要です。これら3つのプロトコルを連携させ、継続的に監視することが、2026年の標準となります。