Outlook.com は、DMARC レコードがないドメインからの一部のメールを拒否しています

エコシステムニュースセキュリティ・インサイト

outlook.com や Hotmail のアドレス宛てに送信したメールがバウンスされる場合は、送信元のドメインが DMARC レコードを公開しているかどうかを確認してください。11月5日以降、マイクロソフトの一般向けメールサービスでは、DMARC レコードを公開していないドメインからの一部のメッセージを拒否するようになっています。

バウンスには次のように書かれています：

550 5.7.1– 「メッセージが拒否されました：メッセージに SPF/DKIM/DMARC 認証レコードがありません (AS9031519)」

末尾にコードがない形で表示される場合もあります：

550 5.7.1– 「メッセージが拒否されました：メッセージに SPF/DKIM/DMARC 認証レコードがありません」

現時点で分かっていること

• 送信ドメインにDMARCレコードがない場合、outlook.com、hotmail.com、live.com、およびmsn.comのアドレス宛てに送信されたメールはバウンスとなります。
• SPFとDKIMが正常に機能しているドメインからもバウンスが発生しており、一部のメッセージのみが配信に失敗しています。
• MicrosoftのQ&Aスレッドでは、複数の異なるプロバイダーの送信者からのメールが拒否されたという報告が寄せられており、その一部は送信者が再送信したところ受信できたという。
• 影響を受けているのは一般ユーザー向けのOutlookのみのようです。DMARCレコードがないドメインは、Outlook.comでは拒否されましたが、Microsoft 365のビジネス用アドレスでは受け入れられました。
• 小規模な送信者も影響を受けていますが、マイクロソフトが公表したルールでは、1日あたり5,000通以上のメッセージを送信する送信者のみが対象となっています。

これが 5.7.515 のバウンスとどう異なるか

Microsoftが以前定めたOutlook.comに関するルールは、1日あたり5,000通以上のメッセージを送信する送信者に適用され、この基準に達しない送信者には「550 5.7.515」のバウンス通知が返されます。このバウンス通知には、送信ドメインが要求される認証レベルを満たしていないことが記載されており、そのメッセージに関するSPF、DKIM、DMARCのチェック結果が列挙される場合があります。一方、新しいバウンス通知には「認証レコードが欠落している」とだけ記載されるため、どのチェックに失敗したかは表示されません。

マイクロソフトの発表内容

2026年11月9日現在、マイクロソフトはこの継続中の問題をサービス品質の低下として認識しており、調査を進めています。マイクロソフトは、この変更について発表も確認も行っていません。11月9日時点で、ポストマスター通知、ブログ記事、サービスステータスの記載はいずれも公開されておらず、11月9日になっても何も掲載されていませんでした。

MicrosoftのQ&Aスレッドで、11月7日、あるモデレーターが、フォーラムの投稿者たちは、これらの報告がMicrosoftのOutlook.comメール保護チームにエスカレーションされたかどうかを確認できないと書き込んだ。そのモデレーターは、影響を受けた人々に、配信失敗のバウンスメッセージをoutlook.comのサポートに送信するよう推奨し、あるユーザーに対しては、異なるプロバイダーの送信者から2つのアカウントで断続的に受信拒否が発生していることから、これは送信者のドメインにおける単一の明らかな設定上の問題にとどまらないと述べた。 

このことから、この問題はバグによるものであり、DMARC要件に対する意図的な変更によるものではないことが示唆されます。同社は現時点では根本的な原因について詳しく説明していません。 

どうすればいいか

メールを送信するすべてのドメインについて、DMARCレコードを公開してください。dmarcianの「DMARCレコードウィザード」では、その作成手順を順を追って案内しており、 p=none まずはここから始めるのが基本です。これは当社の無料ツールスイートの一部であり、アカウント登録は不要です。MicrosoftのQ&Aスレッドへの2件のコメントによると、DMARCレコードを追加したことでバウンスが解消されたとのことです。

このレコードを無料のdmarcianアカウントと紐づけることで、どの送信者があなたのドメイン名を使ってメールを送信しているかを確認できるようになります。

SPF または DKIM は依然として検証に合格し、差出人ドメインと一致している必要があります。つまり、認証されたドメインが、差出人アドレスに記載されているドメインと一致している必要があります。DMARC は、そのいずれかが検証に合格した場合にのみ合格となります。

メールの受信者である場合、Microsoft Q&Aのモデレーターによると、outlook.comの個人用アドレスには独自のDMARCレコードは必要ないとのことです。これは、outlook.comドメインのDNSレコードがMicrosoftによって管理されているためです。また、モデレーターは、この拒否は送信者のドメインに起因している可能性が高く、メッセージが受信トレイに届く前に拒否されているため、「安全な送信者」に送信者を追加しても解決しない可能性が高いと付け加えています。 モデレーターのアドバイスとしては、送信者に、メール管理者またはプロバイダーにバウンスメッセージの全文を提供してもらい、ドメインの SPF、DKIM、および DMARC の設定を確認してもらうよう依頼することを推奨しています。

DMARCポリシーを p=none

この p=none このポリシーは、Microsoftが大量送信者に求める最低要件を満たしており、受信者がメールを処理する方法を変更することなくレポートを送信できるため、適切な第一歩と言えます。このポリシーでは、DMARCに失敗したメールに対して受信者に何の措置も講じないよう求めているため、あなたの名前を偽装したメールは依然として受信トレイに届いてしまいます。そこから通常は、レポートを確認し、失敗した正当な送信者の問題を修正してから、 p=quarantine さらに p=rejectへと進むことです。

メールボックスプロバイダーの要件は段階的に厳格化されており、各段階ごとに、対応が追いついていない送信者からのメールが返送されてきました。GmailとYahooは2024年2月に大量送信者に関するルールを設定し、マイクロソフトは2025年4月にOutlook.com向けのルールを発表しました。2026年11月5日、Outlook.comは、DMARCレコードがないドメインからのメール（小規模な送信者を含む）の一部を拒否し始めました。 

規制面では、PCI DSS 4.0では 2025 年 3 月 31 日以降、フィッシング対策が義務付けられています（要件 5.4.1）。また、そのガイダンスでは、DMARC を対策の例として挙げています。 

EUでは、NIS2により、クラウドおよびマネージドサービスプロバイダーに対し、最新の電子メールセキュリティ基準への対応計画を策定することが義務付けられています。欧州サイバーセキュリティ庁（ENISA）のガイダンスでは、こうした基準の例としてDMARCが挙げられています。

この記事は、2026年11月9日時点で判明していた情報を反映したものです。

---

さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。