2026年11月5日以降、Outlook.com、Hotmail、Live、およびMSNアドレスをカバーするMicrosoftの消費者向けメールサービスは、DMARCレコードを公開していないドメインからの特定のメールを拒否し始めました。この変更は、公式なポストマスター通知、ブログ投稿、またはサービスヘルスエントリなしに実施されたため注目されており、多くの低ボリューム送信者を不意打ちの状態に陥れています。
執行範囲の変化
以前、Microsoftが公開していたルールは主にバルク送信者(1日あたり5,000件以上のメッセージを送信する者)を対象としており、SPF、DKIM、およびDMARCをパスすることを要求し、そうでない場合は「550 5.7.515 Access denied」エラーを返すものでした。しかし、この新しい動作は、小さなオフィスからの1行の返信のような低ボリュームの送信者にも及びます。
以前のルールはマーケターを対象としていましたが、この新しい拒否はDMARCレコードを欠くすべてのドメインを対象としています。送信者に提供されるエラーメッセージは「550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records」であり、これはSPFとDKIMが機能している場合でも、根本的な認証の失敗があることを示唆しています。
「Outlook.com、Hotmail、Live、およびMSNは、DMARCレコードのないドメインからのメールの一部を拒否するようになりました。」
— Outlook.com Is Quietly Rejecting Email From Domains Without DMARC | MailRoute
一貫性のない拒否のメカニズム
この変更の最も困難な側面の一つは、その一貫性の欠如です。Microsoftは影響を受けるドメインからのすべてのメールを拒否するわけではありません。代わりに、あるメッセージを通過させ、次のメッセージを拒否したり、再送したものが突然成功したりすることがあります。このランダム性により、送信者は恒久的な構成要件ではなく、一時的なネットワークの不具合であると誤認する可能性があります。
核心的な問題は、「アライメント」を提供するためのDMARCレコードの欠如です。ドメインに有効なSPFおよびDKIMレコードがある場合でも、DMARCはこれらのレコードが「From」アドレスに記載されているドメインに実際に属していることを確認するプロトコルです。このリンクがない場合、Outlook.comはメールを未認証として扱う可能性があります。
実用的な影響と修正策
患者、住宅所有者、または応募者など、個人用アドレスへの到達に依存する企業にとって、この変更は「静かな」失敗を招く可能性があります。請求書、予約の確認、および返信が届かなくなり、コミュニケーションの欠落やレスポンスの欠如と見なされる原因となります。
解決策は、単一のDNS TXTレコードです: `v=DMARC1; p=none`。このレコードは、ドメインがDMARCを使用していることを宣言し、失敗に対して受信者に何もしないよう求めることで、認証のベースラインを確立します。これはGmailやYahooなどの他のプロバイダーがメールを処理する方法を変更するものではありませんが、Outlook.comの新しい要件を満たします。
メールセキュリティの新しい基準
この動きは、DMARCが推奨されるベストプラクティスから必須の基準へと移行している、より広範な業界のトレンドを反映しています。DMARCを要求することで、メールボックスプロバイダーは、ビジネスメールの侵害の主な要因であるなりすましやフィッシングに対して、より効果的に対抗できるようになります。
現在の `p=none` 設定は、配信を確保するための最低要件ですが、これは `p=reject` への第一歩として機能します。このより高いレベルの執行は、最終的に受信者に対してドメインを偽装したすべてのメールを拒否するよう指示し、正当な送信者に対してより強力なブランド保護を提供します。
Hacker Newsの読者の反応
- 体験談: 適切なSPFおよびDKIM署名を持つドメインからのメールが、DMARCレコードを欠いているためにバウンスしたことを報告した、メールシステムを管理するコメント者が一人いました。 コメント ↗
- 体験談: あるユーザーは、SPFとDKIMを設定していたにもかかわらず、DMARCレコードの欠如のためにブロックされたという個人的な経験を共有しました。 コメント ↗
- 懐疑的: あるコメント者は、メールの配信を拒否することは独占を生み出すと主張し、プロバイダーはDMARCのないメールを完全にブロックするのではなく、スパムとしてフラグを立てるべきだと示唆しました。 コメント ↗
- 懐疑的: 別のコメント者は、SMTPレベルでの拒否なしにメールをドロップすることは、セルフホストユーザーが構成が正しくないことに気づくことを困難にするという懸念を表明しました。 コメント ↗
Hacker Newsのスレッドで出た意見の要約です。事実として検証されたものではありません。 議論の全文を読む ↗
