Share via

Microsoft 365 のメール認証

ヒント

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

microsoft 365 organizationとメールボックスがExchange Online、またはスタンドアロン Exchange Online Protection (EOP) organizationメールボックスを使用せずにExchange Onlineし、送信者からの電子メール メッセージの整合性を保護するドメインは重要です。 受信者は、ドメイン内の送信者からのメッセージが実際にドメイン内の送信者から送信されたと確信する必要があります。

Email認証 (電子メール検証とも呼ばれます) は、偽造された送信者 (スプーフィングとも呼ばれます) からの電子メール メッセージの配信を識別し、防止するための標準のグループです。 なりすまし送信者は、一般的に、ビジネス メール侵害 (BEC)、フィッシング、その他の電子メール攻撃で使用されます。 これらの標準には、次のものが含まれます。

  • Sender Policy Framework (SPF): ドメインのメールを送信する権限を持つソース メール サーバーを指定します。
  • DomainKeys Identified Mail (DKIM): ドメインを使用してメッセージの重要な要素にデジタル署名し、メッセージが転送中に変更されていないことを確認します。
  • ドメイン ベースのメッセージ認証、レポートと準拠 (DMARC): ドメイン内の送信者の SPF または DKIM チェックに失敗するメッセージのアクションを指定し、DMARC 結果を送信する場所 (レポート) を指定します。
  • 認証済み受信チェーン (ARC): 転送中のメッセージを変更する既知のサービスによる元の電子メール認証情報を保持します。 宛先電子メール サーバーは、この情報を使用して、DMARC に失敗するメッセージを認証できます。

これらの標準は相互に 依存する構成要素 であり、スプーフィングやフィッシング攻撃に対して可能な限り最善の電子メール保護を提供するために 連携 することを認識することが重要です。 すべての電子メール認証方法より小さいものは、標準以下の保護になります。

Exchange Online メールボックスのないExchange Onlineまたはスタンドアロン Exchange Online Protection (EOP) 組織のメールボックスを持つ Microsoft 365 組織から送信されたメールの電子メール認証を構成するには、次の記事を参照してください。

Microsoft 365 organizationに送信される受信メールを変更するサービスによるメール認証エラーを防ぐには、「信頼できる ARC シーラーを構成する」を参照してください。

この記事の残りの部分では、次について説明します。

ヒント

セットアップ ガイドMicrosoft Defender for Office 365使用してデプロイを簡略化します。 メール、リンク、コラボレーションの脅威から保護します。 ポリシーの構成、レポートへのアクセス、調査の自動化。 機能には、安全なリンク、安全な添付ファイルなどがあります。 サインイン資格情報が必要です。 Microsoft 365 の高度な展開ガイドは、 setup.cloud.microsoft で認証されていないユーザーが利用できます。 潜在的な Microsoft クライアントからパートナーや IT 管理者まで、すべてのユーザーがガイドにアクセスして自由に使用できます (資格情報は必要ありません)。

インターネット メールに認証が必要な理由

設計上、インターネット上の簡易メール転送プロトコル (SMTP) 電子メールは、メッセージ送信者が誰であるかを検証する努力をしません。

標準の SMTP 電子メール メッセージは、 メッセージ エンベロープとメッセージ コンテンツで構成されます。

  • メッセージ エンベロープには、SMTP サーバー間でメッセージを送受信するための情報が含まれています。 メッセージ エンベロープは RFC 5321 で説明されています。 受信者は、メッセージ転送プロセス中に生成されるため、メッセージ エンベロープは表示されません。
  • メッセージのコンテンツには、総称して "メッセージ ヘッダー" と呼ばれるメッセージ ヘッダー フィールドと、メッセージ本文があります。 メッセージ ヘッダーは RFC 5322 で説明されています。

この設計のため、メッセージには複数の送信者値があります。

  • MAIL FROM アドレス (アドレス、P1 送信者、エンベロープ送信者とも呼ばれます 5321.MailFrom ) は、SMTP 電子メール サーバー間のメッセージの送信に使用される電子メール アドレスです。 このアドレスは通常、メッセージ ヘッダーの Return-Path ヘッダー フィールドに記録されます (ただし、ソース メール サーバーは別 の Return-Path メール アドレスを指定できます)。 このメール アドレスは、配信不能レポート (NDR またはバウンス メッセージとも呼ばれます) で使用されます。
  • 差出人アドレス (アドレスまたは P2 送信者とも呼ばれます 5322.From ) は、[ 差 出人ヘッダー] フィールドのメール アドレスであり、電子メール クライアントに表示される送信者のメール アドレスです。

