How do bad HTML practices trigger filters?

Spam filters don't just read your words. They also read your code. And if your HTML looks broken, overly complex, or suspicious, that's a signal something's off, whether it's sloppiness or an attempt to game the system.

Here's what actually triggers filters, in rough order of severity:

Hidden text. White text on a white background, font-size:0, or display:none used to hide content is one of the oldest spam tricks in the book. Filters know it. If your visible message says "Monthly newsletter" but invisible text is stuffed with keywords, that mismatch is caught immediately.

Embedded scripts. JavaScript has no legitimate place in email. It's a security risk, and every major filter treats its presence as a red flag. It usually gets stripped before delivery, but the damage to your score is already done.

Broken or malformed tags. Unclosed tags, nested elements that don't make sense, and messy structural HTML suggest the email was generated carelessly or deliberately obfuscated. Filters score this poorly because spammers often produce exactly this kind of code to confuse parsers.

External resources from suspicious domains. If your email loads images or assets from a domain with a bad reputation, you inherit that reputation. One dodgy tracking pixel can tank an otherwise clean send.

Excessive table nesting. Some nesting is unavoidable for responsive design. But extreme nesting with no clear purpose reads like obfuscation, which filters treat similarly to deliberately broken code.

It's worth noting there's a difference between code that breaks rendering in a specific client (an Outlook quirk, say) versus code that actively triggers spam scoring. Rendering bugs are annoying but mostly harmless to deliverability. Hidden text and scripts are a different category entirely. They're not rendering bugs. They're active spam signals.

The practical fix is straightforward. Use a tested template from your ESP rather than pasting in code from Word or a PDF converter (both produce spectacularly bad HTML). Keep your structure clean. Avoid inline scripts entirely. And before you send anything important, run it through a spam checker to catch issues you might have missed.

Now if you want a quick look at how your email's source reads, try our free Source Analyzer. It'll flag the obvious problems without you having to squint at raw code.