Text salting is the practice of padding a phishing email with large amounts of hidden HTML text so automated classifiers read a different message than the recipient. The technique exploits the gap between rendered content and source content, making scoring models easier to dilute without changing what the human sees.
What Text Salting Actually Changes
Text salting is not mainly about changing the visible message. It changes what automated systems see by injecting hidden or low-signal text that can distort parsing, scoring, and classification without altering the human recipient’s experience.
That makes the technique especially useful in phishing and spam workflows where defenders rely on content analysis. The attacker is trying to create a mismatch between rendered content and source content, so the model’s interpretation becomes noisier than the sender’s actual intent.
How the Technique Works in Email Pipelines
Most mail filters inspect message source, not just the text a user sees in a client. Text salting abuses that difference by adding hidden HTML, repeated phrases, or other padding that shifts token frequency, dilutes suspicious terms, or adds unrelated language that confuses scoring logic.
The method is effective when preprocessing is weak or inconsistent. If the filter strips or normalises one set of artefacts differently from the recipient’s mail client, the message can look harmless to the machine while still reading normally to the person.
Why It Matters for Detection and Content Integrity
Text salting matters because it undermines one of the simplest assumptions in email security, that the analysed text and the displayed text are functionally the same. Once that assumption fails, false negatives become more likely, especially in systems that lean heavily on lexical features or naive source inspection.
It also creates a broader integrity problem for triage and investigation. Analysts may need to review both rendered output and raw source to understand why a message was classified, which signals were diluted, and whether the source contains hidden content meant only for machines.
Where Organisations Should Be Careful
The main exposure is not just one malicious message, but repeated adaptation. Once attackers learn what a filter weights, they can tune the hidden text to stay below thresholds or to bury suspicious cues inside noise, making campaign-level detection less reliable over time.
Defenders should treat hidden HTML, unusual text density, zero-width characters, excessive repetition, and rendering-source mismatches as signals worth inspecting. Mail security works best when it compares what is delivered, what is rendered, and what the classifier actually consumed.
Risk and Threat Considerations
Text salting can degrade phishing detection by making malicious email content appear less suspicious to automated classifiers while leaving the user-facing message intact. That creates a practical evasion path, especially where source-level parsing is trusted too heavily.
Failure mechanism: The attacker pads or obscures the source with hidden or irrelevant text so feature extraction, token weighting, or scoring logic is distorted before the message reaches the recipient.
Impact: Higher false negatives, weaker email filtering, and a greater chance that phishing or spam messages reach inboxes and trigger user compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Text salting is a phishing evasion technique. |
| Recommendation — Map salted messages to T1566 and inspect for delivery, source, and lure manipulation. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Salting creates anomalous source-versus-rendered message behavior. |
| Recommendation — Monitor for abnormal HTML structure and content mismatches in email telemetry. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Detection depends on logging what the security parser actually processed. |
| Recommendation — Log parser inputs and classification outputs so hidden-text evasion can be investigated. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Email protections should address malicious message content and filtering evasions. |
| Recommendation — Harden mail filtering and URL inspection to reduce phishing messages that use source padding. | ||
Practitioner Guidance
What to watch for: Treat source-to-rendered mismatches as a review trigger, not an edge case. If a message looks normal when rendered but contains abnormal HTML structure, hidden text, or unusual repetition in the source, inspect it as a potential evasion attempt.
Practitioner note: Content-based email controls are strongest when they are paired with rendering-aware analysis and independent signals such as sender reputation, URL inspection, and attachment scrutiny. No single classifier should be assumed to see the whole message correctly.
Related resources from NHI Mgmt Group
- When do structured questions work better than free text in agentic workflows?
- Why do agentic AI prompts need stronger controls than ordinary text inputs?
- What breaks when prompt injection guardrails only look for obvious malicious text?
- Why do text-only AI assistants fail on presentation-layer attacks?