What does the SpamAssassin rule FONT_INVIS_MSGID test for?
Updated on 7 Aug 2026: We corrected the rule mechanics and expanded the troubleshooting advice for current SpamAssassin scoring.
The FONT_INVIS_MSGID rule correlates font-hidden HTML with a host-shaped Message-ID suffix, then applies exceptions for several normal mail-path clues. SpamAssassin publishes the short description Invisible text plus suspicious message ID, but the underlying test does not simply declare a Message-ID invalid or compare its domain with the From address.
Treat the result as a correlation warning. The body contains HTML that matched the tiny-font or transparent-color test, the Message-ID matched an internal host-pattern helper, and none of the rule's listed exceptions suppressed the hit. A normal-looking Message-ID can therefore appear in a message that triggers the rule.
What FONT_INVIS_MSGID tests for
In current SpamAssassin rule logic, FONT_INVIS_MSGID is a meta rule. One subtest scans raw HTML for matched font-hiding patterns. Another helper, __MSGID_OK_HOST, checks whether the Message-ID ends with a host-like value. The final expression then excludes messages with specified relay, header, or MIME clues. The public rule descriptions use the compressed label, so troubleshooting requires the installed rule expression.
- Hidden HTML: The raw-body test matches text immediately after tags styled with specified zero-like or one-unit font sizes, or transparent color.
- Message-ID shape: The internal helper matches an ID ending in a host-like nonnumeric string or an IPv4 address before the closing bracket.
- Benign exceptions: Relay naming, Errors-To, mail links, quoted-printable MIME, campaign IDs, thread indexes, and other clues can suppress the published hit.
- Score impact: Current upstream score sets place the rule roughly between 1.7 and 2.5 points, but the installed version and local configuration control the actual value.
Current rule logic, condensedtext
__FONT_INVIS_MSGID = __FONT_INVIS && __MSGID_OK_HOST FONT_INVIS_MSGID = __FONT_INVIS_MSGID && !__RCD_RDNS_MX_MESSY && !__RCD_RDNS_MX && !__HAS_ERRORS_TO && !__RCD_RDNS_MAIL && !__MAIL_LINK && !__HDR_RCVD_AMAZON && !__MIME_QP && !__HAS_CAMPAIGNID && !__HAS_THREAD_INDEX && !__RCD_RDNS_MTA
Do not assume the Message-ID is malformed
The helper name __MSGID_OK_HOST matters. A hit does not prove that the ID is invalid, reused, or misaligned with the sender. Inspect the matched HTML first, then validate the Message-ID separately if the raw header shows a real syntax or generation problem.
Score displays also differ. SpamAssassin normally adds a positive spam score, while some testing interfaces show the same penalty as points deducted from a deliverability total. For a wider explanation of how tests add up, the related page on SpamAssassin rule impact helps when one rule does not explain the final result.
Why invisible text matters
Hidden text has a long spam-filter history because it can feed words to filters without showing those words to the reader. Senders have used it for neutral terms, keyword stuffing, random words, or copied article fragments intended to change token analysis. Legitimate templates can trigger the same pattern by accident, especially when email builders create tiny preheader text or leave transparent formatting behind.
Infographic showing hidden HTML plus Message-ID context causing a rule hit.
Common legitimate causes
- Preheader text: A preview line styled with a one-pixel font or transparent color by the template builder.
- Responsive blocks: Mobile or desktop variants that combine display rules with tiny-font or transparent fallback styling.
- Editor residue: Copied content that leaves transparent spans, empty font tags, or tiny fallback text.
- Generated fields: Merge values placed inside near-zero text by a template component during the final send.
Patterns to remove
- Keyword stuffing: Terms hidden in one-pixel text to influence filters or previews.
- Transparent copy: Text assigned a transparent color rather than presented to the reader.
- Long hidden blocks: Large content sections hidden instead of removed from the final send.
- Mismatched previews: Preview text that says something materially different from the visible email.
Risky HTML patternhtml
<span style='font-size:0px;color:transparent'>bonus offer terms</span> <span style='font-size:1px'>extra words not shown to readers</span>
Remove hidden filler and keep preheader text short. A hidden preview line can be legitimate, but its generated HTML still needs testing. If it causes the hit, shorten it or change the template markup, then retest the final message before rewriting the whole email.
How to read the Message-ID signal
The Message-ID header is a unique identifier for a message. In this rule, the helper checks only for a host-shaped ending. It does not compare the Message-ID host with the From domain, DKIM signing domain, or Received path. Those comparisons can reveal separate sender problems, but they are not the positive Message-ID predicate in FONT_INVIS_MSGID.
|
|
|
|---|---|---|
Message-ID | Host-like suffix | Fix only actual defects |
HTML | Tiny or transparent font | Remove matched text |
Received | Preserved relay clues | Test full raw source |
MIME and headers | Rule exceptions | Do not manufacture clues |
Score | Installed rule set | Check local configuration |
Checks that separate the rule hit from other header problems.
Evidence to preserve from the raw messagetext
Message-ID: <unique-token@mail.example.com> Received: from mail.example.com by mx.recipient.net Content-Transfer-Encoding: quoted-printable X-Campaign-ID: campaign-123
A normal Message-ID can still be present
A public false positive report reinforces the need to verify the raw message and installed rule file before changing sender infrastructure. The published label alone does not identify which header detail mattered.
A missing or malformed Message-ID is a different failure mode. The related Message-ID bounce page covers that case. For FONT_INVIS_MSGID, begin with the matched body rule and the exact local meta expression.
How to debug the hit
Keep the process mechanical. Prove which generated HTML triggered the body subtest, confirm the exact rule version, then make the smallest change that removes the signal without damaging the campaign or transactional message.
Apache SpamAssassin command-line report showing FONT_INVIS_MSGID in the rule list.
- Save the raw source: Export the full MIME source before a template builder or mailbox view changes the HTML.
- Search matched font styles: Look for font or font-size values near zero and for color set to transparent.
- Check the local rule: Record the SpamAssassin version, active rule file, score set, and any administrator overrides.
- Isolate generated blocks: Duplicate the message and remove the preheader or one template block per test until the hit disappears.
- Compare relevant headers: Preserve Message-ID, Received, transfer encoding, campaign fields, and thread fields when comparing tests.
- Retest the final send: Use the production sender because builders can alter HTML and headers at send time.
- Review the total score: Fix the highest-confidence causes and keep enough margin below the recipient's configured threshold.
A live send is more representative than pasted HTML because the sending system generates the final MIME source and headers. Suped's email tester supports that workflow: send the real message, inspect the rendered result, and review authentication alongside the content findings.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After each retest, check whether the rule disappeared and whether the total score has a safe margin. Do not treat a changed score as proof unless the same SpamAssassin version and configuration processed both samples.
If the rule remains after editing the visible template, search the production-generated source again. A builder can inject preheader markup or tiny fallback text during sending. Change the Message-ID only when a separate header check confirms that its syntax, uniqueness, or generation is actually defective.
Email tester sample report showing total score, email preview, issue summary, and per-section results
What to change in the email
The right fix depends on the evidence in the raw message. Do not suppress the rule or add a scoring override for outbound mail. A receiving administrator can consider a local override after documenting repeated false positives, but senders should remove the matched HTML and correct any independently verified header defect.
Template fixes
- Remove hidden filler: Delete invisible words that do not help the recipient understand the email.
- Shorten preheaders: Use one concise preview line that matches the visible body, then test its generated markup.
- Clean copied HTML: Strip transparent spans, empty font tags, and old editor styling.
- Avoid split meaning: Do not hide claims, legal qualifiers, or keyword blocks away from readers.
Header checks
- Validate the ID: Confirm syntax and uniqueness without assuming this rule proves a defect.
- Preserve raw headers: Test the complete Received path and MIME fields produced during the real send.
- Check local rules: Use the receiver's active expression and score rather than a generic rule description.
- Avoid fake exceptions: Do not add campaign or thread headers solely to bypass the meta rule.
Message-ID hygienetext
Good: unique-token@mail.example.com Good: campaign-id.unique-token@mailer.example.com Risky: reused-token@staging.local Risky: copied-id@example.test
Message-ID hygiene still matters, but it is separate from the fastest fix for this rule. Use predictable generation and a unique value for each message, while removing hidden content that matched the body test.
Where authentication and reputation fit
SPF, DKIM, and DMARC are not predicates in the published FONT_INVIS_MSGID expression. Passing authentication does not suppress the rule, and failing authentication does not create the hidden-font match. Authentication failures, blocklist listings, or blacklist history can still affect the recipient's wider delivery decision. That is why blocklist monitoring belongs in a separate operational review.
Suped's DMARC platform supports that broader workflow through authentication reporting, hosted DNS controls, blocklist monitoring, alerts, and deliverability context. It does not rewrite the email template or alter a receiver's SpamAssassin rules. It helps separate an isolated content hit from concurrent domain or reputation problems.
Suped workflow for this issue
- Send a real sample: Use the final sender path so the HTML and headers match production.
- Check the domain: Use the domain health checker to review separate DNS and authentication issues.
- Fix the direct cause: Remove matched hidden text before addressing unrelated domain findings.
- Watch for recurrence: Use alerts and reporting so sender or domain problems do not return unnoticed.
Fix the template signal first because it is the direct positive body test. Then resolve separate authentication, DNS, blocklist, blacklist, or reputation findings according to their evidence and impact.
Views from the trenches
Best practices
Check raw HTML and headers together before changing templates or sender settings in production.
Keep hidden preheader copy short, human-readable, and consistent with visible content.
Record the full rule set version when comparing spam tests across different systems.
Common pitfalls
Treating a syntactically valid Message-ID as proof the header cannot affect the rule.
Removing tracking pixels while leaving transparent keyword text inside the HTML template.
Testing only one recipient mailbox and assuming every SpamAssassin install scores the same.
Expert tips
Save the original MIME source before editing, so every retest has a clear baseline.
Compare the active meta expression with the raw HTML before diagnosing sender alignment.
Use a real campaign sample, because builders often alter HTML during final sending.
A marketer from Email Geeks recommends checking generated preheader HTML before changing sender infrastructure.
2021-03-16 - Email Geeks
A marketer from Email Geeks notes that public rule descriptions can lag behind live rule logic.
2021-03-16 - Email Geeks
The practical takeaway
Treat FONT_INVIS_MSGID as a meta-rule warning. SpamAssassin found font-hidden HTML, a Message-ID with the host shape expected by its helper, and none of the listed suppressing clues. The fastest fix is usually to remove or restyle the tiny or transparent text in the final generated HTML.
Do not infer a malformed or misaligned Message-ID from the label alone. Save the raw message, verify the installed rule, change one template element, and send a production-path retest. Correct the Message-ID only when a separate check finds an actual defect.
