Microsoft 365 ドメインの有効なメール ソースを識別するように SPF を設定する

Sender Policy Framework (SPF) は、Microsoft 365 organizationから送信されたメールを検証して、ビジネス メール侵害 (BEC)、ランサムウェア、その他のフィッシング攻撃で使用されるなりすまし送信者を防ぐのに役立つ電子メール認証の方法です。

SPF の主な目的は、ドメインのメール ソースを検証することです。 具体的には、SPF は DNS の TXT レコードを使用して、ドメインの有効なメール ソースを識別します。 受信メール システムは、SPF TXT レコードを使用して、メッセージの SMTP 送信中に使用される送信者アドレス (MAIL FROM アドレス、 5321.MailFrom アドレス、P1 送信者、またはエンベロープ送信者) からのメールがそのドメインの既知の指定されたメール ソースからのメールであることを確認します。

たとえば、Microsoft 365 のメール ドメインが contoso.com されている場合は、contoso.com ドメインの DNS に SPF TXT レコードを作成して、Microsoft 365 を contoso.com からの承認されたメール ソースとして識別します。 宛先メール システムは、contoso.com の SPF TXT レコードをチェックして、メッセージが電子メールの承認されたソースから送信されたかどうかを判断 contoso.com。

作業を開始する前に、メール ドメインに基づいて Microsoft 365 の SPF について知る必要がある内容を次に示します。

• メールに Microsoft Online Email ルーティング アドレス (MOERA) ドメイン (たとえば、contoso.onmicrosoft.com) のみを使用する場合: 何もする必要はありません。 SPF TXT レコードは既に構成されています。 Microsoft は onmicrosoft.com ドメインを所有しているため、そのドメインとサブドメインで DNS レコードを作成および管理する責任があります。 *.onmicrosoft.com ドメインの詳細については、「 "onmicrosoft.com" ドメインがある理由」を参照してください。

• メールに 1 つ以上のカスタム ドメイン (たとえば、contoso.com) を使用する場合: Microsoft 365 登録プロセスでは、カスタム ドメインの DNS で SPF TXT レコードを作成または変更して、承認されたメール ソースとして Microsoft 365 を識別する必要がありました。 ただし、メール保護を最大限に高めるために、さらに多くの作業を行うことができます。

  • サブドメインに関する考慮事項:

    • 直接制御下にないメール サービス (一括メール サービスなど) の場合は、メインメール ドメイン (contoso.com など) ではなくサブドメイン (marketing.contoso.com など) を使用することをお勧めします。 これらのメール サービスから送信されたメールに関する問題が、メインメール ドメイン内の従業員から送信されたメールの評判に影響を与える必要はありません。 サブドメインの追加の詳細については、「 カスタム サブドメインまたは複数のドメインを Microsoft 365 に追加できますか?」を参照してください。

    • Microsoft 365 からメールを送信するために使用する各サブドメインには、独自の SPF TXT レコードが必要です。 たとえば、contoso.com の SPF TXT レコードは marketing.contoso.com をカバーしていません。marketing.contoso.com 独自の SPF TXT レコードが必要です。

      ヒント

      未定義のサブドメインのEmail認証保護は、DMARC によってカバーされます。 サブドメイン (定義されているかどうか) は、親ドメインの DMARC 設定を継承します (サブドメインごとにオーバーライドできます)。 詳細については、「 DMARC を設定して Microsoft 365 の送信者の差出人アドレス ドメインを検証する」を参照してください。

  • 登録済みで未使用のドメインを所有している場合: 電子メールや何か ( パークされたドメインとも呼ばれます) に使用されていない登録済みドメインを所有している場合は、この記事で後述するように、SPF TXT レコードを構成して、それらのドメインからのメールが送信されないようにします。

• SPF だけでは十分ではありません。 カスタム ドメインに最適なレベルの電子メール保護を行うには、 全体的な電子メール認証 戦略の一環として DKIM と DMARC を構成する必要もあります。 詳細については、この記事の最後にある 「次の手順 」セクションを参照してください。

  重要

  ドメインのすべての有効なメール ソースを特定することが困難な複雑な組織では、ドメインの DKIM 署名と DMARC ("アクションなし" モード) をすばやく構成することが重要です。 DMARC レポート サービスは、ドメインのメール ソースと SPF エラーを特定するのに非常に役立ちます。

この記事の残りの部分では、Microsoft 365 のカスタム ドメイン用に作成する必要がある SPF TXT レコードについて説明します。

SPF TXT レコードの構文

SPF TXT レコードは RFC 7208 で完全に説明されています。

Microsoft 365 のカスタム ドメインの SPF TX レコードの基本的な構文は次のとおりです。

v=spf1 <valid mail sources> <enforcement rule>

または

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

