The question of whether commented code in emails affects spam filters and deliverability is a nuanced one. While some believe that any unnecessary code, including comments, can lead to increased email size and potential flagging by spam filters, others argue that modern spam filters are sophisticated enough to disregard benign comments. The impact often depends on the type and quantity of comments, as well as the overall sender reputation and content quality of the email.
Key findings
Code bloat: Excessive commented code can increase email file size, which might negatively impact deliverability, though this is less of a concern for small, clean comments.
Gibberish content: Spammers sometimes hide irrelevant or malicious text within comments to bypass content filters. If comments contain what appears to be gibberish or suspicious keywords, filters may flag the email. This is why proper email content is crucial for deliverability.
Filter sophistication: Modern spam filters, particularly those employing Bayesian filtering, are generally capable of stripping out HTML comments before analyzing content, reducing their impact.
Sender reputation: Ultimately, your sender reputation and engagement metrics play a much larger role in inbox placement than minor code elements like comments. A strong reputation can often override small technical imperfections.
Key considerations
Minimalism: It is generally a good practice to keep email code as lean as possible. This means minimizing comments in production emails.
Purpose of comments: While comments are useful for development (e.g., locating dynamic calls), they are not necessary for the end-user experience.
Client requirements: For clients, especially in sensitive industries like finance, adhering to strict audit suggestions, such as removing commented code, can mitigate perceived liability risks and align with internal security policies.
Testing: If concerns arise, conduct A/B tests with and without comments to observe any measurable impact on inbox placement. Regular deliverability testing helps identify potential issues.
What email marketers say
Email marketers often balance the need for clear, maintainable code with deliverability concerns. Many advocate for stripping comments from production emails to reduce bloat and eliminate any potential (even if minor) risk of triggering spam filters. However, some acknowledge that for most filters, the presence of simple comments is unlikely to be the primary cause of an email being marked as spam, as sender reputation and content relevance hold more weight.
Key opinions
Bloat concern: Many marketers recommend removing comments, viewing them as unnecessary code bloat that can increase email size and potentially trigger spam filters.
Hidden content risk: Marketers are aware that spammers use hidden text (e.g., via low contrast colors or comments) to evade filters, making any hidden code a potential flag. This is similar to how new email templates might sometimes affect deliverability if not properly tested.
Primary factors: A common sentiment is that overall sender reputation, historical engagement, and relevant content are far more impactful on deliverability than the presence of minor commented code.
Industry specifics: In highly regulated or sensitive industries like finance, even minor code elements can be scrutinized due to potential liability or phishing concerns. These sectors often adopt stricter code cleanliness. Marketers also stress the importance of avoiding spam trigger words.
Key considerations
Automated removal: Consider implementing a script or build process to automatically strip comments from email HTML before deployment, allowing developers to retain comments in their source files.
Concise comments: If comments must remain, keep them short and to the point, like <!--terms-->.
Content and segmentation: Focus more on preventing phishing-like copy, ensuring good color contrast (to avoid hidden text), and optimizing segmentation and throttling for deliverability, as these are more critical factors.
Copy review: Be diligent about reviewing email copy, especially for financial content, to ensure it does not resemble nefarious or spammy messaging. This aligns with broader strategies to improve email engagement.
Marketer view
Marketer from Email Geeks notes that using gibberish in comments is a technique some spammers employ to circumvent content filters that scan for specific patterns or signatures.
14 Aug 2018 - Email Geeks
Marketer view
Marketer from Email Geeks suggests that marketers should always remove commented code, emphasizing that emails are not webpages. This extra bloat is unnecessary and can potentially confuse spam filters.
14 Aug 2018 - Email Geeks
What the experts say
Email deliverability experts generally agree that while overly large or malicious comments can be problematic, simple, short comments are unlikely to be a primary spam trigger. They emphasize that robust spam filters analyze content differently than browsers, often stripping out comments or evaluating them based on broader patterns of malicious behavior rather than their mere presence. The focus for deliverability remains on sender reputation, authentication, and user engagement over minor code elements.
Key opinions
Filter processing: Good Bayesian spam filters typically remove HTML comments from consideration when evaluating email content. Therefore, benign comments should not count for or against deliverability.
Bloat (minor impact): While comments add bloat, especially if lengthy, their effect on deliverability is usually negligible compared to other factors. The primary concern is excessive, unnecessary content that increases file size without value.
Historical abuse: Microsoft's Hotmail (now Outlook) has historically been known for sometimes treating text within style tags or other hidden elements as valuable, a tactic spammers used to hide junk text. This might cause some filters to be more sensitive to hidden content.
Reputation is key: Experts consistently point to overall sender reputation, including factors like DMARC, SPF, and DKIM authentication, as the dominant influence on inbox placement, overshadowing minor code details.
Key considerations
Minimal comment length: If comments cannot be omitted, keep their quantity and size to a minimum. Use short, functional comments rather than lengthy instructional ones.
Testing value: While unlikely to be a major factor, testing different approaches to comments (e.g., with and without) can provide data for specific email programs or clients.
Prioritize fundamentals: Focus on foundational deliverability elements, such as maintaining a clean list, avoiding good sender reputation, and ensuring content is relevant and engaging.
Spam filter logic: Understand that content filters are designed to detect malicious patterns and hidden text used for deceptive purposes. Simple HTML comments are generally not part of these patterns unless they contain known spammy keywords or excessive, nonsensical data.
Expert view
Expert from Email Geeks notes that good Bayesian spam filters are designed to extract HTML from value tags, meaning that content placed within comments should ideally not negatively impact or positively influence spam scoring. Anything within the body of three characters or less also typically does not count.
14 Aug 2018 - Email Geeks
Expert view
Expert from Email Geeks agrees that commented code simply adds bloat to the production message. If omitting comments isn't feasible, they advise keeping their quantity and size to a minimum, suggesting short comments like <!-- top --> instead of lengthy instructional ones.
14 Aug 2018 - Email Geeks
What the documentation says
Official documentation and research often focus on specific technical standards and common spamming techniques. While explicit warnings about HTML comments are rare, general guidelines for email design emphasize lean code and avoiding elements that could be exploited for malicious purposes. The underlying principle is that email content should be straightforward and avoid characteristics commonly associated with spam, regardless of whether they are visible to the recipient.
Key findings
Code weight: Documentation often advises keeping email file sizes reasonable. Overly large emails, even if due to seemingly innocuous elements like excessive comments, can raise red flags for spam filters.
HTML vs. Plain Text: Some documentation clarifies that email filters are not designed to flag emails simply for containing a small amount of HTML code. This implies that comments, as part of HTML, would also likely not be flagged on their own merit.
Irrelevant tags: Technical guides often caution against irrelevant or broken HTML tags, as these can disrupt parsing and potentially affect deliverability, which can be extended to poorly structured or excessive comments.
Hidden content detection: While not directly about comments, documentation often describes how spam filters look for hidden text (e.g., matching foreground and background colors) used by spammers. This general vigilance towards obscured content may indirectly apply to comments if they appear suspicious.
Key considerations
Code cleanliness: Adhere to best practices for email HTML, which generally promotes lean and valid code. While comments are valid HTML, their excessive use deviates from a minimal approach.
Minimizing file size: Reducing overall email file size is a recognized deliverability best practice. Removing non-essential elements like comments contributes to this goal, helping to avoid issues described by Email on Acid.
Avoid errors: Ensure that any code, including comments, does not introduce errors that can impact how an email is rendered or interpreted by mail clients and spam filters. Code analysis reports should be reviewed.
Technical article
Documentation from Dyspatch highlights that no email filter will flag an email as spam simply because of a small amount of code. This suggests that the presence of benign comments is unlikely to be a direct spam trigger.
15 Sep 2014 - Dyspatch
Technical article
Documentation from Email on Acid emphasizes that using overly large emails without supporting text can raise a red flag for spam filters. This implies that code bloat, potentially including excessive comments, could contribute to deliverability issues.