次の例は、2 つの SMTP 電子メール サーバー間の有効なメッセージ送信の簡略化されたトランスクリプトを示しています。

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

この例では次のようになっています。

  • ソース電子メール サーバーは、HELO コマンドで tailspintoys.com 宛先メール サーバーに woodgrovebank.com として自身を識別します。
  • メッセージ受信者は です astobes@tailspintoys.com。
  • メッセージ エンベロープ内の MAIL FROM アドレス (SMTP 電子メール サーバー間でメッセージを送信するために使用) は です dubious@proseware.com。
  • 受信者の電子メール クライアントに表示される差出人アドレスは です security@woodgrovebank.com。

このメッセージは SMTP に従って有効ですが、MAIL FROM アドレス (proseware.com) のドメインが From アドレス (woodgrovebank.com) のドメインと一致しません。 このメッセージは、フィッシング攻撃で使用するメッセージの真のソースをマスクすることで、意図が受信者を欺く可能性がある、スプーフィングの従来の例です。

明らかに、SMTP 電子メールは、メッセージの送信者が誰であるかを確認するのに役立つ必要があります。

SPF、DKIM、DMARC が連携して電子メール メッセージの送信者を認証する方法

このセクションでは、インターネット上のドメインに SPF、DKIM、DMARC が必要な理由について説明します。

  • SPF: 「SPF を設定して Microsoft 365 ドメインの有効なメール ソースを識別する」で説明されているように、SPF は DNS の TXT レコードを使用して MAIL FROM ドメインからの有効なメール ソースを識別し、宛先メール サーバーが未定義の送信元からメールを受信した場合の処理 (メッセージを拒否するには"ハードフェイル" します。メッセージを受け入れてマークする 'soft fail' )。

    SPF の問題:

    • SPF は、MAIL FROM ドメイン内の送信者のソースのみを検証します。 SPF では、差出人アドレス内のドメインや、MAIL FROM ドメインと From ドメイン間のアラインメントは考慮されません。

      • 攻撃者は、次の手順に従って SPF 認証 (偽陰性) を渡す電子メールを送信できます。
        • ドメイン (たとえば、proseware.com) を登録し、ドメインの SPF を構成します。
        • 登録済みドメインの有効なソースから電子メールを送信します。別のドメインの送信元メール アドレス (たとえば、woodgrovebank.com)。
      • 他のドメインに代わってメールを送信する正当な電子メール サービスは、MAIL FROM アドレスを制御する可能性があります。 他のドメインと MAIL FROM ドメインが一致しないため、メッセージは SPF 認証 (誤検知) に合格できません。

    • メッセージがメッセージをリダイレクトまたはリレーするサーバーベースのメール転送に遭遇した後、SPF は中断 します 。

      • サーバー ベースのメール転送により、メッセージ ソースが元のサーバーから転送サーバーに変更されます。
      • 転送サーバーは、元の MAIL FROM ドメインからメールを送信する権限がないため、メッセージは SPF 認証 (誤検知) に合格できません。

    • 各ドメインとサブドメインには、独自の SPF レコードが必要です。 サブドメインは、親ドメインの SPF レコードを継承しません。 定義および使用されたサブドメインからの電子メールを許可するが、未定義および未使用のサブドメインからの電子メールを防ぐ場合、この動作は問題になります。

  • DKIM: 「Microsoft 365 ドメインからのメールに署名するように DKIM を設定する」で説明されているように、DKIM はドメインを使用してメッセージの重要な要素 (From アドレスを含む) にデジタル署名し、署名をメッセージ ヘッダーに格納します。 宛先サーバーは、メッセージの署名された要素が変更されていないことを確認します。

    DKIM が SPF を支援する方法: DKIM は SPF に失敗したメッセージを検証できます。 例:

    • 同じ MAIL FROM アドレスが他のドメインからのメールに使用されるメール ホスティング サービスからのメッセージ。
    • サーバー ベースの電子メール転送が発生したメッセージ。

    メッセージ ヘッダーの DKIM 署名は、これらのシナリオでは影響を受けたり変更されたりしないため、これらのメッセージは DKIM を渡すことができます。

    DKIM の問題: DKIM がメッセージの署名に使用するドメインは、メール クライアントに表示される From アドレスのドメインと一致する必要はありません。

    SPF と同様に、攻撃者は次の手順に従って DKIM 認証 (偽陰性) を渡す電子メールを送信できます。

    • ドメイン (たとえば、proseware.com) を登録し、ドメインの DKIM を構成します。
    • 別のドメイン (たとえば、woodgrovebank.com) の From メール アドレスを使用して電子メールを送信します。

  • DMARC: 「Microsoft 365 の送信者の差出人アドレス ドメインを検証するように DMARC を設定する」で説明されているように、DMARC は SPF と DKIM を使用して、MAIL FROM アドレスと From アドレス内のドメイン間のアライメントにチェックします。 DMARC では、DMARC に失敗したメッセージに対して宛先メール システムが実行するアクションも指定し、DMARC の結果を送信する場所 (合格と失敗の両方) を識別します。

    DMARC が SPF と DKIM にどのように役立つか: 前述したように、SPF は MAIL FROM ドメインと From アドレスのドメインとの照合を試行しません。 DKIM は、メッセージに署名したドメインが From アドレス内のドメインと一致するかどうかは気にしません。

    DMARC は、SPF と DKIM を使用して、MAIL FROM アドレスと From アドレスのドメインが一致することを確認することで、これらの欠陥に対処します。

    DMARC の問題: 配信中断 SPF、DKIM、および DMARC チェックの前に転送中のメッセージを変更する正当なサービス。

  • ARC: 信頼できる ARC シーラーの構成で説明されているように、転送中のメッセージを変更する正当なサービスでは、ARC を使用して、変更されたメッセージの元の電子メール認証情報を保持できます。

    ARC が DMARC を支援する方法: 宛先メール システムは、信頼できる ARC シーラーとしてサービスを識別できます。 その後、ARC は保存された電子メール認証情報を使用してメッセージを検証できます。

