Microsoft 365 において Sender Policy Framework (SPF) を使用して、スプーフィングを防止する方法

ヒント

Office 365 プラン 2 のMicrosoft 365 Defenderの機能を無料で試すことができることをご存じですか? Microsoft 365 Defender ポータル試用版ハブで 90 日間のDefender for Office 365試用版を使用します。 サインアップできるユーザーと試用版の使用条件については、 こちらをご覧ください

適用対象

概要: この記事では、Microsoft 365 が DNS の Sender Policy Framework (SPF) TXT レコードを使用して、宛先電子メール システムがカスタム ドメインから送信されたメッセージを信頼する方法について説明します。 これは、Microsoft 365 から送信された送信メールに適用されます。 Microsoft 365 から Microsoft 365 内の受信者に送信されたメッセージは、常に SPF を渡します。

SPF TXT レコードは、電子メール メッセージの送信元のドメイン名を確認することで、スプーフィングやフィッシングを防ぐのに役立つ DNS レコードです。 SPF は、送信者の IP アドレスを送信ドメインの疑わしい所有者に対して検証することで、電子メール メッセージの配信元を検証します。

注:

SPF レコードの種類は、2014 年にインターネット技術標準化委員会 (IETF) によって廃止されました。 代わりに、SPF 情報を公開するには、DNS で TXT レコードを必ず使用してください。 この記事の以降の部分では、わかりやすいように SPF TXT レコードという用語を使用します。

ドメイン管理者は DNS の TXT レコードで SPF 情報を公開します。 この SPF 情報は、承認された送信メール サーバーを識別します。 送信先メール システムにより、承認された送信メール サーバーからメッセージが発信されたことが確認されます。 SPF に既に精通している場合、または簡単なデプロイがあり、MICROSOFT 365 用 DNS の SPF TXT レコードに何を含めるかを知る必要がある場合は、 スプーフィングを防ぐために Microsoft 365 で SPF を設定するに進むことができます。 Microsoft 365 で完全にホストされている展開がない場合や、SPF のしくみや Microsoft 365 の SPF のトラブルシューティング方法の詳細については、引き続きご覧ください。

注:

以前は、SharePoint Online も使用している場合、カスタム ドメインに別の SPF TXT レコードを追加する必要がありました。 この作業を行う必要はなくなりました。 この変更により、SharePoint Online の通知メッセージが [迷惑メール] フォルダーに振り分けられるリスクが軽減されます。 すぐに変更を加える必要はありませんが、"参照が多すぎる" というエラーが表示された場合は、「 スプーフィングを防ぐために Microsoft 365 で SPF を設定する」の説明に従って SPF TXT レコードを変更します。

MICROSOFT 365 でのスプーフィングとフィッシングを防ぐための SPF のしくみ

SPF は、送信者がドメインの代理として送信することを許可されているかどうかを判断します。 送信者が許可されていない場合、つまり、電子メールが受信側サーバーで SPF チェックに失敗した場合、そのサーバーに構成されたスパム ポリシーによってメッセージの処理が決定されます。

各 SPF TXT レコードには、SPF TXT レコードであるという宣言、ドメインからのメール送信が許可されている IP アドレス、ドメインに代わって送信できる外部ドメイン、および適用規則の 3 つの部分が含まれています。 有効な SPF TXT レコードには、3 つすべてが必要です。 この記事では、SPF TXT レコードを作成する方法と、Microsoft 365 のサービスを操作するためのベスト プラクティスについて説明します。 ドメイン レジストラーと連携してレコードを DNS に発行する手順へのリンクも記載されています。

SPF の基本: カスタム ドメインからの送信が許可された IP アドレス

SPF ルールの基本的な構文を見てみましょう。

v=spf1 <IP><適用規則>

たとえば、contoso.com に対して次の SPF ルールが存在するとします。

v=spf1 <IP アドレス #1><IP アドレス #2><IP アドレス #3><適用規則>

この例では、SPF ルールは、ドメイン contoso.com について、これらの IP アドレスからのメールのみを受け入れるように受信電子メール サーバーに指示します。

  • IP アドレス #1

  • IP アドレス #2

  • IP アドレス #3

