mail filter failed to catch homoglyph domain spoof

Not specified by the original author.

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.

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

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

Thread query: mail filter failed to catch homoglyph domain spoof

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.