以下に例を示します。

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

• v=spf1 は、TXT レコードを SPF TXT レコードとして識別します。

• 有効なメール ソース: ドメインの有効なメール ソースを指定します。 ドメイン、IP アドレス、またはその両方を使用します。

  • ドメイン: include: 値は、元のドメインからの有効なメール ソースとして他のサービスまたはドメインを指定します。 これらの値は、最終的には DNS 参照を使用した IP アドレスにつながります。

    ほとんどの Microsoft 365 組織では、ドメインの SPF TXT レコードに include:spf.protection.outlook.com が必要です。 他のサード パーティのメール サービスでは、多くの場合、元のドメインからの有効なメール ソースとしてサービスを識別するために、追加の include: 値が必要になります。

  • IP アドレス: IP アドレス値には、次の両方の要素が含まれます。

    • IP アドレスの種類を識別するために ip4: 値または ip6: 。
    • ソース 電子メール システムのパブリックに解決可能な IP アドレス。 以下に例を示します。
      • 個々の IP アドレス (192.168.0.10 など)。
      • クラスレス Inter-Domain ルーティング (CIDR) 表記 (192.168.0.1/26 など) を使用した IP アドレス範囲。 範囲が大きすぎたり小さすぎたりしないようにしてください。

    Microsoft 365 では、通常、SPF TXT レコードで IP アドレスを使用するのは、Microsoft 365 ドメインからメールを送信するオンプレミスのメール サーバー (ハイブリッド展開など) がある場合Exchange Serverのみです。 一部のサード パーティの電子メール サービスでは、SPF TXT レコードの include: 値ではなく IP アドレス範囲を使用する場合もあります。

• 適用規則: ドメインの SPF TXT レコードに指定されていないソースからのメッセージの処理方法を宛先メール システムに伝えます。 有効な値は次のとおりです。

  • -all (ハード フェイル): SPF TXT レコードに指定されていないソースは、ドメインのメールを送信する権限がないため、メッセージは拒否する必要があります。 メッセージに対して実際に何が起こるかは、宛先のメール システムによって異なりますが、通常、メッセージは破棄されます。

    Microsoft 365 ドメインの場合は、ドメインに DKIM と DMARC も推奨されるため、 -all (ハード フェイル) することをお勧めします。 DMARC ポリシーは、SPF または DKIM に失敗したメッセージに対して何を行うかを指定します。DMARC レポートを使用すると、結果を検証できます。

    ヒント

    既に示したように、DMARC レポート サービスを使用して構成された DMARC は、ドメインの電子メール ソースと SPF エラーを識別するのに大きく役立ちます。

  • ~all (論理的な失敗): SPF TXT レコードに指定されていないソースは、ドメインのメールを送信する権限がない 可能性 があるため、メッセージは受け入れられるがマークされている必要があります。 メッセージに対して実際に何が起こるかは、送信先のメール システムによって異なります。 たとえば、メッセージがスパムとして検疫されたり、迷惑メール Email フォルダーに配信されたり、件名またはメッセージ本文に識別子が追加された受信トレイに配信されたりすることがあります。

    Microsoft 365 ドメインには DKIM と DMARC も推奨されるため、 -all (ハード フェイル) と ~all (ソフト フェイル) の違いは効果的に排除されます (DMARC では、どちらの結果も SPF エラーとして扱われます)。 DMARC は SPF を使用して、MAIL FROM アドレスと From アドレスのドメインが揃っていることを確認 し、 メッセージは From ドメインの有効なソースから送信されました。

  ヒント

  ?all (ニュートラル) は、未確認のソースからのメッセージに対する特定のアクションを提案するためにも使用できます。 この値はテストに使用され、運用環境ではこの値をお勧めしません。

覚えておくべき重要なポイント:

• DNS で定義された各ドメインまたはサブドメインには SPF TXT レコードが必要であり、ドメインまたはサブドメインごとに許可される SPF レコードは 1 つだけです。 未定義のサブドメインのEmail認証保護は、DMARC によって最適に処理されます。
• *.onmicrosoft.com ドメインの既存の SPF TXT レコードを変更することはできません。
• 宛先メール システムが SPF レコード内の有効なメール ソースをチェックすると、チェックで DNS 参照が多すぎる場合、SPF 検証は失敗します。 詳細については、この記事の後半の 「SPF TXT レコードのトラブルシューティング 」セクションを参照してください。

Microsoft 365 のカスタム ドメインの SPF TXT レコード

