A recipient opening the email saw an ordinary subject line: “Your Password is About to Expire.” Nothing about it looked unusual. But when Jan Kopriva at the SANS Internet Storm Center pulled the raw headers apart, the subject was not one clean phrase. It was a chain of MIME encoded words, each Base64-decoded fragment separated by an invisible Unicode character, the soft hyphen, U+00AD, inserted between nearly every letter. No mail client ever rendered those characters. No recipient ever noticed a gap. And no keyword filter scanning for phrases like “password expire” or “account update” ever matched the string either, because at the byte level, the word “password” was not there anymore.
How a Line-Break Hint From the 1990s Became a Filter Bypass
The soft hyphen was never designed for this. It exists in Unicode as a formatting hint, a marker that tells a renderer where a word may break across a line if space runs out, and it is meant to stay invisible everywhere else. RFC 2047 gives email a related mechanism, the encoded word, which lets a subject line carry non-ASCII or specially encoded text wrapped in a syntax like =?charset?encoding?text?=. Mail clients decode this transparently before display, which is exactly why it makes such a convenient hiding place. The campaign Kopriva documented split an ordinary subject line into multiple encoded words, wove soft hyphens between the letters, and Base64-encoded the entire string. A mail client decodes it, drops the invisible characters, and shows the recipient clean, readable text. A filter that pattern-matches against the same decoded string sees something closer to “password,” broken into fragments a keyword rule was never written to catch.
Why DMARC Was Never Going to Stop This, and What That Says About the Layer Underneath It
DMARC, SPF, and DKIM authenticate one thing: whether the domain claiming to send a message actually has the authority to send as that domain. They say nothing about what the subject line or body contains. Content-based filtering, the keyword and phrase matching that flags “urgent,” “verify your account,” or “password expires,” has always been a separate layer, bolted on top of authentication by the mailbox provider or a security gateway. This technique does not touch the authentication layer at all. A message using it can come from a domain with a clean, enforced DMARC record, pass every authentication check cleanly, and still carry a subject line engineered from the ground up to dodge the exact phrase-matching rules a security team spent years tuning.
The Same Weak Spot Deliverability Teams Have Been Living With All Along
Keyword and phrase scoring is not exclusive to security gateways. Every major mailbox provider’s spam filter still weighs subject line language as one signal among many when deciding where a message lands, and every commercial ESP tells its customers to avoid spammy phrases for the same reason. What Kopriva’s find really demonstrates is how brittle that entire category of filtering has become: a five-minute encoding trick defeats it completely, whether the string being disguised is a phishing lure or, hypothetically, a promotional phrase a less scrupulous sender wanted to sneak past a spam folder classifier. That second scenario is not hypothetical enough to ignore. Regulators have spent this year producing multi-million dollar settlements, Costco at fourteen million dollars, Lululemon at close to seven hundred thousand, over subject lines that were merely misleading, not technically altered with hidden characters. CAN-SPAM already treats deceptive email headers as a violation carrying civil penalties up to $53,088 per message. A sender who used invisible characters to manipulate how a subject line is read by automated systems would be building a header deception claim against themselves in the exact way regulators have shown they are willing to prosecute.
What This Means for Your Program
Decode before you filter. Any content rule, security or spam, that pattern-matches against a raw or partially decoded subject line will miss encoded-word tricks entirely. MIME decoding needs to happen before phrase matching runs, not after.
Treat invisible characters as a signal on their own. An unusual density of soft hyphens, zero-width spaces, zero-width joiners, or word joiners inside a subject line is suspicious regardless of what phrase they are hiding. That ratio is worth flagging by itself.
Stop treating keyword filtering as a primary control. It has always been the easiest layer to defeat, and this is proof of exactly how easily. Pair it with authentication, sender reputation, and behavioral signals rather than leaning on it alone.
Audit your own outbound tooling for accidental invisible characters. Design tools, template builders, and copy-paste from rich text editors can leave zero-width or formatting characters embedded in subject lines without anyone intending it. To a receiving filter, an accidental one looks identical to a deliberate one, and either can tank inbox placement.
The Takeaway
The technique itself is small, one Unicode character, one old RFC, one Base64 wrapper. What it exposes is larger: keyword-based content filtering, the layer sitting on top of DMARC rather than inside it, is far easier to defeat than most security and deliverability programs assume. DMARC will keep telling you whether a domain had the right to send. It was never going to tell you whether the words inside the message meant what they appeared to mean, and this is a clean demonstration of just how much distance still sits between those two questions.
Authentication answers who is allowed to send. It cannot tell you what a filter actually saw once your message decoded. Excello Mail turns your DMARC aggregate reports into a clear, ongoing record of every service sending as your domain, authenticated or not, so the parts of your program that are within your control stay visible. Sign up for free to Excello Mail and build the layer of visibility a keyword filter was never going to give you.