## TL;DR
Shared mailboxes break the assumptions of impersonation protection: names like Accounts Payable or IT Support are used by teams, partners and, unfortunately, attackers. A protected-user entry for a shared name can flood alerts on legitimate team mail, while removing it invites exact-name spoofing. Handle shared names with domain-aware rules: trust the name only from authenticated own or partner domains, and flag it from anywhere else.

```text
impersonation protection error on shared mailbox display name
```

## Use this when
- Impersonation alerts fire constantly for a shared service name, or a spoof using that name sailed through.
- A shared mailbox was added to or missing from the protected users list.

## Not for this skill when
- The impersonated name belongs to one executive. Standard protected-user handling applies.
- Alerts are about domain impersonation, not display name matching.

## Steps
1. List which shared names are in impersonation protection and sample the last week of alerts for one name, splitting own-domain from external senders. Verify: legitimate versus hostile use of the name is quantified.
2. Remove the shared name from the personal protected-users list if most legitimate use is internal, and replace it with a rule keyed on external origin. Verify: internal team mail no longer alerts.
3. Add a transport or anti-phishing rule: external mail using the shared display name from a non-partner domain goes to quarantine or gets a warning banner. Verify: the rule conditions check both name and origin domain.
4. Register partner domains that legitimately send under the shared name as trusted senders for this check only. Verify: each trusted domain is named with a business owner.
5. Test with an external test account using the shared name. Verify: the test is flagged, while internal and partner test mail pass.

## Variant phrasings
### impersonation protection shared mailbox false positive
The false positive variant.
### display name impersonation shared service account rule
The rule design variant.

Compatibility: Defender anti-phishing impersonation settings and Exchange mail flow rules.

## Why it happens
Impersonation models learn or list individuals. Shared service names have many legitimate senders, so the model either over-alerts or, when admins silence it, under-protects exactly the names finance and IT spoofs prefer.

## Edge cases / pitfalls
- Publish a canonical list of service names and their real domains so users can verify unexpected external use.
- Banners beat silent quarantine for shared names, because recipients often expect partner mail under them.
- Review the trusted partner list when vendors change; stale trust is a standing hole.

## Provenance

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