• シナリオ: Microsoft 365 では電子メールに contoso.com を使用し、Microsoft 365 が contoso.com からの唯一のメール ソースです。

  Microsoft 365 および Microsoft 365 Government Community Cloud (GCC) の contoso.com の SPF TXT レコード:

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

  Microsoft 365 Government Community Cloud High (GCC High) と Microsoft 365 国防総省 (DoD) の contoso.com の SPF TXT レコード:

  v=spf1 include:spf.protection.office365.us -all
  

  21Vianet が運営する Microsoft 365 の contoso.com の SPF TXT レコード

  v=spf1 include:spf.protection.partner.outlook.cn -all
  

• シナリオ: Microsoft 365 でメールに contoso.com を使用し、ドメインからのすべてのメール ソースを含む SPF TXT レコードを contoso.com で既に構成しています。 また、ドメインの contoso.net と contoso.org も所有していますが、メールには使用しません。 contoso.net または contoso.org から電子メールを送信する権限を持つユーザーがいないことを指定する必要があります。

  contoso.net の SPF TXT レコード:

  v=spf1 -all
  

  contoso.org の SPF TXT レコード:

  v=spf1 -all
  

• シナリオ: Microsoft 365 で電子メールに contoso.com を使用します。 次のソースからメールを送信する予定です。

  • 外部メール アドレスが 192.168.0.10 のオンプレミスの電子メール サーバー。 このメール ソースを直接制御できるため、contoso.com ドメイン内の送信者にサーバーを使用しても問題ありません。
  • Adatum 一括メーリング サービス。 このメール ソースを直接制御できないため、サブドメインを使用することをお勧めします。そのため、その目的のために marketing.contoso.com を作成することをお勧めします。 Adatum サービスのドキュメントに従って、ドメインの SPF TXT レコードに include:servers.adatum.com を追加する必要があります。

  contoso.com の SPF TXT レコード:

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

  marketing.contoso.com の SPF TXT レコード:

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

SPF TXT レコードのトラブルシューティング

• ドメインまたはサブドメインごとに 1 つの SPF レコード: 同じドメインまたはサブドメインに対して複数の SPF TXT レコードを使用すると、SPF が失敗する DNS 参照ループが発生するため、ドメインまたはサブドメインごとに 1 つの SPF レコードのみを使用します。

• 10 個未満の DNS 参照: 宛先メール システムが MAIL FROM アドレス ドメインの有効なソースについて SPF TXT レコードにクエリを実行すると、メッセージ ソース (最終的には IP アドレス) が指定されたソースのいずれかに一致するまで、クエリはレコード内の IP アドレスと include: ステートメントをスキャンします。 DNS 参照の数 (DNS クエリの数とは異なる場合があります) が 10 を超える場合、メッセージは永続的なエラー ( permerror とも呼ばれます) で SPF に失敗します。 宛先メール システムは、配信不能レポート (NDR または バウンス メッセージとも呼ばれます) 内のメッセージを拒否し、次のいずれかのエラーが発生します。

  • メッセージのホップ数を超えました。
  • メッセージに必要な参照数が多すぎます。

  SPF TXT レコードでは、個々の IP アドレスまたは IP アドレス範囲によって DNS 参照は発生しません。 各 include: ステートメントには少なくとも 1 つの DNS 参照が必要であり、 include: 値が入れ子になったリソースを指している場合は、さらに多くの参照が必要になる場合があります。 つまり、 include: ステートメントが 10 個未満の場合、10 個未満の DNS 参照は保証されません。

  また、宛先メール システムは、SPF TXT レコード内のソースを左から右に評価します。 メッセージ ソースが検証され、それ以上ソースがチェックされないと、評価は停止します。 したがって、SPF TXT レコードには、10 を超える DNS 参照を引き起こすのに十分な情報が含まれている場合がありますが、一部の宛先による一部のメール ソースの検証では、レコード内でエラーが発生するのに十分な深さがありません。

  メインのメール ドメインの評判を維持するだけでなく、DNS 参照の数を超えないことが、制御しない他のメール サービスにサブドメインを使用するもう 1 つの理由です。

無料のオンライン ツールを使用して、ドメインの SPF TXT レコードやその他の DNS レコードを表示できます。 一部のツールでは、SPF TXT レコードに必要な DNS レコード参照の数も計算されます。

次の手順

「SPF、DKIM、DMARC が連携して電子メール メッセージの送信者を認証する方法」で説明されているように、SPF だけでは Microsoft 365 ドメインのなりすましを防ぐには不十分です。 また、可能な限り最善の保護を実現するために DKIM と DMARC を構成する必要もあります。 手順については、以下を参照してください。

• DKIM を使用して、カスタム ドメインから送信される送信電子メールを検証する
• DMARC を使用してメールを検証する

Microsoft 365 に届 くメールの場合、組織への配信前に転送中のメッセージを変更するサービスを使用する場合は、信頼できる ARC シーラーの構成も必要になる場合があります。 詳細については、「 信頼できる ARC シーラーを構成する」を参照してください。