Transactional Email API sends follow different send-attempt rules from standard marketing emails. This is why a transactional email can be attempted even when the customer has email_invalid = true.
The key difference
The Transactional Email API does not follow the standard bounce management rules used for standard marketing email campaigns. Instead, it generally attempts to send the email unless one of the following conditions prevents the attempt:
The email address fails basic syntax validation.
The email is suppressed on the ESP level.
The global suppression list blocks the email address.
The difference stems from the API's sending rules, not necessarily from a change to the customer's email data.
The email_invalid paradox
For Transactional Email API sends, the API ignores the email_invalid customer attribute. Therefore, the value email_invalid = true does not by itself stop the API from attempting to send the email.
The API instead relies on the checks described above: basic email syntax validation and the global suppression list.
Possible delivery mismatch
Since transactional emails are sent via the Transactional Email API, they follow different rules; the same customer could receive transactional email but not marketing campaign emails. In particular, an email_invalid value that would be relevant when reviewing a customer email does not prevent a Transactional Email API send attempt.
Summary
A transactional email can be sent even when email_invalid = true because the Transactional Email API ignores that attribute. For these sends, the API generally attempts delivery unless the address fails basic syntax validation, is suppressed on the ESP level, or is blocked by the global suppression list. This is why transactional email results can differ from those of standard marketing email.