550 5.4.1 Access denied の原因4つと対処
目次
この記事では、Microsoft 365 / Exchange Online で発生する 550 5.4.1 Access denied の意味、4 つの主要原因、切り分け手順を整理します。
エラーコード 550 5.4.1 の意味
メール送信が失敗したときに返される NDR（Non-Delivery Report、配信不能通知）には SMTP のステータスコードが含まれています。550 は永続的な配信失敗を表す SMTP reply code、5.4.1 は Microsoft が「受信者拒否（Access denied）」を示す目的で使用している拡張サブコードです。RFC 3463 上の 5.4.1 は元々「No answer from host」（送信先ホスト無応答）として定義されていますが、Microsoft 365 / Exchange Online は独自に「Recipient address rejected」の意味で 550 5.4.1 を返します。本記事は Microsoft 拡張の 550 5.4.1 Access denied を対象としています。
Microsoft 365 環境では、典型的に次のような文面で返ってきます。
Remote Server returned '550 5.4.1 <[email protected]>:
Recipient address rejected: Access denied'
この文面は 「メール自体は受信側に届いたが、相手側のポリシーで明示的に受信を拒否された」 ことを意味します。送信側のメール認証（SPF / DKIM / DMARC）が通っていても発生するため、認証設定だけを見直しても解決しないケースが多いのが特徴です。
メール認証の基本はDMARC とは何かで整理しています。本記事は認証通過後の「受信側で弾かれる」パターンに絞って扱います。
主要な発生原因 4 つ
原因 1: 受信者メールボックスが存在しない / 削除済み
最も多いパターン。退職者のアドレス宛に送ってしまった、共有メールボックスが削除された、エイリアスが解除された等です。受信者ドメインの MX レコードは Microsoft 365 を指しているため接続自体は成立し、ユーザー解決の段階で Access denied が返ります。
切り分け：受信側の管理者に「該当アドレスが現在も有効か」を確認するのが最短です。
原因 2: Connector 設定で送信ドメインが許可されていない
受信側の Exchange Online で パートナー Connector（Partner Connector）を使い、特定ドメインからのみ受信を許可している運用の場合、許可リスト外のドメインからの送信は 5.4.1 で弾かれます。BtoB の閉域メール運用や、子会社・グループ会社専用の Connector を組んでいる企業で発生しがちです。
切り分け：受信側に「Connector で送信元ドメインを制限していないか」「自社ドメインを許可リストに追加できるか」を依頼します。
原因 3: メールフローポリシーで拒否
Exchange Online の メールフロー ルール（トランスポートルール） で、件名・本文・送信元ドメインの条件にマッチしたメールを拒否する設定が組まれていると、5.4.1 Access denied が返ります。情報漏洩対策（DLP）や、社外送信制御の一環で組まれていることが多いです。
切り分け：受信側で Exchange Admin Center → メールフロー → ルールの一覧を確認してもらいます。
原因 4: ライセンス未割り当てユーザーへの送信
Microsoft 365 の Exchange Online ライセンスが割り当てられていないユーザーアカウントは、メールボックスを持たないため受信できません。新入社員アカウントの作成直後や、ライセンス見直しの過渡期に発生します。
切り分け：受信側管理者に「対象ユーザーに Exchange Online プラン（または Microsoft 365 Business / E3 等）が付与されているか」を確認します。
切り分けの手順
Step 1: バウンスメールから情報を抽出
NDR の本文から以下を取得します。
- Diagnostic information for administrators ブロック内の Remote Server 文面
- Reporting-MTA と Final-Recipient
- Original Message Headers の
Received行
これで、エラーが受信側の Exchange Online から返されているのか、中継サーバから返されているのかが分かります。
Step 2: 送信側で Message Trace を確認
送信元が Microsoft 365 の場合、Exchange Admin Center の メールフロー → メッセージトレース で対象メッセージを検索すると、配信状況の詳細イベントが取得できます。Failed イベントの詳細に Access denied が含まれていれば、受信側ポリシーでの拒否が確定します。
公式リファレンス: Non-delivery report error codes in Exchange Online
Step 3: 受信側に確認依頼
切り分けの結果が揃ったら、受信側の IT 部門に以下を依頼します。
- 該当アドレスの存在確認とライセンス状態
- Connector / メールフロールールでの拒否ログの有無
- 自社ドメインの許可リスト追加可否
似たエラーコードとの混同に注意
550 5.7.1: 認可拒否（リレー拒否やスパム判定）550 5.7.26: 認証失敗（SPF / DKIM / DMARC のいずれかに不合格）。詳しくはGmail 550 5.7.26 の対処を参照421 4.7.0: 一時的な拒否。詳しくは421 4.7.0 一時拒否の対処を参照
NDR 内のステータスコードを正確に確認することが、対処の出発点です。
送信側で予防できること
5.4.1 は受信側起点のエラーですが、送信側でできる予防策もあります。
- 配信先リストを定期的にクリーンアップし、退職者アドレスを除外する
- 一斉配信前にテストアドレスへ事前送信し、Connector 拒否を早期検出する
- SPF / DKIM / DMARC を整え、認証起因の二次的な拒否を防ぐ
特に DMARC は受信側の判定材料になるため、未設定の場合はDMARC 設定ガイドを参考に最小構成（p=none）から導入することを推奨します。
まとめ
550 5.4.1 Access deniedは受信者側ポリシーによる明示拒否- 原因は受信者不在 / Connector / メールフロールール / ライセンス未割当の 4 系統
- Message Trace と NDR ヘッダで切り分け、最終的に受信側 IT 部門と連携する
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。