[ 到達性と送信者のルール ]

Outlook .com の大量送信者の要件: 消費者メールと企業メールを区別する

企業メールの想定を適用するのではなく、コンシューマ サービスの範囲でOutlook .com の大量認証エラーを診断します。

EmailAuth研究チームによる · 3 分で読めます

【ポイント】

  • Outlookアプリだけでなく、Microsoft コンシューマー メールボックス サービスを特定します。
  • DMARCパスは、失敗した別のSPF要件と共存できます。
  • 認証を変更する前に、実際の拒否とルートを保存します。
このページでは

「 Outlook 」とは、デスクトップ アプリケーション、消費者メールボックス、または組織のMicrosoft 365環境を意味します。これらは交換可能なポリシー スコープではありません。大量のチェックリストを使用して失敗したメッセージを説明する前に、実際の受信サービスと診断から始めてください。

消費者サービスとその現在の要件を特定する

Microsoft の 550 5.7.515 の現在のサポート記事では、 Outlook .com と、Hotmail、Live.com、MSN などの関連コンシューマ サービスについて説明しています。大量の送信者が、可視の同じドメインを使用してこれらのサービスに 5,000 以上のメッセージを送信していることを識別します。 5322.から 住所。そのサポート文言には、両方とも記載されています SPF そして DKIM 合格する必要があり、公開されたものであること DMARC 少なくとも p=none およびDMARCパスが必要です。 Microsoft 550 5.7.515 ガイダンス.

更新された発表では、拒否の実施が 2025 年 5 月 5 日に開始されることが設定されました。当初のジャンクのみの計画は無効になりました。置き換えられた段落を現在の対応方針として扱わないでください。 Microsoft の最新の発表.

以前の発表では、1 日あたりの取引量について「5,000 件以上」と表現されていました。境界文言の周囲に例外を設けないでください。現在のサポート ガイダンスでは 5,000 以上が使用されています。また、このサポート ページからリセット期間や永続的な分類ルールを考案するべきではありません。ケースを解釈するときに、バージョンと実際の受信診断を記録します。

プロトコルの成功をプロバイダー ゲートから分離する

参考文献: RFC 9989 §4.4, RFC 9989 §5.3.5.

DMARC 、整列されて成功したものを通過できます。 DKIM署名 SPFが失敗した場合でも。そのプロトコルの結果は、両方の基礎となるメカニズムが通過するという個別の要件を満たしていません。逆に、 SPFとDKIMどちらも、表示されている From に関係のないドメインに合格し、 DMARC失敗する可能性があります。 3 つの結果すべてとその背後にあるアイデンティティを保持します。

直接サービスによって生成されたメッセージの場合は、送信元 IP を記録します。 封筒の差出人 ドメイン、From ドメイン、 DKIM d= ドメイン、および セレクタ。セットアップ画面だけでなく、現在のDNSと最終的な署名付きメッセージを確認します。実際のプロトコル名を使用します。SMTP MAIL FROM はSMTP RFC 5321エンベロープ ID ですが、表示される From はRFC 5322に属します。

修復スクリプトではなく、証拠として拒否を読む

参考文献: RFC 8601 §5.

550 5.7.515 拒否は、送信者のドメインが必要な認証レベルを満たしていないことを示します。診断全体、時刻、影響を受ける受信者、およびメッセージ ID を保存します。利用可能なすべてのプロバイダー インクルードをSPFに追加したり、無効にしたりして応答しないでください。 DMARC施行 失敗したアイデンティティを理解せずに。

影響を受けたストリームと影響を受けなかったストリームを比較します。請求サービスには正しいカスタム署名設定がある場合がありますが、キャンペーン サービスは引き続き独自のドメインでのみ署名する場合があります。転送または別の仲介が関与する場合は、ルートと変換を保存します。ダイレクトメールの仮定では、間接的なパスやコピーされたメールが説明できない可能性があります。 Authentication-Results line は、信頼された受信者の証拠の代わりにはなりません。

総合的な診断を行う

参考文献: RFC 9989 §5.3.5.

