impersonation protection error on shared mailbox display name

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.

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/pstuZGYzI8xWEn3T6N7vmAZQ