Microsoft 365 での電子メール認証のセキュリティ操作ガイド

Email認証は、organizationの通信をセキュリティで保護するための重要なコンポーネントです。 Microsoft 365 で電子メールを受信すると、サービスによって Authentication-Results ヘッダーが追加されます。 このヘッダーは、SPF、DKIM、DMARC、複合認証 (compauth) など、さまざまな電子メール認証チェックの結果を示します。

このガイドでは、次の結果で発生する可能性がある一般的なシナリオについて説明します。

• メッセージが電子メール認証に合格または失敗した理由。
• 電子メールの送信元または電子メールの送信先が結果を担当するかどうか。
• 電子メール認証の結果を向上させるために推奨されるアクション (ある場合)。

ただし、最初に、次の表に示すようにいくつかの定義を示します。

Email認証パス のシナリオ

これらのシナリオでは、 電子メール認証チェックに合格した メッセージ、または受け入れられたメッセージについて説明します (特定の構成が原因である場合があります)。 一般に、電子メール認証に合格した場合、是正措置は必要ありません。 ただし、一部のシナリオには、セキュリティを強化するために構成の改善を推奨する 注意書き が含まれています。

送信者は、ソース organizationの管理者を参照します。 受信者は、宛先organizationの管理者を参照します。

すべての認証チェックに合格しました

• ヘッダーの例: dmarc=pass (通常は spf=pass と dkim=pass)。
• 意味: すべての電子メール認証チェック (SPF、DKIM、DMARC) が成功しました。 この結果は、標準の電子メール認証プロトコルに従ってメッセージが完全に認証されていることを示します。
• 責任者: 送信者。
• 推奨されるアクション: なし。Email認証が正しく構成され、意図したとおりに動作します。 受信者は、このメッセージを適切に認証した送信者ドメインを信頼できます。

複合認証が渡されました

• ヘッダーの例: compauth=pass (複合認証パス)。

• 意味: メッセージは Microsoft 365 複合認証に合格しました。

  • DMARC 要件が満たされました。SPF または DKIM が渡され 、 MAIL FROM アドレスと From アドレスがアラインされています。

    または

  • Microsoft の暗黙的な信頼ロジックでは、メッセージが正当なものとして識別されました。 たとえば、Microsoft の安全な送信者履歴に基づく複合認証や、送信者が信頼されていることを示す スプーフィング インテリジェンス に基づいて、メッセージが複合認証に合格する場合があります。

• 責任者: 送信者。

• 推奨されるアクション: なし。 認証チェックは成功し、システムは問題を検出しませんでした。 このシナリオでは、SPF または DKIM に変更は必要ありません。

DMARC ポリシーを使用しない DMARC パス (DMARC レコードなし)

• ヘッダーの例: dmarc=bestguesspass action=none
• 意味: 送信者のドメインに公開された DMARC レコードがないため、 既定でDMARC に渡されたメッセージ。 ドメインに DMARC ポリシーがない場合、宛先メール サーバーは DMARC 上のメッセージを失敗できません。 実質的に、DMARC チェックは適用されません。 DMARC=bestguesspass action=noneは、ドメインに有効な DMARC レコードがある場合、メッセージの DMARC チェックが渡されることを意味します。
• 責任者: 送信者。
• 推奨されるアクション: 送信者は、ドメインの DMARC レコードを発行する必要があります 。 メッセージは受け入れられましたが、DMARC ポリシーがないのは良い兆候ではありません。 ドメイン所有者は、DMARC 検証に失敗したメッセージに対して DMARC ポリシー (p=quarantine または p=reject) を適用するように DMARC TXT レコードを設定することをお勧めします。 詳細については、「 DMARC TXT レコードの構文」を参照してください。

ARC 検証済み (複雑なルーティング シナリオ)

• ヘッダーの例: compauth=pass reason=130 (ARC が原因で渡された複合認証)。
• 意味: 認証された受信チェーン (ARC) オーバーライドが原因で認証が渡されたメッセージ。 この結果は、通常、複雑なメール ルーティングまたは電子メール転送シナリオで発生します。 中間メール サーバーがメッセージを変更し、SPF または DKIM が失敗した場合、信頼された ARC 署名は元の認証が有効であることを Microsoft 365 に通知します。 この場合、SPF または DKIM の直接チェックが失敗する可能性がある場合でも、システムは有効な ARC チェーンに基づいてメッセージを受け入れます。
• 責任者: 送信者 (元の送信者または中継局)。 構成に誤りはありません。 ARC を使用する中継局がメッセージを処理しました。
• 推奨されるアクション: このシナリオが予想される場合は 直接アクションは必要ありません (たとえば、メッセージは ARC を実装する既知のサービスによって処理されました)。 Microsoft 以外の仲介サービスを運用する場合は、ARC ヘッダーを追加し、受信サーバー (Microsoft 365 など) が ARC 署名を信頼することを確認します。 この構成により、受信メッセージは ARC 経由で compauth を渡すことができます。

テナント許可/ブロック リストのなりすまし送信者の許可エントリが原因で配信されるメッセージ

• 意味: メッセージは、 なりすまし送信者の許可エントリがテナント許可/ブロック リストに存在するため、通常の認証エラーアクションをバイパスしました。 Microsoft 365 では、なりすまし送信者の許可エントリがエラーをオーバーライドする可能性があります。 電子メール認証チェックが通常失敗した場合でも、この明示的な信頼構成によりメッセージが許可されます。

• ヘッダーの例: compauth=fail reason=000 (ただし、organization ポリシーでは、テナント許可/ブロック リストのスプーフィング許可) というメッセージが許可されました。

• 責任者: 受信者。 受信者のorganizationの管理者は、この特定のドメイン ペアの [テナントの許可/ブロック] リストにスプーフィングの許可エントリを構成しました。 送信者は、他の受信者との配信可能性の問題を回避するために、認証の問題を解決する必要があります。

• 推奨されるアクション: 受信者管理者は、Email エンティティ ページの [すべてのオーバーライド] セクションをチェックして、テナントの許可/ブロック リストのオーバーライドが関係しているかどうかを確認できます。 これらのメッセージには、organization ポリシーで許可: テナント許可/ブロック リストのスプーフィングが許可されています。

  一般に、これらのメッセージは意図的に許可されているため、 直ちにアクションを実行することはできません 。 ただし、管理者は、必要な送信者のみが許可されるように、 なりすまし送信者の許可エントリを定期的に確認 することをお勧めします。 テナント許可/ブロック リストを使い過ぎれば、通常は認証チェックに失敗する (悪意のある可能性がある) メッセージを配信できます。

PTR (逆引き DNS) アライメントを使用して認証される

• ヘッダーの例: PTR レコードの使用を示すreason=116やreason=111などのコードを含むcompauth=pass。
• 意味: メッセージは、フォールバックとして PTR (逆引き DNS) 検証に基づいて 認証を渡しました。 SPF チェックと DKIM チェックで決定的なパスが生成されない場合、Microsoft 365 は送信者の PTR レコードを確認できます。 送信側サーバーの IP アドレスに、メッセージの From アドレス内のドメインと一致する PTR レコード (逆引き DNS) がある場合、システムはメッセージを認証済みとして扱う可能性があります。
• 責任者: 送信者。 送信者の電子メール サーバーは、DNS の PTR レコードを介して検証されました。 この結果は通常、SPF と DKIM が正しく構成されておらず、システムが PTR 参照に頼っていたことを意味します。
• 推奨されるアクション: 送信者は、 SPF と DKIM がドメインに対して適切に構成されていることを確認 する必要があります。 送信ドメインを送信 IP アドレスにマップする正しい逆引き DNS (PTR) レコードは適切ですが、DMARC アラインメントに代わるレコードではありません。 送信者は、SPF と DKIM の構成を改善するために、PTR パスをインジケーターとして扱う必要があります。 この結果に気付いたときに送信者に通知する以外に、受信者に対するアクションはありません。

Email認証エラーのシナリオ

これらのシナリオでは、 失敗した認証チェック や、メッセージが認証されていないとマークされているその他の条件について説明します。 認証チェックに失敗しても、メッセージが拒否されたとは限りません。 一部のエラーでは、メッセージが検疫されるか、警告と共に配信されます。 次のシナリオでは、エラーが発生した理由、それに対処する必要があるユーザー、および基になる問題を解決する方法について説明します。

送信者は、ソース organizationの管理者を参照します。 受信者は、宛先organizationの管理者を参照します。

DMARC に失敗しました (メッセージの拒否または検疫)

• ヘッダーの例: dmarc=fail action=quarantine (またはaction=reject)。多くの場合、コード (reason=000、reason=001、reason=601など) を含むcompauth=failが伴います。

• 意味: DMARC 検証がメッセージに対して失敗しました 。 この結果は、次のことを意味します。

  • SPF または DKIM が From アドレス ドメインのアラインメントで渡されませんでした。

    And

  • From アドレス ドメインの DMARC レコードには、 p=quarantine または p=reject ポリシーが含まれています。

  その結果、Microsoft 365 は、指定したポリシー アクションのメッセージをマークしました。[迷惑メール] Email フォルダーへの配信、検疫、または拒否。

• 責任者: 送信者 または 受信者。 このエラーは、送信者のドメインが DMARC を渡さないか、DMARC が失敗する原因となった受信者の 複雑なメール ルーティング構成 が原因です。

  送信者はドメインに対して SPF、DKIM、DMARC を正しく構成する責任を負う一方で、認証エラーが受信者のorganizationの問題によって発生する場合があります。 例:

  • 受信者のorganizationは、コネクタの拡張フィルター処理を構成せずに、インターネット Microsoft 365 間で Microsoft 以外のフィルタリング サービスを使用します。 Microsoft 365 がメッセージを受信すると、SPF 検証が失敗する可能性があります。
  • Microsoft 以外のフィルター サービスが配信前にメッセージを変更すると、送信者の DKIM レコードが正しく構成されていても、DKIM が失敗する可能性があります。

  そのため、最初の受信時点での判定 (MX レコード) と、メッセージが受信者のメールボックスに到達したときの判定を区別することが重要です。

• 推奨されるアクション:

  • 送信者は、メール認証の構成を修正する必要があります。 具体的には、送信者は次の手順を実行する必要があります。

    • SPF レコードに、ドメインからの電子メールのすべての正当なソース IP アドレスが含まれていることを確認します。
    • ドメインの DKIM を設定し、署名が送信メールに正しく適用されていることを確認します。
    • SPF または DKIM (またはその両方) が渡され、DMARC で必要に応じて From アドレス ドメインにも 対応 していることを確認します。
    • DMARC レコード構文と DMARC ポリシーを確認します。 たとえば、p=quarantine および p=reject が禁止となります。

  • 受信者は、複雑なメール ルーティング構成を修正する必要があります。 具体的には、受信者は次の手順を実行する必要があります。

    • コネクタの拡張フィルター処理を構成する
    • 使用可能な場合は、転送中のメッセージの変更によって発生したエラーをオーバーライドするように 、信頼された ARC シーラー を構成します。
    • Microsoft 以外のサービスではなく、Microsoft 365 を使用してメッセージの変更 (フッター、免責事項、件名など) を適用することを検討してください。

SPF チェック失敗しました

• ヘッダーの例: spf=fail または spf=softfail。 一時的な DNS の問題を示す spf=temperror 、または SPF 構成の問題を示す spf=permerror を監視します。

• 意味: 次のいずれかの可能性があります。

  • 送信側サーバーの IP アドレスはドメインの SPF レコードによって 承認されていないため 、SPF から返された IP アドレスは 失敗します。
  • SPF チェックが正しく完了できませんでした。 たとえば、DNS 参照の問題 (spf=temperror) やリダイレクト (spf=permerror) が多すぎます。

  DMARC パスなしで SPF が失敗すると、DMARC が失敗します。

