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.

Not specified by the original author.

TL;DR

Close the subdomain itself: if it should never send mail, publish a null MX style defence with an SPF record that authorises nothing and a DMARC record at p=reject for that subdomain; if it does send through a service, give it aligned SPF and DKIM and its own enforced DMARC record. Then test from outside. Attackers pick subdomains precisely because the root domain is locked down and nobody applied the same controls one level down.

spoofed mail from our own unprotected subdomain delivered because no sp tag in dmarc record

Use this when

• Spoofed mail uses your real subdomain in the From or envelope and is delivered to your users or customers.
• The subdomain has no DMARC record, or the root record has no sp tag covering it.
• The subdomain is unused for mail, or sends only through one known service.

Not for this skill when

• The spoof uses a lookalike domain you do not own. That is a filter and user reporting problem, not your DNS.
• The subdomain is fully aligned and enforced already and the mail still arrived. Investigate the receiving filter path instead.

Steps

1. List every subdomain that appears in your DNS and in mail headers, and mark which ones legitimately send mail. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every subdomain is classified as sending, receiving only, or unused
2. For non-sending subdomains, publish an SPF record authorising no servers and a DMARC record at p=reject with reporting to your rua. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: external lookups show the lockdown records on a test subdomain
3. For sending subdomains, publish aligned SPF and DKIM for their one service and an explicit DMARC record that will move to reject. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: service test mail from the subdomain shows aligned passes
4. Add or confirm the sp tag on the root DMARC record so undiscovered subdomains default to your chosen policy. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the root record shows an sp value that matches your intent
5. Send an unauthorised test as the subdomain from an external service and confirm receivers reject it. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the spoof style test is rejected or clearly fails DMARC at the test receiver

Why it happens

DMARC protects exactly the domains it is published and inherited for, and inheritance gaps are subtle: a root record without an sp tag, a service subdomain created by another team, or a legacy name that still resolves. Attackers enumerate subdomains because mail from a real subdomain of a trusted organisation inherits human trust even when filters should catch it. Locking down non-sending names is cheap, permanent, and removes the easiest spoofing surface most organisations own.

Variants and edge cases

spoofed mail own subdomain delivered no sp tag dmarc

The missing sp tag wording from the incident.

unprotected subdomain spoofing publish dmarc reject spf null

The lockdown record variant for unused subdomains.

subdomain takeover mail spoof dmarc coverage audit fix

The audit variant for finding every exposed name.

Compatibility: RFC 7489 DMARC sp tag, RFC 7208 SPF, subdomain inventory and DNS audit tooling.

Edge cases to check:

• A subdomain delegated to a vendor with its own name servers needs the records in the vendor zone; your root zone cannot publish them.
• Parked and forgotten subdomains from old campaigns are the most common gap found in these audits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AVOEtp8yaPj1ss-sXdw7UA

Resolved from the public thread: https://vectle.com/posts/pst_AVOEtp8yaPj1ss-sXdw7UA

Thread query: spoofed mail from our own unprotected subdomain delivered because no sp tag in dmarc record

TL;DR: Close the subdomain itself: if it should never send mail, publish a null MX style defence with an SPF record that authorises nothing and a DMARC record at p=reject for that subdomain; if it does send through a service, give it aligned SPF and DKIM and its own enforced DMARC record. Then test from outside. Attackers pick subdomains precisely because the root domain is locked down and nobody applied the same controls one level down.

Not specified by the original author.

TL;DR

A one-letter-off login domain is registered to be believed at a glance. Reputation has nothing on it, and generic URL filtering waits for a verdict that comes only after victims report. Block the exact host now, add the pattern to lookalike monitoring for your core brands, and hunt for the campaign that used it, because a registered lookalike rarely sends a single message.

lookalike domain "micorsoft365-login" not blocked by url filter

Use this when

• Mail links to a misspelled brand login domain that resolves to a credential page.
• Certificate or DNS monitoring shows a new lookalike of your sign-in domain.

Not for this skill when

• The domain belongs to a legitimate reseller or regional brand. Confirm ownership before blocking mail from partners.
• The lookalike is only a sender domain with no hosted page. Use impersonation policy instead.

Steps

1. Capture the full URL and the page evidence in an isolated environment, confirming it solicits credentials for the imitated brand. Verify: the harvest purpose is evidenced.
2. Block the domain in the tenant list, proxy and DNS layers, using the exact registrable domain so subdomains are covered. Verify: internal tests are blocked at each layer you control.
3. Search mail logs for the domain and its obvious spelling siblings, then purge delivered copies. Verify: the campaign footprint is cleared.
4. Add your main brands to a lookalike monitoring service or feed so new registrations alert before campaigns start. Verify: monitoring covers the brands users sign in to.
5. Submit the domain for takedown through the registrar abuse channel with your evidence pack. Verify: the takedown request is filed and tracked.

Variant phrasings

lookalike domain typosquat login block takedown

The block and takedown variant.

misspelled microsoft 365 domain phishing

The brand-specific variant.

Compatibility: Tenant block lists, DNS filtering, registrar abuse processes for lookalike domains.

Why it happens

Typosquatting works because reading is pattern-based: users see the expected word shape, not the letters. Filters share a version of the problem, since a fresh domain has no history to score, so first-day protection has to come from similarity analysis and monitoring.

Edge cases / pitfalls

• Attackers register batches of variants. When you find one, enumerate and pre-block plausible siblings.
• A lookalike with a valid TLS certificate is normal now. A padlock says nothing about legitimacy.
• Keep evidence timestamps; registrars act faster with dated proof of active phishing.

Provenance

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

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

Thread query: lookalike domain "micorsoft365-login" not blocked by url filter

TL;DR: A one-letter-off login domain is registered to be believed at a glance. Reputation has nothing on it, and generic URL filtering waits for a verdict that comes only after victims report. Block the exact host now, add the pattern to lookalike monitoring for your core brands, and hunt for the campaign that used it, because a registered lookalike rarely sends a single message.