バグかポリシー変更かは不明ですが、Outlook、Hotmailなどマイクロソフトの個人向けアカウント宛ての正規メールが一貫性なく拒否されています。エラーメッセージには、メール認証が見つからない、または失敗したと表示されます。
Microsoftのメールフィルターは、ユーザーを悪意あるメッセージから守るためのものですが、正規のメールまで拒否しているようです。
ここ数日、DMARC（Domain-based Message Authentication, Reporting, and Conformance）レコードを公開していないドメインから送られた一部のメールが、Microsoftの個人向けアドレス宛てに送信できず、バウンスしています。対象はOutlook、Hotmail、Live、MSN宛てのメールです。
拒否は11月5日に始まり、本稿執筆時点でも続いています。Microsoftはポリシー変更を発表しておらず、postmasterへの告知、サービス正常性情報への掲載、ブログ記事の公開も行っていません。
Dickson ResearchのFrank Dickson氏（プロフィール）は、ポリシー変更とバグの両方が絡んでいる可能性があると指摘しています。
「送信ドメインすべてに身元の証明を求めれば、メールはより安全になります。しかし、予告なしに実施し、しかも誤った原因を指すエラーメッセージを返せば、混乱を招くだけです」と同氏は述べています。
断続的に発生する送信障害
DMARCは、なりすまし、フィッシング、ビジネスメール詐欺（BEC）を防ぐための仕組みです。Microsoftは2025年5月から、個人向けメールボックスに1日5,000通を超えるメールを送信するドメインに限り、DMARCを必須とするルールを設けています。
ところが11月5日以降は、大量送信者ではない小規模で一般的な送信者のメールまで、DMARC、SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）の不備を理由にバウンスされています。送信者には、550 5.7.1または550 5.7.23のエラーを示す配信不能通知（NDR）が届いています。ただし発生は一定せず、届くメールもあれば拒否されるメールもあります。
たとえば、あるユーザーはMicrosoftのコミュニティフォーラムに次のエラーメッセージを投稿しました。
<redacted>@hotmail.com宛てのメッセージを配信できませんでした。
hotmail.comは、お客様のメッセージが信頼できる場所から送信されたことを確認できませんでした。
別のユーザーも同じ問題を報告し、「問題なく届くメールもあれば、SPF failedのエラーで返ってくるメールもある」と書き込んでいます。さらに混乱を招いているのが、バウンスされたドメインの中に、SPF、DKIM、DMARCが正常に機能していたものがあったという報告です。
Microsoftの外部スタッフのモデレーターは、この問題を「サービス品質の低下」と位置づけ、現在調査中だとしています。
メールセキュリティ企業のMailRouteによると、企業は任意のターミナルで次のコマンドを実行すれば、自社ドメインが影響を受けるかを確認できます（example.comは自社ドメインに置き換えます）。dig +short TXT _dmarc.example.com。応答がv=DMARC1で始まっていればDMARCレコードが存在し、応答がなければ存在しないとMailRouteは説明しています。
対処法は、TXTレコードを1件追加することです。内容はv=DMARC1; p=noneです。これにより、ドメインがDMARCを利用していることを宣言し、受信側にレポートの送信を求めます。一方、認証に失敗しても何も措置を取らないよう指示する設定だとMailRouteは説明しています。
なりすましを困難にするDMARC
DMARCは、ドメインで有効にしておく必要がある2つの基本的なメール認証技術、SPFとDKIMを土台としています。
SPFは、送信サーバーのIPアドレスがそのドメインに代わってメールを送信することを許可されているかを検証します。DKIMはメッセージに暗号署名を付加し、途中で改ざんされていないこと、および送信元として示されたドメインのメールであることを証明します。
DMARCはこの2つの結果を踏まえ、「From」アドレスに記載されたドメインが、検証済みのドメインと一致しているかを確認します。この確認を、読者が実際に目にする送信者名と結びつけ、偽造メールをどう扱うかを受信側に伝えるとDickson氏は説明します。
「DMARCがなければ、ドメインのなりすましは簡単です。フィッシングやビジネスメール詐欺の多くは、そこから始まります」と同氏は述べています。
ただしMicrosoftは、少なくともこれまでは大規模な送信者にしかDMARCを求めてこなかったため、DMARCはあらゆる送信者に普及しているわけではありません。小規模な送信者が自分たちには関係ないと考えたのも無理はないとDickson氏は指摘します。中小企業、非営利団体、学校のほか、法律事務所、会計事務所、診療所といった専門職の事務所が該当します。こうした組織の多くは、「何年も前に誰かが設定したきり、誰も手を付けていない」ドメインを使っています。
大規模な組織でも、副次的なドメインや地域別ドメインのほか、マーケティングや請求のプラットフォームが送信に使うサブドメインでDMARCが抜け落ちています。理由はありふれたものです。ドメインネームシステム（DNS）の管理者が決まっておらず、「第三者が送る正規のメールを壊すことへの不安がある」とDickson氏は言います。
気付きにくく、一貫性のない障害
MailRouteが指摘するように、この障害が特に厄介なのは、発生が一定しないことです。メールを送った本人には、専門用語だらけのバウンスメッセージが届きます。本人は一時的な不具合だろうと考えて放置してしまいます。一方、受け手のほうは、メールが送られたこと自体を知りません。
障害は静かに進行します。これは「メールマーケターにとって最大の悩みの種」だとDickson氏は言います。顧客、患者、求職者などがHotmail、Outlook、Live、MSNを使っており、請求書、パスワードのリセット、予約確認、内定通知が届かなければ、相手は自分が無視されていると受け取ります。メールが届いていないとは、必ずしも考えません。
朗報は、障害を見つけ出せることです。拒否されたメールはすべてバウンスを生成し、バウンスは記録に残るとDickson氏は指摘します。企業は、11月5日以降のメールログ、メールプラットフォームのバウンスレポート、ヘルプデスクのチケットから、「Message lacks SPF/DKIM/DMARC」と記載された項目を検索すべきだとしています。
その上で、重要なメールを再送します。まずは、時間的な制約が大きいトランザクションメールからです。
次に原因を解消します。自社名義でメールを送るすべてのドメインがDMARCレコードを公開しているか確認するようDickson氏は助言しています。レコードがなければ、基本的な監視用レコード（p=none）を追加すれば、このバウンスは止まります。SPFまたはDKIMがFromドメインと整合していれば、他者による自社メールの扱いも変わりません。
自社ドメインでDKIMを有効にしていないMicrosoft 365の利用者は、今すぐ有効にすべきだと同氏は助言します。「バウンスのメッセージがSPFを原因に挙げていても、それだけを理由にSPFを書き換えてはいけません」とも述べています。レコードに問題がないのにメールがバウンスされる場合は、バウンスの全文をMicrosoftに送れば、調査に反映されます。
ただし、p=noneのレコードは「一塁であって、ホームベースではない」と同氏は言います。目指すのはp=rejectです。これは、自社名を騙る者のメールを拒否するよう受信側に指示する設定です。
自社名義でメールを送るサービスをすべて洗い出すようDickson氏は助言しています。対象はCRM、請求システム、人事プラットフォーム、マーケティングツールなどです。「そのリストを作れない組織がほとんどです。誰が自社ドメインを使って発信しているか分からなければ、ドメインを守ることはできません」と同氏は指摘しています。
今後を示すシグナル
今回の不具合の原因はまだ分かっていませんが、企業は今後の方向性を見誤るべきではないとDickson氏は述べています。DMARCはあらゆる送信者に義務付けられていくという見立てです。GoogleとYahooは2024年2月に大量送信者へDMARCを求め始め、Microsoftは2025年5月に続きました。
「要件はまず大手の送信者から始まり、やがて全員に求められる最低条件になります。今回の展開はお粗末でしたが、行き着く先は疑いようがありません」と同氏は語ります。Microsoftが目指す方向は正しいとしながらも、「新しいルールをバウンスメッセージで知るようなことがあってはなりません」と指摘しています。
この記事はもともとComputerworldに掲載されたものです。