• 責任者: 送信者。 問題は、送信者ドメインの SPF レコード構成または送信側サーバーのセットアップにあります。

• 推奨されるアクション: 送信者は 、ドメインの SPF レコードを更新して修正する必要があります。

  • ドメイン のすべての正当なソース IP アドレス が SPF レコードに含まれていることを確認します。
  • ドメインのアライメントミスが原因で DMARC が失敗した場合 (MAIL FROM アドレス ドメインが From アドレス ドメインと異なる)、次の手順のいずれかまたは両方を実行して修正できます。
    • MAIL FROM アドレスと From アドレスで使用されるドメインを揃えます。
    • From アドレス ドメインと一致するドメインを使用して、送信メッセージの DKIM 署名を設定します。 DMARC では、両方ではなく SPF または DKIM の検証が必要です。
  • spf=temperror 一般に、受信者が SPF レコードの解決に問題があることを示します (一時的な DNS の問題など)。 送信者は、ドメインの DNS サーバーが正常で到達可能であることを確認する必要があります。 Time-to-Live (TTL) の値が低すぎてタイムアウトが頻繁に発生する場合は、TTL を 少なくとも 1 時間に増やすことを検討してください。
  • spf=permerror 通常、SPF レコード自体に問題があることを示します。これには 、10 を超える DNS 参照が必要です。 不要な include: ステートメントを削除し、構文エラーを修正することで、SPF レコードを簡略化します。

SPF の問題を解決すると、メッセージが DMARC 認証に合格する可能性が高くなります。 受信者は、SPF エラーと、問題を解決するための推奨アクションについて送信者に通知する必要があります。

DKIM チェックに失敗しました (署名のキーなし)

• ヘッダーの例: 公開キーが見つからない場合に dkim=fail (署名用のキーなし)。

• 意味: 次のいずれかの可能性があります。

  • DKIM 署名はありましたが、受信者が DNS で一致する 公開キー を見つけることができませんでした (キーなし)。

    または

  • キーが署名と一致しませんでした (署名を確認できませんでした)。

• 責任者: 送信者。 送信者のドメインの DKIM セットアップが壊れています。

  • 公開キーが DNS の DKIM CNAME レコードまたは TXT レコードに存在しません。

    または

  • 送信者側または受信側に DNS の問題があります。

• 推奨されるアクション: 送信者は、次の手順を実行して 、ドメインの DKIM 設定を修正 する必要があります。

  • DNS で DKIM 公開キーを発行 します。 DKIM CNAME レコードまたは TXT レコードに、メッセージの署名に使用される秘密キーと一致する有効なセレクター ( selector._domainkey.contoso.com など) が含まれていることを確認します。
  • キーが発行された場合、Microsoft 365 がレコードのクエリを実行しようとしたときにタイムアウトが発生した可能性があります。 Time-to-Live (TTL) の値が 少なくとも 1 時間に設定されていることを確認します。

DKIM が適切に構成され、アラインされると、受信者はメッセージの dkim=pass を確認し、メッセージが DMARC を通過するのにも役立ちます。

変更後に DKIM が失敗しました (署名が確認されませんでした)

• ヘッダーの例: dkim=fail (署名が検証されませんでした)。
• 意味: メッセージには 有効な DKIM 署名が含まれていましたが、DKIM 署名に含まれるヘッダーが 署名後に転送中に変更されたため、メッセージは DKIM 検証に失敗しました。 この変更は通常、仲介者 (メーリング リスト、転送サービス、セキュリティ アプライアンスなど) が、DKIM 署名が最初に適用された後に署名済みヘッダー (Subject:、From:、To:など) を変更するときに発生します。 DKIM-Signature のh=値は、元のハッシュに含まれるヘッダーを識別します。 これらのヘッダーのいずれかを変更すると、DKIM エラーが発生します。
• 責任者: メッセージ ヘッダーを変更した 送信者 または 中継局 。 元の送信者の DKIM がメッセージに正しく署名しましたが、中断された DKIM 署名は中継局によって担当される可能性があります。
• 推奨されるアクション: DKIM がメッセージに署名した後、ヘッダーに変更を加えないでください。
  • 送信者: メッセージが DKIM 署名された時点から環境を離れるまで、署名されたヘッダーが変更されていないことを確認します。
  • 仲介: 顧客がサービスを 信頼できる ARC シーラー として構成し、転送中のメッセージの変更によって発生する DKIM エラーをオーバーライドできるようにします。

