Microsoft 365などで外部ドメインへの自動転送を設定した際に、突然「5.7.520 Access denied」エラーが表示されて困った経験はありませんか？その原因や対処策を徹底的に解説します。セキュリティと利便性を両立するコツもご紹介します。
「5.7.520 Access denied」エラーとは
「5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555).」というエラーは、Exchange OnlineやMicrosoft 365で外部ドメインへの自動転送がブロックされている際に表示されるメッセージです。これはスパム対策や情報漏洩対策の一環で、組織のポリシーによって外部転送が制限・禁止されている場合に発生します。
なぜ外部への転送が制限されるのか
企業や組織では、機密情報の漏洩を防止するために、外部への自動転送を全面的にブロックする設定が行われることがあります。特に、サイバー攻撃や内部不正などの脅威から組織を守る手段として、外部転送の禁止や制限は有効な対策の一つです。
一般的な発生例
- ユーザーがOutlookルールで外部メールアドレスへの転送を設定しようとした
- 管理者が自動転送ポリシーを「オフ」にしている状態でユーザーに転送許可を与えようとした
- テナント全体の「Outbound spam filter policy」でAutomatic forwardingが無効になっている
外部転送がブロックされる具体的な仕組み
外部転送の可否を判定しているのは、主に「Outbound spam filter policy」(アンチスパム対策ポリシー)や、組織全体のメールフロー設定です。これらのポリシーが外部への自動転送を禁止していると、メールサーバー側で転送要求が遮断され、「5.7.520 Access denied」というエラーを返します。
Outbound spam filter policyの役割
組織内から外部へ送信されるメールがスパムやマルウェア配信の温床にならないように、Microsoft 365には独自のアンチスパムポリシーがあります。その中で自動転送に関する設定を「On」「Off」「Automatic – System-controlled」の3つから選ぶことができます。
3つの設定モード
| モード | 内容 |
|---|---|
| On | 外部転送を許可する |
| Off | 外部転送を全面的に禁止する |
| Automatic – System-controlled | システムの判断で外部転送が実質オフ扱いとなる既定状態 |
なぜ「Automatic – System-controlled」で転送できないのか
このモードでは、Microsoftのセキュリティ基準に基づき、外部転送は原則オフとして扱われます。ポリシーが「Automatic – System-controlled」のままになっている場合、組織外へのメールの自動転送を許可していないのと同様になります。
対処方法の概要
エラーが表示された際には、以下の手順でポリシーや設定を確認し、必要に応じて変更を行うことが推奨されます。
1. Microsoft 365管理センターまたはExchange管理センターへアクセス
まずは管理者権限を持つアカウントでサインインし、管理センターにアクセスします。最新のUIを使用している場合は、Microsoft 365管理センターの左メニューから「管理センター」→「Exchange」を選ぶ、または直接Exchange管理センター(EAC)へアクセスします。
Exchange管理センターを使用する場合の流れ
- Microsoft 365管理センターに管理者アカウントでログインする
- 「管理センター」一覧から「Exchange」を選択する
- 「Exchange管理センター」が開いたら、左ペインで「メール フロー」または「脅威ポリシー」を選択する
- 画面に表示される「ポリシー」や「アウトバウンドポリシー（スパム対策）」「脅威対策」を探す
2. Outbound spam filter policyの確認・変更
EAC内で「スパム対策」や「脅威対策」「ポリシー」などに該当する項目を探し、Outbound spam filter policy（もしくは送信スパムフィルターポリシー）を開きます。そこにある「Automatic forwarding」を以下のように変更します。
- 外部転送を許可したい場合：Onに設定
- 外部転送をブロックしたい場合：Offに設定
- システムの制御に任せる場合：Automatic – System-controlled（既定は実質オフ）
変更後は設定を保存し、ポリシーが組織全体に反映されるまで待ちます。反映には数分から数時間程度かかる場合があります。
PowerShellでの設定例
より詳細な管理が必要な場合、Exchange Online PowerShellを使用してポリシーを設定することも可能です。以下はPowerShellを用いた簡単な例です。
# Exchange Online PowerShellに接続
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <管理者アカウント>
# 既存の送信スパムフィルターポリシーを確認
Get-HostedOutboundSpamFilterPolicy
# 自動転送をOnに変更
Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On
# 切断
Disconnect-ExchangeOnlineこれにより、既定の送信スパムフィルターポリシーに対して自動転送を許可する設定が適用されます。
3. 個別ユーザー設定の確認
場合によっては、グローバルなポリシーを変更してもユーザー単位のポリシーやメールフロールールが競合している可能性があります。たとえば、ユーザーごとに設定されたトランスポートルールが外部転送をブロックしている、または一部のアカウントのみ外部転送を認めないように設定されているケースです。そのような場合は以下をチェックしてください。
- ユーザーのMailboxの詳細設定
- Exchange管理センターの「メール フロー」→「ルール」にあるカスタムルール
- Security & Complianceセンターでの追加セキュリティ制限
もしこれらの個別設定で外部転送が制限されている場合は、そちらのルールを無効化するか、ポリシーを変更する必要があります。
変更後もエラーが継続する場合
管理センターでOutbound spam filter policyを「On」にしても、すぐには反映されないことがあります。変更が反映されるまでに時間がかかる点に注意してください。それでも解決しない場合、以下の点を追加で検証しましょう。
1. テナント全体のデフォルトポリシーの存在
テナントによっては、複数のポリシーが並行して存在し、一つが「On」でももう一方が「Off」の設定になっていると、最終的に外部転送がブロックされる場合があります。「Default」という名前のポリシー以外にも、カスタムポリシーが設定されていないか確認してください。
2. ユーザーが作成したOutlookルールの検証
ユーザー自身がOutlookやOutlook on the Web(OWA)で独自に自動転送ルールを作成しているケースがあります。組織側のポリシーで許可されていても、ユーザー設定が誤っていたり条件と一致しなかったりすると転送に失敗することがあります。実際にOutlook画面でルールが正しく設定されているかを確認しましょう。
3. 他のセキュリティポリシーとの競合
データ損失防止(DLP)ポリシーなどが厳格に設定されている場合、外部ドメインへの転送をブロックするようなルールが働いている可能性があります。特定のキーワードや機密データを含むメールは自動的に転送がブロックされることもあるので、必要に応じて管理者にDLPポリシーの設定を確認してもらいましょう。
セキュリティと利便性のバランス
外部転送を許可すると情報漏洩のリスクが高まる一方で、業務上必要な連携が阻害される恐れもあります。以下のようなセキュリティ対策を取りつつ、許可設定を実施することでバランスをとることができます。
1. ドメイン単位で許可する
「すべての外部ドメイン」ではなく、「指定した取引先のドメインだけ転送を許可する」などの方法でリスクを限定します。Exchange管理センターのトランスポートルールを活用すれば、転送先ドメインをホワイトリスト形式で管理できるようになります。
2. MFA(多要素認証)を有効化する
外部転送を許可するユーザーのアカウントにはMFA(多要素認証)の利用を義務付けることで、不正ログインを防ぎつつ外部転送のリスクを抑制します。特に、管理者権限を持つアカウントには必須ともいえる対策です。
3. DLPポリシーの導入
社内の機密情報や個人情報などを含むメールが外部へ転送される際に検知・ブロックするためにDLP(データ損失防止)ポリシーを活用します。送信されるメールの内容を確認し、機密度が高い情報を含む場合は転送させない、といった運用が可能です。
具体的な設定例
ここでは、「社外への自動転送を基本許可するが、一部高リスクの部署や機密情報はブロックしたい」というシナリオを例に挙げてみます。
手順1: 全体ポリシーを「On」に
まずOutbound spam filter policyで自動転送を「On」に設定し、組織全体として外部転送を許可します。
# Exchange Online PowerShellに接続後
Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On手順2: 特定の部署向けにトランスポートルールを設定
機密情報の取り扱いが多い部署のユーザーだけは外部転送をブロックする場合、下記のようにトランスポートルールを作成します。
New-TransportRule -Name "Block External Forwarding for DeptA" `
-FromScope "Organization" `
-SenderMembership "部署Aの配布リストまたは動的配布リスト" `
-ApplyType "Outbound" `
-PrependSubject "[転送ブロック]" `
-RejectMessageReasonText "機密情報のため外部転送は禁止されています。" このルールによって、部署Aに所属するユーザーが外部へ自動転送する場合はブロックされます。組織全体では「On」としつつ、一部高リスク部署だけを限定的にブロックできるので、セキュリティと利便性を両立できます。
トラブルシューティングのポイント
ここでは設定変更後や各種競合を疑う際のチェックリストを整理してみました。
| チェックポイント | 確認すべき内容 | 解決方法の例 |
|---|---|---|
| Outbound spam filter policy | AutoForwardingModeがOn/Off/Automaticになっているか | 状況に応じてOnに変更し、組織全体の反映を待つ |
| テナント複数ポリシー | 「Default」以外にカスタムポリシーが有効になっていないか | 優先度の高いポリシーを確認して意図通りの設定に修正 |
| 個別ユーザーまたはグループの設定 | トランスポートルールやメール フロー ルールで外部転送をブロックしていないか | 競合があればルールを無効化または調整 |
| DLPポリシー | 機密データを含むメールを転送する際にエラーが発生していないか | DLPポリシー側のルールを精査し、例外設定を検討 |
| ユーザー側のOutlookルール | 転送先が外部であることを正しく指定しているか | 誤った条件や間違ったメール アドレスを修正 |
解決に至らない場合の最終手段
管理者として設定を見直しても状況が改善しない場合は、Microsoftサポートに問い合わせるのも選択肢の一つです。ポリシーやテナント設定の専門家がログや内部情報をもとに詳細な原因調査を行ってくれます。
サポートにスムーズにつなぐための事前準備
- エラーが発生した日時と具体的なメールアドレス、件名
- 外部転送が行えないユーザー数やアカウント一覧
- 各種ポリシーのスクリーンショットまたはPowerShell出力
- テナントIDやサブスクリプション情報
これらを整理しておくと、スムーズなサポートが受けられます。
まとめ
「5.7.520 Access denied」エラーは、一見すると複雑に思えますが、実際には「外部転送を無効化しているポリシー」が原因であるケースがほとんどです。以下のポイントを押さえておけば、スムーズに解決できるでしょう。
- まずは「Outbound spam filter policy」のAutoForwardingModeを確認し、「On」または「Off」のいずれか明確な設定にする
- 組織のセキュリティポリシーを踏まえたうえで、一部ユーザーのみ許可・ブロックしたい場合はトランスポートルールを活用
- DLPやカスタムポリシーなどの競合がないか念入りにチェック
- ユーザーや管理者で協力して実装し、反映に時間がかかることを考慮する
外部転送は情報共有のスピードアップや業務効率化に大いに役立ちます。しかし、セキュリティの観点からリスクを伴う機能であることも事実です。組織方針を明確にし、適切なポリシーとルールを組み合わせることで、安全かつ快適に外部転送を利用できる環境を整えてみてください。
コメント