この SPF ルールは受信メール サーバーに、メッセージが contoso.com からのものであるものの、これら 3 つの IP アドレスのいずれからのものでもない場合、受信側サーバーはメッセージに対して強制ルールを適用する必要があることを指示します。 通常、強制ルールは次のオプションのいずれかです。

  • Hard fail。 メッセージ エンベロープ内に 'hard fail' を含むメッセージをマークし、受信側サーバーでこの種類のメッセージに対して構成されたスパム ポリシーに従います。

  • Soft fail。 メッセージ エンベロープ内に 'soft fail' を含むメッセージをマークします。 通常、電子メール サーバーはこれらのメッセージを配信するように構成されます。 ほとんどのエンド ユーザーには、このマークは表示されません。

  • 中立。 何もしないでください。つまり、メッセージ エンベロープにマークを付けないでください。 これはテスト目的で予約されており、ほとんど使用しません。

次の例は、さまざまな状況での SPF のしくみを示しています。 これらの例では、contoso.com は送信者、woodgrovebank.com は受信者です。

例 1:送信者から受信者に直接送信されるメッセージの電子メール認証

SPF は、送信者から受信者へのパスが直接パスである場合に最適に機能します。次に例を示します。

サーバーからサーバーへ直接送信されるときに SPF がメールを認証する方法を示す図。

Woodgrovebank.com がメッセージを受け取る際に、IP アドレス # 1 が contoso.com の SPF TXT レコードにある場合は、メッセージは SPF チェックに合格し認証されます。

例 2:偽装された送信者のアドレスが SPF チェックに失敗する

フィッシャーが contoso.com を偽装する方法を見つけたとします。

偽装しているサーバーから送信されるときに SPF がメールを認証する方法を示す図。

IP アドレス #12 は contoso.com の SPF TXT レコードに含まれていないため、メッセージは SPF チェックに失敗し、受信者はそれをスパムとしてマークすることを選択できます。

例 3:SPF と転送されたメッセージ

SPF の欠点の 1 つは、電子メールが転送されたときに機能しない点です。 たとえば、woodgrovebank.com のユーザーが、outlook.com アカウントにすべての電子メールを送信する転送ルールを設定しているとします。

電子メール メッセージが転送される際に SPF がメールを認証できないことを示す図。

メッセージはもともと woodgrovebank.com で SPF チェックに合格しますが、IP #25 が contoso.com の SPF TXT レコードに含まれていないため、outlook.com で SPF チェックが失敗します。 このため、Outlook.com はメッセージをスパムとしてマークする可能性があります。 この問題を回避するには、DKIM や DMARC などの他の電子メール認証方法で SPF を使用します。

SPF の基本:自分のドメインに代わってメールを送信できるサード パーティのドメインを含める

IP アドレスに加えて、送信者としてドメインを含めるように SPF TXT レコードを構成することもできます。 これらは、SPF TXT レコードに "include" ステートメントとして追加されます。 たとえば、contoso.com は、contoso.net と contoso.org のメール サーバーのすべての IP アドレスを含める必要があります。このアドレスも所有しています。 これを行うには、contoso.com は次のような SPF TXT レコードを発行します。

v=spf1 include:contoso.net include:contoso.org -all

受信側サーバーでは、DNS でこのレコードが表示されると、CONTOSO.NET と contoso.org の SPF TXT レコードに対して DNS 参照も実行されます。contoso.net または contoso.org のレコード内で別の include ステートメントが見つかると、そのステートメントもそれに従います。 サービス拒否攻撃を防止するための、1 つの電子メール メッセージに対する DNS 参照の最大数は 10 です。 各 include ステートメントは追加の DNS 参照を表します。 メッセージが上限 10 を超えると、メッセージは SPF チェックに失敗します。 メッセージがこの制限に達すると、受信側サーバーの構成方法に応じて、メッセージが生成された "参照が多すぎます" または "メッセージの最大ホップ数を超えた" というメッセージを送信者が受け取ることがあります (これは、ルックアップループがループし、DNS タイムアウトを超えた場合に発生する可能性があります)。 これを回避する方法のヒントについては、「 トラブルシューティング: Microsoft 365 の SPF のベスト プラクティス」を参照してください。

SPF TXT レコードと Microsoft 365 の要件

