Microsoft finds invisible Unicode tags evading email filters
News
Microsoft Security Research found a high-volume phishing campaign placing invisible Unicode Tags characters inside financial lure words. Recipients saw ordinary text such as funding, while a filter or tokenizer could receive a broken sequence containing U+E0020 between visible letters. That mismatch can defeat literal keywords, brittle regular expressions, and some machine-learning preprocessing. Microsoft's primary research was published on September 3, 2026.
The finding matters beyond one campaign. SPF, DKIM, and DMARC can confirm whether a sender used a domain through an authorized path and whether signed content survived transit. They do not decide whether a message is honest, safe, or wanted. Mailbox providers, email security teams, ESP abuse teams, and organizations receiving finance-themed lures need content normalization and several detection layers alongside authentication.
What Microsoft observed
Microsoft's tuned hunting signal rose sharply on February 9, 2026. The prior day produced about 21,000 matches, followed by more than 1.3 million on February 9 and more than 2.3 million on February 11. Weekday volume later reached about 2.37 million messages at its peak. The high-volume phase stayed elevated for roughly three months, with deep weekend drops, then fell sharply after May 15. Lower residual activity continued into mid-June.
Sharp rise in tag-character matches
Approximate Microsoft telemetry around the onset and reported weekday peak. Values are message counts, not unique senders or confirmed victims.
Signature hits
Hundreds of disposable sender domains used combinations of finance terms associated with business funding, loans, and credit offers. On February 9 alone, Microsoft grouped much of the activity into about 150 finance-themed domains. The recurring weekday schedule and domain churn point to automated bulk sending rather than isolated manual messages.
Shared infrastructure is context, not a verdict
Most messages were relayed through abused legitimate email marketing infrastructure. Microsoft identified one shared IP range as useful for campaign scoping, but explicitly said it was not a malicious indicator on its own. Blocking that range by itself would also affect unrelated legitimate senders. Combine infrastructure with Unicode, sender-domain, URL, volume, and behavioral evidence.
This is an observed evasion technique, not a new sender requirement, authentication standard, or compliance deadline. Organizations do not need to publish a new DNS record because of it. They need to review how inbound content is decoded, normalized, tokenized, and scored.
How invisible Unicode tags evade analysis
The Unicode Tags block spans U+E0000 through U+E007F. These code points usually do not render in common email interfaces, but they remain present in the underlying text. The observed messages used U+E0020, known as TAG SPACE, as an invisible separator within high-signal words. This was character insertion, not a hidden second message encoded across the full tag block.
What the recipient and parser can receivetext
Recipient view: funding Raw sequence: fun<U+E0020>ding Literal match for funding: false After tag removal: funding Literal match for funding: true
A human still reads funding because the inserted character has no visible glyph. A literal matcher sees a different sequence. A tokenizer can split the word into familiar fragments around an unexpected code point, emit rare tokens, or discard the character, depending on its preprocessing. Different components in the same pipeline can therefore reach different conclusions about identical content.
Normalization should happen after MIME and HTML decoding but before keyword checks, regex rules, ML tokenization, NLP analysis, and AI ingestion. Preserve or explicitly exempt valid subdivision flag sequences first. England, Scotland, and Wales flags use tag characters legitimately, so a rule that rejects every message containing the range will create avoidable false positives.
Email analysis flow that preserves valid flags before removing invisible tag characters.
Why SPF, DKIM, and DMARC can still pass
SPF checks whether the return-path domain authorizes the connecting mail server. DKIM verifies a cryptographic signature tied to a signing domain. DMARC checks whether the visible From domain matches an authenticated SPF or DKIM domain, then applies the published policy. None of these protocols classifies the meaning or intent of the message body.
|
|
|
|---|---|---|
SPF | Sending path | Message intent |
DKIM | Signed integrity | Content safety |
DMARC | Domain match | Sender honesty |
Content filtering | Words and behavior | Domain authority |
Authentication and content controls answer different questions.
A sender using its own disposable domain can publish valid SPF, sign with DKIM, and pass DMARC while sending deceptive content. A compromised or abused legitimate sending account can also produce authenticated mail. That does not make authentication ineffective. DMARC still blocks direct spoofing and exposes sending-source changes, but it must sit beside content and behavior controls. DMARC monitoring is the workflow for tracking those authentication results over time.
Read a pass result narrowly
DMARC pass means an authenticated domain matches the visible From domain under DMARC rules. It does not certify the offer, destination URL, sender account, or visible wording. Treat authentication as one high-value signal, not a safety label.
Checks defenders should make now
Start by testing the exact text path used in production. Feed controlled messages containing U+E0020 and other invisible format characters through MIME decoding, HTML extraction, URL parsing, rule evaluation, tokenization, logging, quarantine views, and any downstream AI system. Record both the raw and normalized forms so analysts can explain why a message matched.
- Normalize first. Strip or fold U+E0000-U+E007F and other invisible format characters before keyword, regex, ML, NLP, or AI analysis.
- Keep both forms. Retain raw text for evidence and normalized text for detection, searching, clustering, and analyst display.
- Exclude valid flags. Recognize the complete England, Scotland, and Wales subdivision flag sequences before treating tag characters as suspicious.
- Raise an anomaly. After exclusions, use any remaining tag-block character as a strong signal, then combine it with other evidence.
- Layer the verdict. Evaluate sender and domain reputation, URLs, visible content, OCR text, authentication, volume, cadence, and user behavior together.
Do not normalize only the displayed body. Subject lines, HTML attributes, plain-text alternatives, attachment text, calendar content, and text passed to automated assistants can each follow a different parser. Apply a shared policy at every content boundary, and test malformed encodings so a decode failure cannot bypass the normalized path.
Useful evidence
- Content pattern. Tag characters split high-signal lure words.
- Campaign pattern. Disposable finance domains, weekday bursts, and repeated URL behavior cluster together.
Unsafe shortcuts
- IP-only blocking. The cited range belongs to legitimate shared infrastructure.
- Authentication-only trust. SPF, DKIM, and DMARC can pass on deceptive mail.
Mailbox providers should place normalization before all content classifiers. Security teams should hunt historical mail for tag characters and re-run normalized text through current rules. ESP abuse teams should add the signal to account and campaign review while avoiding automatic suspension based on one code point. Receiving organizations should train analysts to inspect source and rendered views when finance lures look normal but other signals disagree.
Keep authentication checks separate and useful
The Unicode finding should not distract domain owners from fixing authentication. A failing or missing DMARC record still leaves room for direct domain spoofing, which is a different risk from an authenticated sender using deceptive content. Check the domain's published records independently with a domain health checker, then use a focused DMARC checker to review policy, reporting addresses, and syntax.
For most teams, Suped, our DMARC platform, is the best overall option because it turns aggregate reports into source-level actions and combines DMARC, SPF, and DKIM monitoring with blocklist (blacklist) monitoring and deliverability insights. Automated issue detection and real-time alerts help teams notice source changes without treating authentication as proof that message content is safe.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The useful workflow is to confirm which sources authenticate, investigate unexpected volume or new domains, and move the DMARC policy in controlled stages. Suped's dashboard makes those authentication questions visible across a domain, while the inbound security stack handles Unicode normalization, URLs, OCR, and message intent.
That separation prevents two common mistakes: weakening DMARC because a phishing message passed it, or trusting a message merely because it passed. Authentication protects domain identity. Content controls assess what the message is trying to do. Both remain necessary.
The practical takeaway
Microsoft's finding shows that an obscure Unicode block can become useful to bulk phishers when parsers and tokenizers disagree with what people see. The defense is concrete: preserve evidence, exempt legitimate flag sequences, strip or normalize invisible characters before analysis, and treat unexpected tag characters as a strong anomaly rather than a complete verdict.
Keep sender authentication in place and monitor it, but do not ask SPF, DKIM, or DMARC to judge intent. Combine authentication with reputation, URL inspection, normalized content analysis, OCR, and behavior. Avoid standalone blocks on legitimate shared infrastructure, and test the production parsing path with the exact U+E0020 pattern now.