SPF結果が失敗、 DKIM結果が合格である制御メッセージを想像してください。 アライメント、 DMARCの結果は合格です。 DMARC結果は内部的に一貫しています。 Microsoft が明示した大容量要件では、 SPF障害は依然として修復が必要です。これは論理的な例であり、Microsoft の拒否を捉えたものではありません。

次のアクションは、評価されたエンベロープ送信者が実際の接続 IP を許可したかどうかを判断することです。修正が承認された後、同じ意図したルートで再テストし、新しい結果を保存します。変更されたメッセージまたはルートの証拠として古いパスを再利用しないでください。

企業の訴訟を独自の証拠経路に沿って維持する

Microsoft 365テナントは、独自の受信ポリシーとコネクタを適用できます。 Outlookアプリケーションを使用している受信者は、自分の組織を消費者向け記事の正確なゲートの対象にすることはありません。エンタープライズの場合は、5.7.515 がすべての 5.7.x 応答を説明すると仮定するのではなく、テナントの診断コンテキストとポリシー コンテキストを収集します。

影響を受けるサービス、送信者ドメイン、観察されたメカニズムの結果、修正されたルートを報告します。ここでは Microsoft メールボックスのライブ テストは要求されておらず、認証準拠は受信トレイの配置とは区別されたままです。

[ 取り除く ]

認証を変更する前に、実際の拒否とルートを保存します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

各認証結果を保持

DMARCだけでも、別のメカニズムの障害を隠すことができます。

次のステップ

  1. 完全な診断をキャプチャします。
  2. エンベロープと From ID をマップします。
  3. 修正したルートを再テストします。

CISO / SecOps

推測による政策の弱体化を避ける

拒否は調査の理由であり、認可を拡大するものではありません。

次のステップ

  1. SPF変更を注意深く確認します。
  2. 中間証拠を保存します。
  3. テナントポリシーを消費者向けガイダンスから分離します。

創業者 / 非技術系

エスカレーションする前にインシデントの範囲を調査する

消費者訴訟と企業訴訟では異なる証拠が必要です。

次のステップ

  1. メールボックス サービスを特定します。
  2. 影響を受けるストリームを追跡します。
  3. ユニバーサルOutlookラベルは避けてください。

[ よくある質問 ]

よくある質問

Outlookアプリを使用すると受信ポリシーが特定されますか?

いいえ。実際のメールボックス サービスと診断を特定します。

5.7.515 の記事ではどのサービスがカバーされていますか?

Outlook .com および関連する Microsoft 消費者向け電子メール サービス。

現在のプロバイダーのガイダンス

SPFが失敗してもDMARC通過できますか?

はい、調整に成功したDKIM署名を通じて可能です。

RFC 9989 §5.3.5

それは消費者の大容量ゲートを必ず満たすのでしょうか?

いいえ。Microsoft のサポート記事では、 SPFとDKIM両方に合格する必要があります。

現在のプロバイダーのガイダンス

5,000 はまさに免除として扱われる必要がありますか?

いいえ。現在のサポート文言は 5,000 以上を使用しています。

現在のプロバイダーのガイダンス

これにより、永続的な大量ステータス ルールが確立されますか?

いいえ。引用されたサポート ページから分類の有効期間を推測しないでください。

現在のプロバイダーのガイダンス

管理者は拒否を修正するためにDMARC無効にする必要がありますか?

まず障害のある ID を診断します。やみくもな修復として政策を弱めないでください。

合成 SPF 失敗例は Microsoft に送信されましたか?

いいえ。これは、プロトコル ロジックとプロバイダー要件の違いを示しています。

[ 情報源 ]

情報源

  1. RFC 8601

    セクション §5

  2. RFC 9989

    セクション §4.4 · §5.3.5

  3. マイクロソフトの公式要件

    セクション 大量の (大規模な) 送信者を定義するものは何ですか? · 認証要件

  4. MICROSOFT UPDATEの公式要件

    セクション 施行スケジュール

[ 用語集 ]

用語集

消費者向けメールボックス
エンタープライズ テナントではなく、プロバイダーのコンシューマ サービス内のメールボックス。
5322.から
メッセージの From ヘッダーに表示される作成者のアドレス。
5321.メール送信元
メッセージ転送中に使用されるSMTPエンベロープ送信者の ID。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース