Defaults.Exposed › 修正 › Guides

Outlook がメールを拒否する：550 5.7.515、550 5.7.509 と compauth=fail の解説と修正（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

2つの異なる Microsoft システムがメールを拒否する。コンシューマー Outlook.com は認証に失敗した大量送信者をバウンスし（550 5.7.515、2025年5月から施行）；Exchange Online は自ドメインの DMARC reject ポリシーに失敗したメールをバウンスする（550 5.7.509）。Defaults.Exposed の 261,086,232 ドメインのセンサスによると、spf.protection.outlook.com を認可する 10,205,070 ドメインのうち、85.0% が strict SPF を持つが DMARC を適用しているのはわずか 21.7% だ。

「Outlook がメールを拒否する」という問題のほとんどは実際には拒否ではない — ヘッダーに compauth=fail があるメールが静かに迷惑メールフォルダに入るのだ。このガイドは Microsoft のコードをデコードし、Authentication-Results ヘッダーの読み方を示し、修正を順序立てて説明する：SPF を確認し、カスタムドメインの DKIM を有効にし、DMARC を公開して適用し、再テストする。

どの Microsoft エラーを実際に持っているか？

Microsoft は2つの別々の受信サーフェスを運用し、異なる理由で拒否する。まず症状を照合する — 間違った診断は1日を無駄にする。

正確な NDR の表現は変わる；依拠する前に引用する文字列をライブのバウンスと照合すること。

550 5.7.515 とは何を意味するか？

これはコンシューマー Outlook.com/Hotmail の要件であり、Microsoft 365 テナントのエラーではない。2025年5月以来、コンシューマー Outlook アドレスに1日 5,000 通超を送信する送信者は、SPF に合格し、DKIM に合格し、From ドメインとアライメントした DMARC レコード（少なくとも p=none）を公開しなければならない。その基準に失敗するとコンシューマー Outlook は次のような表現で拒否する：

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

これがではないことが2つ：2026年の義務ではない（メールが最近バウンスし始めたなら、ルールではなく送信量または DNS が変わった）、そして受信者の M365 テナント設定ではない。修正は以下の認証ステップだ — 5,000 通/日を超えるキャンペーンの日も対象になる。

550 5.7.509 とは何を意味するか？

これはビジネステナントの Exchange Online Protection から来て、自ドメインの DMARC ポリシーが適用されていることを意味する：

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

注意深く読む — Microsoft が難しくしているのではない。ドメインが p=reject を公開し、このメッセージが DMARC に失敗し、受信側はあなたが指示した通りのことをした。バウンスされたメールが正規のものであれば、ある送信元（ニュースレタープラットフォーム、CRM、スキャン対電子メールデバイス）がアライメントした方法で認証されていない。ポリシーを弱めない；その送信元にアライメントされた SPF または DKIM を与える — DMARC の修正と p=none から p=reject へを参照。

Outlook がバウンスせずに compauth=fail でメールを迷惑メール判定するのはなぜか？

Microsoft の配信性の問題のほとんどはバウンスを生成しない。メッセージは受け付けられ、スコアリングされ、迷惑メールフォルダに入る — 唯一の証拠は Authentication-Results ヘッダーだ。受信者のメールボックス（または自分の outlook.com テストメールボックス）でメッセージを開き、**「メッセージのソースを表示」**を選択し、次の行を見つける：

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth は Microsoft の複合認証の判定だ：ドメインが DMARC レコードを公開していない場合でも、Microsoft は暗黙的な DMARC 的チェックを適用する。よく見られる値：

• compauth=fail reason=000 — メッセージが明示的認証に失敗：ドメインの DMARC ポリシーが quarantine/reject でメッセージが失敗した。
• compauth=fail reason=001 — メッセージが暗黙的認証に失敗：ドメインが認証レコードを公開していない（または不十分）で、メッセージがあなたから来たように見えなかった。典型的な「DKIM/DMARC を設定したことがない」パターン。
• compauth=fail reason=6xx — 暗黙的認証の失敗バリアント；601 は送信ドメインが組織自身の受け入れドメインの1つであることを意味する（組織内なりすまし、自己から自己へ）。

教訓：Microsoft では、NDR だけでなくヘッダーも読む。同じ行の spf=、dkim=、dmarc= の判定が、どのレグを修正すべきかを正確に教えてくれる。

Outlook の拒否と迷惑メール判定を修正するには？

1. 最初に無料スキャンを実行する。 SPF、DKIM、DMARC を1回で採点し、DNS を変更する前にどのレグが失敗しているかを表示する。
2. SPF を確認する — Microsoft 365 では通常すでに問題ない。 標準レコードは v=spf1 include:spf.protection.outlook.com -all で、M365 のセットアップがそこに入れる：spf.protection.outlook.com を認可する 10,205,070 ドメインの 85.0% がすでに strict な -all で終わっている（2026-06-29 時点データ）。1つのガードレール：受信側は SPF を From ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメインに対して評価する — そのためニュースレタープラットフォームが自社のバウンスドメインで SPF を合格させてもあなたのために何もしない。だからステップ3と4の方が重要だ。
3. カスタムドメインの DKIM を有効にする — セレクター CNAME が2件。 M365 はカスタムドメイン署名をオンにするまでアライメントしない onmicrosoft.com のデフォルトで署名する：テナントのキーを指す selector1._domainkey と selector2._domainkey の CNAME を公開し、Defender ポータルで署名を有効にする。完全なクリック操作：Microsoft 365 での DKIM 設定。DKIM が「合格」と表示されているのに DMARC が失敗する場合はデフォルト署名の落とし穴にある。
4. DMARC を公開し、適用する。 v=DMARC1; p=none; rua=mailto:... から始めてレポートを取得し、レポートが明らかにするすべての正規の送信元を修正し、p=quarantine と p=reject に漸増する — 段階的なパスは DMARC の修正にある。これはほとんどの Microsoft ショップが省略するステップだ：M365 送信ドメインのうち DMARC を適用しているのはわずか 21.7%。
5. ヘッダーを読んで再テストする。 コンシューマーの outlook.com メールボックスに送信し、メッセージソースを開き、spf=pass、dkim=pass、dmarc=pass、compauth=pass を確認する。
6. 大量送信者：コンシューマー Outlook の基準を満たす。 5,000 通/日を超える場合は、有効でモニタリングされた From/reply-to、機能する配信停止、クリーンなリストも必要だ — 認証が 5.7.515 を解消；苦情率が S3140/S3150 の IP ブロックを防ぐ。すでに IP ブロックされている場合、SPF/DKIM/DMARC の修正はブロックを解除しない：Microsoft の送信者サポートを通じてリスト除外をリクエストし、認証を二度と戻らない理由として扱う。

なぜこれほど多くの Microsoft 365 ドメインが依然として失敗するのか？

デフォルトが最初のステップを代わりにやってくれて、残りは何もしないからだ。spf.protection.outlook.com を認可する 10,205,070 ドメインのうち、85.0% が strict SPF（M365 セットアップ時に手渡されるレコード）を持つが、Defaults.Exposed の 261,086,232 ドメインのセンサスによると、DMARC を適用しているのはわずか 21.7% だ。M365 はデフォルトで strict SPF を与え、ほとんどのテナントはそこで止まる — まさに compauth が捕まえるように設計された集団だ（ただし全採点済みドメインの 10.59% という DMARC 適用率より上）。プロバイダーの完全な比較：メールプロバイダー SPF ランキング。

よくある質問

550 5.7.515 は Microsoft 365 のエラーか？ いいえ。コンシューマー Outlook.com/Hotmail から来て、5,000 通/日超の送信者を対象とし、2025年5月から施行されている。ビジネスの Exchange Online の拒否は異なるコードを使用する — 最も一般的なのは 550 5.7.509（自ドメインの DMARC reject ポリシー）または 5.7.511（禁止送信者）。

550 5.7.509 が来たが、メールは正規のものだった — p=reject をやめるべきか？ いいえ — ポリシーが未認証の送信元を捕まえた、それが機能している証拠だ。ヘッダーまたは DMARC レポートで送信元を特定し、アライメントされた DKIM（またはアライメントされた SPF）を与える。p=none に弱めると、すべての人に対して完全ドメインなりすましへの扉を再び開く。

compauth=fail は誰かがなりすましていることを意味するか？ 必ずしもそうではない。reason=001 は通常、自分のメールが自分のものだと証明できないことを意味する — アライメントされた DKIM なし、DMARC なし。10,205,070 の M365 送信ドメインのうち DMARC を適用しているのはわずか 21.7%（2026-06-29 時点データ）なので、Microsoft は他のすべての人に暗黙的チェックを適用し、未認証の正規メールもそれに失敗する。

1日 5,000 通未満の送信 — 無視できるか？ 550 5.7.515 は回避できるが、迷惑メールフォルダは回避できない：compauth はどの送信量にも適用される。Gmail も同様のことをする — Gmail 550 5.7.26 ガイドを参照。修正は無料だ；バリアントは認識の欠如であり、コストではない。

オーナーにレポートを送る

他の人のメールを修正する場合 — クライアント、上司、請求書がバウンスしていた会社 — 証拠で仕事を完了させる。DNS が安定したら無料スキャンを再実行し、採点レポートを転送する。SPF、DKIM、DMARC が緑になっていることを、ビジネスオーナーが読める平易な言葉で示す。次にサイバー保険更新や顧客セキュリティアンケートで「メールを認証しているか？」と聞かれた時に必要な成果物だ。修正は良いことだ；証明できる修正が報酬とカバーをもたらす。

ドメインを無料でチェックする

Microsoft が失敗しているレグ（SPF、DKIM、DMARC）を — プライベートかつオーナー限定で確認する。

ドメインをチェックする → · DMARC を修正する → · DKIM は合格するが DMARC が失敗する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。