## TL;DR
External auto-forwarding is blocked at several layers, and mail escapes when any layer is missed: the outbound spam policy may allow it, a transport rule may not cover client-created rules, or remote domain settings may permit it. Check each layer in turn, set them consistently to block or to allow only named domains, and then sweep for existing forwarding rules the block will not remove retroactively.

```text
auto-forward to external domain not blocked by dlp rule error
```

## Use this when
- Users or an audit find mail auto-forwarding to personal or external accounts.
- A compromised account forwarded mail out despite a stated no-forwarding policy.

## Not for this skill when
- Forwarding is an approved, time-boxed migration setting. Document it instead of blocking.
- The forwarding is a user manually sending mail on. DLP content rules, not forwarding controls, govern that.

## Steps
1. Check the outbound anti-spam policy setting for automatic external forwarding and record its value. Verify: the primary control state is known.
2. Check remote domain settings and any transport rule meant to block auto-forward message types. Verify: all layers agree, or the permissive layer is identified.
3. Set the layers to block external auto-forwarding, or to allow only explicitly approved domains if the business requires some. Verify: settings are saved and documented.
4. Sweep mailboxes for existing inbox rules and mailbox forwarding settings that forward externally, since policy blocks new use but old rules may persist. Verify: existing forwarders are listed and reviewed with owners.
5. Test by creating a forwarding rule in a test mailbox to an external address and sending mail to it. Verify: the forward is blocked and the event is logged.

## Variant phrasings
### automatic external forwarding not blocked outbound policy
The outbound policy variant.
### disable auto forward office 365 layers remote domain
The layers variant.

Compatibility: Defender outbound spam policies, Exchange remote domains and mail flow rules.

## Why it happens
Forwarding grew organically as a user feature, so its controls are scattered across policy generations. Attackers and departing staff both rely on at least one layer being left permissive, and auditors usually check only the best-known one.

## Edge cases / pitfalls
- Mailbox-level forwarding set by admins and inbox rules set by users are different stores. Sweep both.
- Approved forwarding exceptions are prime abuse targets. Review them monthly.
- Alert on new external forwarding creation even where blocking exists; the attempt itself is a signal.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Tent1PLatX2uTDLHhG6x1Q