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 に既に慣れている場合、または簡単な展開を行っており、DNS for Microsoft 365 の 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 は、送信者から受信者へのパスが直接パスである場合に最適に機能します。次に例を示します。
Woodgrovebank.com がメッセージを受け取る際に、IP アドレス # 1 が contoso.com の SPF TXT レコードにある場合は、メッセージは SPF チェックに合格し認証されます。
例 2:偽装された送信者のアドレスが SPF チェックに失敗する
フィッシャーが contoso.com を偽装する方法を見つけたとします。
IP アドレス #12 は contoso.com の SPF TXT レコードに含まれていないため、メッセージは SPF チェックに失敗し、受信者がスパムとしてマークすることを選択する場合があります。
例 3:SPF と転送されたメッセージ
SPF の欠点の 1 つは、メールが転送されたときに機能しないということです。 たとえば、woodgrovebank.com のユーザーが、outlook.com アカウントにすべての電子メールを送信する転送ルールを設定しているとします。
メッセージはもともと woodgrovebank.com で SPF チェックに合格しますが、IP #25 が contoso.com の SPF TXT レコードにないため、outlook.com の SPF チェックに失敗します。 このため、Outlook.com はメッセージをスパムとしてマークする可能性があります。 この問題を回避するには、DKIM や DMARC などの他の電子メール認証方法で SPF を使用します。
SPF の基本:自分のドメインに代わってメールを送信できるサード パーティのドメインを含める
IP アドレスに加えて、送信者としてドメインを含めるように SPF TXT レコードを構成することもできます。 これらは、"include" ステートメントとして SPF TXT レコードに追加されます。 たとえば、contoso.com は、contoso.net および contoso.org からのメール サーバーのすべての IP アドレスを含めることができます。この IP アドレスも所有しています。 これを行うには、contoso.com は次のような SPF TXT レコードを発行します。
v=spf1 include:contoso.net include:contoso.org -all
受信サーバーは、DNS でこのレコードを確認すると、CONTOSO.NET の SPF TXT レコードに対して DNS 参照を実行し、次に contoso.org に対して 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 アドレスを使用している場合は、この記事の例の ip4 を ip6 に置き換えます。 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=quarantine または 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 を設定したら、DKIM と DMARC for Microsoft 365 も構成する必要があります。 開始するには、「 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 レコードを作成 する」を参照してください。 スパム対策メッセージ ヘッダー には、MICROSOFT 365 で SPF チェックに使用される構文フィールドとヘッダー フィールドが含まれています。