変更後に DKIM が失敗しました (本文ハッシュに失敗しました)

• ヘッダーの例: dkim=fail (本文ハッシュに失敗)。
• 意味: メッセージには 有効な DKIM 署名が含まれていましたが、メッセージ本文が 署名後に転送中に変更されたため、メッセージは DKIM 検証に失敗しました。 通常、この変更は、仲介者 (メーリング リスト、転送サービス、セキュリティ アプライアンスなど) が、DKIM 署名が最初に適用された後にメッセージ本文の内容を変更するときに発生します。 結果は、受信メール システムによって計算されたハッシュが DKIM 署名のハッシュと一致しないため、DKIM チェック失敗します。
• 責任者: メッセージを変更した 送信者 または 中継局 。 元の送信者の DKIM がメッセージに正しく署名しましたが、中断された DKIM 署名は中継局によって担当される可能性があります。
• 推奨されるアクション: 署名後に電子メール コンテンツに意図しない変更が加えないことを確認します。
  • 送信者: 次の手順を実行します。
    • メッセージが DKIM 署名された時点から環境を離れるまで、署名されたヘッダーが変更されていないことを確認します。
    • Microsoft 以外のサービスではなく、Microsoft 365 を使用してメッセージの変更 (フッター、免責事項、件名など) を適用することを検討してください。
  • 仲介: 顧客がサービスを 信頼できる ARC シーラー として構成し、転送中のメッセージの変更によって発生する DKIM エラーをオーバーライドできるようにします。

クイック リファレンス テーブル

このセクションには、シナリオ、推奨される解決策、および詳細な読み取りのために関連する記事へのリンクをまとめた簡略化された表が含まれています。

送信者 は、送信側ドメインの管理者を参照します。 受信者は、受信organizationの管理者を指します。

ベスト プラクティスとヒント

• SPF、DKIM、DMARC を実装する: これらのテクノロジは相互に補完し、多層防御を提供します。 何よりも保護のギャップを残します。

• DNS レコードの管理: すべてのメール ソースで SPF レコードを最新の状態に保ちます。 必要に応じて DKIM キーをローテーションして管理し、DMARC レポートを監視して認証エラーを特定します。

• 認証結果の監視: 認証結果ヘッダーを定期的にチェックするか、ツール/レポート (Microsoft 365 スプーフィング インテリジェンス分析情報など) を使用して、受信メッセージの動作を確認します。 このアクティビティは、SPF/DKIM を設定していないパートナー、または独自のメッセージが認証に失敗している場合に表示される可能性があります。

• リレー シナリオに ARC を使用する: organizationがメール転送を行う場合、またはメッセージを変更する Microsoft 以外のサービスを使用する場合は、Microsoft 365 で信頼できる ARC シーラーを構成することを検討してください。 ARC は、認証を保持し、メッセージが中継局を通過するときの誤ったエラーを回避するのに役立ちます。

• 許可リストには注意してください:許可エントリをorganizationするのではなく、可能な限り標準の認証結果に依存してください。 許可エントリは例外であり、不要なエントリを削除するには定期的にチェックする必要があります。

• 最新情報を入手する: 次のリソースに従います。

  • Microsoft Defender for Office 365 のブログ
  • Exchange チーム ブログ
  • Microsoft Defender for Office 365 の新機能
  • Microsoft 365 メッセージ センター。