Microsoft 365 のセットアップ時にメールを設定した場合は、ドメインの正当なメールソースとして Microsoft メッセージング サーバーを識別する SPF TXT レコードが既に作成されています。 このレコードは、おそらく次のようになります。

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

完全にホストされている顧客である場合、つまり送信メールを送信するオンプレミスのメール サーバーがない場合は、これが、Office 365用に発行する必要がある唯一の SPF TXT レコードです。

ハイブリッド展開がある場合 (つまり、一部のメールボックスがオンプレミスにあり、Microsoft 365 でホストされているメールボックスがあります)、またはExchange Online Protection (EOP) スタンドアロンのお客様 (つまり、組織が EOP を使用してオンプレミス メールボックスを保護している場合) は、オンプレミス エッジ メール サーバーごとに送信 IP アドレスを DNS の SPF TXT レコードに追加する必要があります。

Microsoft 365 の SPF TXT レコードを作成する

この記事に記載されている構文の情報を使って、カスタム ドメイン用の SPF TXT レコードを形成します。 ここに記載されていない他の構文オプションもありますが、これらが最もよく使うオプションです。 レコードの作成後には、ドメイン レジストラーでレコードを更新する必要があります。

Microsoft 365 に含める必要があるドメインの詳細については、「 SPF に必要な外部 DNS レコード」を参照してください。 ドメイン レジストラーの SPF (TXT) レコードを更新するための 詳細な手順 を使用します。

Microsoft 365 の SPF TXT レコード構文

Microsoft 365 の一般的な SPF TXT レコードには、次の構文があります。

v=spf1 [<ip4>|<ip6>:<IP address>] [include:<domain name>] <enforcement rule>

以下に例を示します。

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 include:spf.protection.outlook.com -all

各部分の意味は次のとおりです。

  • v=spf1 は必須です。 これは、SPF TXT レコードとして TXT レコードを定義します。

  • ip4 は、IP バージョン 4 アドレスを使用していることを示します。 ip6 は、IP バージョン 6 アドレスを使用していることを示します。 IPv6 IP アドレスを使用している場合は、この記事の例の ip4ip6 に置き換えます。 CIDR 表記を使用して IP アドレス範囲を指定することもできます (たとえば、ip4:192.168.0.1/26)。

  • IP address は、SPF TXT レコードに追加する IP アドレスです。 通常、これは組織の送信メール サーバーの IP アドレスです。 複数の送信メール サーバーを一覧表示できます。 詳細については、「 例: 複数の送信オンプレミスメール サーバーと Microsoft 365 の SPF TXT レコード」を参照してください。

  • domain name は、正当な送信者として追加するドメインです。 Microsoft 365 に含める必要があるドメイン名の一覧については、「 SPF に必要な外部 DNS レコード」を参照してください。

  • 通常、強制ルールは次のいずれかです。

    • -all

      hard fail を示します。 ドメインの承認済み IP アドレスがすべてわかっている場合は、SPF TXT レコードにリストし、-all (ハード フェール) 修飾子を使用します。 また、SPF のみを使用している場合、つまり DMARC または DKIM を使用していない場合は、-all 修飾子を使用する必要があります。 常にこの修飾子を使用することをお勧めします。

    • ~すべての

      soft fail を示します。 IP アドレスの完全な一覧がわからない場合は、~all (論理的な失敗) 修飾子を使用する必要があります。 また、p=検疫または p=reject で DMARC を使用している場合は、~all を使用できます。 それ以外の場合は、-all を使用します。

    • 。すべての

      neutral を示します。 SPF のテスト時に使用されます。 ライブ デプロイでは、この修飾子を使用することはお勧めしません。

例: すべてのメールが Microsoft 365 によって送信されたときに使用する SPF TXT レコード

すべてのメールが Microsoft 365 によって送信される場合は、SPF TXT レコードでこれを使用します。

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

例: 1 つのオンプレミス Exchange Serverと Microsoft 365 を使用したハイブリッド シナリオの SPF TXT レコード

ハイブリッド環境で、オンプレミスの Exchange Server の IP アドレスが 192.168.0.1 である場合、SPF の強制ルールを hard fail に設定するために、SPF TXT レコードを次のように形成します。

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

例: 複数の送信オンプレミスメール サーバーと Microsoft 365 の SPF TXT レコード

