## TL;DR
Homoglyph spoofs replace a letter with a visually identical character from another script, so the domain reads as your brand but resolves somewhere else, often as a punycode name. Filters that compare strings literally see a completely different domain. Enable confusable and impersonation detection where your platform offers it, add your brands as protected domains, and alert on mixed-script domains in headers during triage.

```text
mail filter failed to catch homoglyph domain spoof
```

## Use this when
- A phish From domain looks correct on screen but its underlying characters differ.
- Headers show an xn-- form of a domain impersonating your brand.

## Not for this skill when
- The spoof domain is a normal ASCII misspelling. Typosquat lists and impersonation policy cover it; Unicode checks add nothing.
- The lookalike is in the display name only, with an unrelated real domain. That is display-name spoofing.

## Steps
1. Copy the sender domain from raw headers, not from the rendered message, and inspect its code points or punycode form. Verify: the substituted characters are identified.
2. Check your anti-phishing policy for Unicode or impersonation controls and whether your own domains and brands are listed as protected. Verify: the relevant control state is known.
3. Enable confusable-domain detection or, where unavailable, add a transport rule that flags mixed-script and punycode sender domains for review. Verify: the control exists and is scoped to inbound external mail.
4. Search recent mail for other messages from the same or similar encoded domains and quarantine matches. Verify: the sweep finds and holds any siblings.
5. Test by sending from a controlled lookalike domain you register for testing, or use the platform test tools. Verify: the test spoof is flagged with an impersonation warning.

## Variant phrasings
### homoglyph punycode domain impersonation detection
The detection variant.
### mixed script domain spoof mail filter bypass
The script-mixing variant.

Compatibility: Defender impersonation protection, gateway Unicode confusable checks based on Unicode confusables data.

## Why it happens
Human eyes read shapes; filters read code points. Internationalised domain names make the two diverge, and attackers register the visual twin of a brand in a different script block, which string matching alone will never equate with the real brand.

## Edge cases / pitfalls
- Legitimate international senders do use IDN domains. Flag and review rather than hard-block all punycode mail.
- Protect both directions: your users receiving spoofs of partners, and your brand being spoofed to others, which DMARC cannot stop when the domain is genuinely different.
- Screenshots in user reports hide the encoding. Always triage from headers.

## Provenance

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