Microsoft 365 に送信されるメールの受信メール認証

フィッシングの問題と、インターネット上の電子メール送信者による強力な電子メール認証ポリシーの完全な導入未満のため、Microsoft 365 は暗黙的な電子メール認証を使用して受信メールをチェックします。 暗黙的な電子メール認証は、他のソースからの信号を使用して受信メールを評価することで、通常の SPF、DKIM、DMARC チェックを拡張します。 これらのソースには、次のものが含まれます。

  • 送信者の評判。
  • 送信者の履歴。
  • 受信者の履歴。
  • 行動分析。
  • その他の高度な手法。

暗黙的な認証に関する Microsoft の元の発表については、「 フィッシングの海パート 2 - Microsoft 365 での強化されたなりすまし対策」を参照してください。

これらの他のシグナルを使用すると、従来の電子メール認証チェックに失敗するメッセージは暗黙的な認証に合格し、Microsoft 365 に許可されます。

複合認証

Microsoft 365 の暗黙的な認証チェックの結果が組み合わされ、 複合認証 という名前の単一の値または compauth 略して格納されます。 この compauth の値は、メッセージ ヘッダーのAuthentication-Results にスタンプされます。 Authentication-Results ヘッダーでは、次の構文が使用されます。

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

これらの値については、「Authentication-results メッセージ ヘッダー」で説明しています。

管理者とユーザーは、メッセージ ヘッダーを調べて、Microsoft 365 が送信者を疑わしいなりすまし送信者または正当な送信者として識別した方法を確認できます。

ヒント

複合認証の失敗によってメッセージがブロックされるわけではないことを理解しておくことが重要です。 メッセージの全体的な疑わしい性質と複合認証結果を考慮した包括的な評価戦略を使用したシステム。 この方法は、電子メール認証プロトコルに厳密に準拠していない可能性があるドメインからの正当な電子メールを誤ってブロックするリスクを軽減するように設計されています。 このバランスの取れたアプローチは、純粋に悪意のあるメールを、標準の電子メール認証のプラクティスに準拠できないメッセージ送信者と区別するのに役立ちます。

