The Plain-Text Part Nobody Writes
Almost nobody writes the plain-text version of a transactional email, and almost every spam filter notices. This connector builds one from the HTML rather than sending without it — which is three characters of code and a measurable difference in whether the message arrives.
An email is traditionally two documents in one envelope: the formatted version and a plain-text alternative for anything that cannot render it. Almost nothing cannot render it any more, so the plain part looks like a historical curiosity, and most systems stopped producing it. Spam filters did not stop looking, and a message with only one part is a small negative signal that costs nothing to remove.
Why the plain part still matters
Not because anybody reads it. Because of what its absence suggests.
| Reason | What it actually affects |
|---|---|
| Filters treat HTML-only as a weak negative signal | Where the message lands, marginally |
| Some clients and previews prefer the text part | Notification snippets and low-bandwidth readers |
| Screen readers work from cleaner content | Whether the message is usable at all for some recipients |
| Legitimate senders generally produce both | The company your message is keeping |
None of those is decisive on its own. Deliverability is an accumulation of small signals, and the useful mental model is that you are being scored rather than judged. This is one point, it is free, and there is no reason to give it away.
A stripped-down text version is a worse document than a hand-written one and an enormously better one than nothing.
So it is derived
If the message carries a text part, that is used. If it does not, one is produced by stripping the markup out of the HTML.
The result is imperfect in a way worth being honest about. Tables lose their structure. Link text survives and the addresses behind it do not. Spacing is whatever the source happened to have. It is not a document anybody would write.
It is also a real text part containing the actual words of the message — the purchase order number, the supplier, the amount, the date. Somebody reading it in a notification preview gets the substance. Compared with an empty part or no part at all, that is not a close comparison.
The general principle is one worth carrying: where a good default is expensive and a mediocre one is free, produce the mediocre one automatically and let anything that cares supply better. A field left empty because the perfect version was too much work is the worst of the three options.
The sender name, three deep
A smaller example of the same instinct, in the field beside it.
The name a recipient sees is resolved through three levels: the name you configured on the connector, then the name on the message itself, then the product's own. The first one present wins.
And if all three somehow come out empty, the field is dropped from the request entirely rather than sent as an empty string. That is the same distinction the SMS connectors make about a missing sender: an absent key means use your default and an empty value means use this, which is nothing — and providers treat the two differently.
The address, by contrast, is never inherited from the message. It is always the verified sender on your connected account, because a message claiming an address that does not match the account sending it fails the alignment checks receiving servers apply — which is worse than not connecting the account at all.
Omitted rather than empty, again
The same rule runs through the whole conversion, and it is worth seeing collected because it is the single most repeated decision in this connector.
-
No copy recipients, no key
An empty list is left out of the request rather than sent as an empty array. The two are different statements and some providers treat them differently.
-
No blind copies, no key
Same again.
-
No attachments, no key
And an attachment with no content is skipped rather than sent as an empty file, which is the version that produces a mail with a zero-byte document stapled to it.
-
No sender name, no key
Rather than a name that is an empty string, which some clients render as a stray space before the address.
None of these is interesting individually. Together they are what makes a translated request look like one a person wrote for that provider rather than one a machine converted, and that difference shows up as the absence of small oddities nobody would have connected to the conversion.
And a fourth way of saying who you are
A last note, because this connector completes a set.
Across the email providers here there are four distinct authentication arrangements. One uses a key and a secret through its own client library. One uses basic authentication with a fixed literal username. One uses a custom header with no scheme keyword at all. And the mailbox connectors use bearer tokens obtained through consent.
There is no pattern to learn and no convention to assume. Each is read from its provider's documentation and implemented as specified, and every one of the wrong guesses fails as an authentication error that says nothing about which half was wrong. The technique is not cleverness, it is looking it up — once, per provider, before assuming.
What is in place, layer by layer
The Brevo connector as it stands
A plain-text part on every message
Used where the message supplies one and derived from the HTML where it does not, so nothing goes out as a single-part message.
A three-level sender name
Your configured name, then the message's own, then the product's — with the field dropped entirely rather than sent empty.
The sender address always yours
Replaced with your verified address rather than inherited, because a mismatch between the claimed sender and the sending account hurts delivery.
Empty keys omitted throughout
Copy recipients, blind copies, attachments and the sender name are all left out when absent rather than sent as empty values.
Attachments without content skipped
An attachment carrying nothing is dropped rather than sent, so a message never arrives with a zero-byte file attached to it.
The provider's own authentication header
A custom header with no scheme keyword, as specified, rather than the conventional arrangement that would fail as an invalid key.
One message per request, guarded individually
Each message in a body is its own send, so a failure costs itself and every reason is kept.
A verdict with a floor
Success requires at least one message actually sent and no failures, so a body with nothing sendable is reported rather than passing quietly.
Credentials encrypted at rest
Stored on the row for one workspace, never in configuration, and never written into a log line.
The derived text part is a stripped version of the HTML rather than a written one. It loses table structure and link addresses, and it carries the words of the message — which is the comparison that matters.
Three positions held on purpose
- A mediocre automatic default beats an empty field. Where the good version is expensive and a passable one is free, produce the passable one and let anything that cares supply better.
- An absent key and an empty value are different statements, and the difference is honoured everywhere in the conversion. Providers treat them differently, and a converted request full of empty values reads as machine-generated in ways that produce small oddities nobody traces back.
- Each provider's authentication is looked up rather than assumed. There are four arrangements across these connectors and no pattern between them, and every wrong guess fails as an error about the credential rather than about the scheme.
Five questions about transactional email quality
Do your emails carry a plain-text part?
A good answer sounds like
Yes, always.
What ours actually is
Supplied where the message has one, derived from the HTML where it does not.
What name do recipients see?
A good answer sounds like
A resolved chain.
What ours actually is
Your configured name, then the message's, then the product's — and the field is dropped rather than sent empty.
Can the message claim a different sender?
A good answer sounds like
No.
What ours actually is
The address is always your verified sender, because a mismatch fails the checks receiving servers apply.
What happens to an empty attachment?
A good answer sounds like
Skipped.
What ours actually is
Dropped rather than sent, so no message arrives with a zero-byte file attached.
How do you authenticate to this provider?
A good answer sounds like
As documented.
What ours actually is
A custom header with no scheme keyword — one of four different arrangements across these connectors.
Our take
Deliverability is not a feature you build, it is a score you accumulate, and most of the inputs are small things that cost nothing individually. A plain-text alternative. A sender address that matches the sending domain. A reply-to that goes somewhere real. No empty fields, no zero-byte attachments, no claims the envelope cannot support. None of these will get a message into an inbox on their own, and giving away four or five of them for no reason is how a legitimate organisation ends up wondering why its invoices go to spam while nothing in particular seems wrong.
The small things decide where mail lands
A text part, a matching sender, a real reply address. None of them is interesting and together they are most of the difference.
Talk through email deliveryFrequently asked questions
What does the plain-text version of our invoice email look like?
The words of the message with the markup removed. Tables lose their alignment and link addresses are not carried, so it reads as a slightly ragged version of the same content. Almost nobody will see it — its job is to exist, because a message with only an HTML part is a small negative signal to filters.
Can we supply our own text version?
Where a message carries one it is used as given, and the derived version is only produced when there is none. So a template that provides a written text part will send that instead.
Why can the sender address not be the one on the message?
Because receiving servers check that the address a message claims is aligned with the domain that actually sent it. A message routed through your account but claiming a platform address fails that check and lands in spam more reliably than it would have from the platform in the first place.
What happens if an attachment is missing its content?
It is skipped rather than sent. The alternative is an email arriving with a zero-byte file attached, which looks broken to the recipient and gives them nothing to act on.
Is there a pattern to how these providers authenticate?
No, and that is worth knowing. Across the email connectors here there are four different arrangements, and none of them can be guessed from another. Each is implemented from its provider's own documentation, because every wrong guess fails as an error about the credential rather than about the scheme.