複数の送信メール サーバーがある場合は、SPF TXT レコードに各メール サーバーの IP アドレスを含め、各 IP アドレスをスペースと "ip4:" ステートメントで区切ります。 以下に例を示します。

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 include:spf.protection.outlook.com -all

次の手順: Microsoft 365 の SPF を設定する

SPF TXT レコードを作成したら、「 Microsoft 365 で SPF を設定する」の手順に従って、スプーフィングを防止して ドメインに追加します。

SPF はスプーフィングを防ぐために設計されていますが、SPF では保護できないスプーフィング手法があります。 これらを防ぐために、SPF を設定したら、Microsoft 365 用に DKIM と DMARC も構成する必要があります。 開始するには、「 DKIM を使用して、Microsoft 365 のカスタム ドメインから送信された送信メールを検証する」を参照してください。 次に、 DMARC を使用して Microsoft 365 で電子メールを検証する方法に関するページを参照してください。

トラブルシューティング: Microsoft 365 での SPF のベスト プラクティス

カスタム ドメインに作成できる SPF TXT レコードは 1 つのみです。 複数のレコードを作成すると、ラウンド ロビン状況の原因となり、SPF が失敗します。 これを避けるために、各サブドメインに対して個別にレコードを作成できます。 たとえば、contoso.com に 1 つのレコードを作成し、bulkmail.contoso.com に別のレコードを作成します。

電子メール メッセージが配信される前に 10 を超える DNS 参照が発生した場合、受信メール サーバーは永続的なエラー ( permerror とも呼ばれます) で応答し、メッセージが SPF チェックに失敗します。 また、受信側のサーバーは、次のようなエラーを含む配信不能レポート (NDR) で応答することもあります。

  • メッセージのホップ数を超えました。

  • メッセージに必要な参照数が多すぎます。

Microsoft 365 でサード パーティのドメインを使用するときに "参照が多すぎる" というエラーを回避する

サード パーティのドメインの SPF TXT レコードには、受信側のサーバーに多数の DNS 参照を実行するよう指示するものがあります。 たとえば、この記事の執筆時には、Salesforce.com のレコードに 5 つの include ステートメントが含まれています。

v=spf1 include:_spf.google.com
include:_spfblock.salesforce.com
include:_qa.salesforce.com
include:_spfblock1.salesforce.com
include:spf.mandrillapp.com mx ~all

エラーを回避するために、(たとえばバルク メールを送信する) あらゆるユーザーがサブドメインを使用する必要があるというポリシーを、特にこの目的のために実装できます。 次にバルク メールを含むサブドメイン用の別の SPF TXT レコードを定義します。

salesforce.com の例などのように、SPF TXT レコードでドメインを使用する必要がある場合がありますが、サードパーティがこの目的のためにユーザーの使用するサブドメインを既に作成している場合もあります。 たとえば、exacttarget.com は、SPF TXT レコードに対して使用する必要があるサブドメインを作成しました。

cust-spf.exacttarget.com

SPF TXT レコードにサード パーティのドメインを含む場合は、参照の上限値 10 に達することを回避するために、どのドメインまたはサブドメインを使用するかを、サードパーティに確認する必要があります。

現在の SPF TXT レコードを表示し、それに必要な参照数を決定する方法

nslookup を使用して、SPF TXT レコードなどの DNS レコードを表示できます。 SPF TXT レコードの内容を表示するために使用できる無料のオンライン ツールが多数用意されています。 SPF TXT を参照し、一連の include ステートメントとリダイレクトに従って、レコードが必要とする DNS 参照数を判断できます。 オンライン ツールには、これらの参照数をカウントして表示するものもあります。 この番号を追跡すると、組織から送信されたメッセージが、受信サーバーから永続的なエラー (perm エラーと呼ばれる) をトリガーするのを防ぐのに役立ちます。

詳細情報

SPF TXT レコードの追加に関するヘルプが必要ですか? Microsoft 365 のカスタム ドメインで Sender Policy Framework を使用する方法の詳細については、 Microsoft 365 の DNS ホスティング プロバイダーで DNS レコードを作成 する方法に関する記事を参照してください。 スパム対策メッセージ ヘッダー には、SPF チェックに Microsoft 365 で使用される構文フィールドとヘッダー フィールドが含まれます。