## TL;DR
The external banner is inserted by a mail flow rule that prepends a disclaimer to external messages. When it is missing on a phish, either the message did not traverse the rule path, matched an exception, or the rule failed on that message format. Check the rule conditions and exceptions, the connector path the phish used, and whether the message was later forwarded or re-sent internally, which legitimately drops the banner.

```text
external sender banner missing on phish email; transport rule failed
```

## Use this when
- An external phish shows no external sender banner or tag.
- Banner coverage is inconsistent across external senders.

## Not for this skill when
- The message is internal or was forwarded internally after arrival. Absence is expected there.
- The banner appears but users ignore it. That is a design and training issue, not a rule fault.

## Steps
1. Trace the phish and confirm it entered as external mail through the normal inbound connector. Verify: the entry path should have triggered the banner rule.
2. Read the banner rule conditions and exceptions for matches this message could hit, such as sender allow entries or message type exclusions. Verify: any exception the message matches is identified.
3. Check the rule mode and priority, including stop-processing from earlier rules that could end evaluation first. Verify: the rule actually evaluates on inbound external mail.
4. Test with a fresh external message in each format, plain, HTML and calendar invite. Verify: the banner appears in every format or the failing format is named.
5. Fix the gap, then retest and sample a day of external mail for banner presence. Verify: coverage in the sample is complete.

## Variant phrasings
### external sender banner missing transport rule disclaimer
The missing banner variant.
### external tag not applied some external mail exchange
The inconsistent coverage variant.

Compatibility: Exchange Online external tagging and disclaimer mail flow rules.

## Why it happens
Banner rules are ordinary transport rules with ordinary failure modes: exceptions written for one vendor, format quirks, and alternate ingress paths all punch holes. Attackers do not need to remove the banner; they only need a path where it was never added.

## Edge cases / pitfalls
- Native external tagging in newer tenants is more reliable than disclaimer insertion. Prefer it where available.
- A banner inserted as HTML can fail on plain-text-only messages. Cover both parts.
- Audit banner coverage by sampling, not by trusting the rule state.

## Provenance

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