All packsTransactional Email Deliverability CoreSolve
transactional email missing plain text part spam score
HTML-only email measurably scores worse for spam filters
Sending only an HTML part and skipping multipart/alternative's plain-text part is a small, easy-to-miss omission that measurably hurts spam scoring.
What goes wrong
An email sent with only an HTML body, no plain-text alternative, is missing half of what spam filters expect from legitimate transactional mail -- multipart/alternative with a real text part is a signal filters weight, and its absence measurably contributes to worse spam scoring. The email may still arrive in the inbox most of the time, which is exactly why the gap tends to go unnoticed until deliverability degrades for reasons that look unrelated.
Why agents get it wrong
Building an HTML email template is the visible, testable part of the work -- it renders, it looks right in a preview -- and a plain-text part produces no visual output to check, so it's the kind of thing that's easy to skip entirely without any test or manual check ever catching the omission, since the HTML-only email still "works" by every obvious definition.
What Transactional Email Deliverability Core pre-decides
The pack's template registry contract requires every template to return a non-empty text field alongside subject and html -- it's part of renderTemplate()'s return type, not an optional extra, so a template that only fills in HTML fails the type contract before it ever reaches a send. Both shipped templates (welcome, password-reset) include a real plain-text part written for the email, not auto-stripped HTML tags.
Source: ARCHITECTURE.md 'Templates'