次の例では、電子メール認証の結果 (値と理由) のみに焦点を compauth 当てています。 その他の Microsoft 365 保護テクノロジでは、電子メール認証に合格したメッセージをなりすましとして識別したり、電子メール認証に失敗したメッセージを正当なメッセージとして識別したりできます。

  • シナリオ: SPF レコードまたは DKIM 署名のドメインが、From アドレスのドメインと一致しません。

  • 結果: メッセージは複合認証に失敗する可能性があります。 複合認証エラーにもかかわらず、他の評価が疑わしい性質を示していない場合、メッセージは引き続き許可される可能性があります。

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • シナリオ: fabrikam.com ドメインに SPF、DKIM、または DMARC レコードがありません。

  • 結果: fabrikam.com ドメイン内の送信者からのメッセージは、複合認証に失敗する可能性があります。

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • シナリオ: fabrikam.com ドメインに SPF レコードがあり、DKIM レコードがありません。 MAIL FROM アドレスと From アドレスのドメインが一致します。

  • 結果: SPF を渡したドメインが From アドレスのドメインと一致するため、メッセージは複合認証を渡すことができます。

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • シナリオ: fabrikam.com ドメインに SPF レコードのない DKIM レコードがあります。 DKIM がメッセージに署名したドメインは、From アドレスのドメインと一致します。

  • 結果: DKIM 署名のドメインが From アドレスのドメインと一致するため、メッセージは複合認証を渡すことができます。

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • シナリオ: SPF レコードまたは DKIM 署名のドメインが、From アドレスのドメインと一致しません。

  • 結果: メッセージは複合認証に失敗する可能性があります。

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Microsoft 365 にメールを送信するときに電子メール認証エラーを回避する方法

ヒント

Microsoft 365 のお客様は、次の方法を使用して、なりすましまたは認証エラーとして識別される送信者からのメッセージを許可できます。

  • ドメインの SPF、DKIM、DMARC レコードを構成する: ドメイン レジストラーまたは DNS ホスティング サービスによって提供される構成情報を使用します。 また、電子メール認証レコードの設定を支援する専用のサード パーティ企業もあります。

    多くの企業は、ドメイン内のメッセージのすべての電子メール ソースを把握していないため、SPF レコードを発行しません。

    1. まず、知っているすべてのメール ソース (特に会社のトラフィックが配置されている場所) を含む SPF レコードを発行し、適用規則の値 "論理的な失敗" (~all) を使用します。 例:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      この SPF レコードを作成すると、Microsoft 365 は企業インフラストラクチャからの受信メールを認証済みとして扱いますが、複合認証に失敗した場合でも、未確認のソースからのメールはスプーフィングとしてマークされる可能性があります。 ただし、この動作は引き続き、Microsoft 365 によってなりすましとしてマークされているドメイン内の送信者からのすべての電子メールから改善されています。 通常、宛先メール システムは、SPF が論理的な失敗の適用規則で構成されている場合、未確認のソースからのドメイン内の送信者からのメッセージを受け入れます。

    2. メッセージの電子メール ソースをさらに検出して含めます。 例:

      • オンプレミスのメールサーバー。
      • SaaS (サービスとしてのソフトウェア) プロバイダーから送信されたメール。
      • クラウドホスティング サービス (Microsoft Azure、GoDaddy、Rackspace、Amazon Web Services など) から送信されたメール。

      ドメインのすべてのメール ソースを特定したら、適用規則の値 "ハード フェイル" (-all) を使用するように SPF レコードを更新できます。

    3. メッセージにデジタル署名するように DKIM を設定します。

    4. DMARC を設定して、MAIL FROM アドレスと From アドレスのドメインが一致することを検証し、DMARC チェックに失敗したメッセージの処理 (拒否または検疫) を指定し、DMARC の結果を監視するレポート サービスを特定します。

    5. 一括送信者を使用して代理で電子メールを送信する場合は、差出人アドレスのドメインが SPF または DMARC を渡すドメインと一致することを確認します。

  • ドメインのメールをホストするか、メールを送信できるホスティング インフラストラクチャを提供します。

    • 顧客に、ドメインの SPF を構成する方法を説明するドキュメントがあることを確認します。
    • 顧客がドメインに DKIM を明示的に設定していない場合でも、DKIM の送信メールに DKIM 署名することを検討してください (既定のドメインで署名します)。 DKIM 署名 (使用可能な場合は会社のドメインと顧客のドメイン) でメールをダブル署名することもできます。

    プラットフォームから送信されたメールを認証した場合でも、Microsoft への配信は保証されません。 ただし、電子メール認証を使用すると、認証されていないという理由だけで、顧客ドメインから Microsoft が自動的に迷惑メールを送信しないようにします。