Opportunistic vs forced encryption
Almost all email is encrypted "where possible". The useful question is not whether your provider encrypts — it is what it does when it cannot.
Two couriers
The first uses an armoured van when one is free. When none is, he takes his bike. The parcel always arrives — sometimes it just crossed the city in the open. That is opportunistic encryption, and it is the default behaviour of very nearly every email provider in the world.
The second uses only the van. No van, no delivery: the parcel stays at the depot and you are told. It is not lost, and it is not returned to sender stamped "undeliverable" — it waits. That is forced encryption, and it is what you switch on per API key when the contents call for it.
What the second courier does with the parcel matters as much as his refusal to ride in the open. We come back to it below, because that is where our behaviour differs from most.
Normal
the default
Encrypt whenever the receiving server offers it. When it does not, deliver anyway — because not delivering would be worse for almost all mail.
Required
when the contents demand it
Deliver only over a verified TLS connection. If that is unavailable, do not send at all.
What actually happens
| When the receiving server… | Normal | Required |
|---|---|---|
| offers TLS with a valid certificate | delivered, encrypted | delivered, encrypted |
| offers no encryption at all | delivered in the clear | not sent |
| offers TLS with an expired, self-signed or wrong-name certificate | delivered in the clear, or encrypted to an unproven party | not sent |
| is unreachable | retried, then fails | retried, then fails |
The middle row is the whole reason Required exists. Under Normal, the absence of encryption is reported nowhere: the message goes, it arrives, and nothing marks it as having travelled readable.
What does "verified" mean?
Not merely "encrypted". The receiving server must advertise STARTTLS, present a certificate that is trusted, unexpired, and matches the name in its MX record, and negotiate at least TLS 1.2.
A self-signed certificate encrypts the connection without proving who is on the other end. That is exactly what an active interception relies on: the traffic is encrypted, but to the interceptor. Required mode treats those as failures.
What if the message cannot be sent?
This is where we part company with most descriptions of forced TLS, which say the message bounces back to the sender. Ours does not bounce.
In order: the message is held, never sent in the clear. If the obstruction was momentary, a retry delivers it encrypted seconds later and you see nothing but a delivery. If it is permanent, we establish that ourselves by querying the recipient's server, and the status becomes blocked — usually inside a minute, rather than waiting for retries to run out.
The address is never suppressed. It is valid and nothing was transmitted, so the recipient does not enter your suppression list, and list tools that automatically drop bounced subscribers will not drop them. That is what stops a security requirement from quietly costing you subscribers.
And if the recipient fixes their encryption afterwards, a later attempt succeeds and the status returns to delivered on its own.
You always know why
Every block carries a machine-readable reason, available from GET /v1/email/{id} and on the blocked webhook event:
| Reason | What happened |
|---|---|
| no_starttls | The receiving server offers no encryption at all. |
| cert_expired | Their certificate has expired. |
| cert_self_signed | Their certificate is self-signed — encrypted, but unverifiable. |
| cert_name_mismatch | Their certificate is for a different name than their MX. |
| cert_untrusted | Their certificate comes from an unknown authority. |
| tls_version | They negotiate only TLS versions older than 1.2. |
| starttls_withheld | They offer encryption to other senders, but not to us. |
| refused | They refused the connection before any exchange. |
| connect_failed | Unreachable — no mail server answering. |
Which should I use?
Normal for newsletters, product notifications, receipts — anything where failing to arrive costs more than being read by a third party. That is almost all email, which is why it is the default.
Required for medical records, legal documents, financial statements, credentials, internal alerts — anything you would answer for if it were read in transit. The setting lives on the API key, not the account: a billing key can require encryption while a newsletter key stays on Normal, same domain, same sender.
What Required costs you
Some recipients become unreachable. A small badly-maintained server, a local government office, an address at a host that let its certificate lapse — under Required you stop writing to them. That is the point, but it is a real cost and worth planning for.
You inherit a problem that is not yours. The certificate that needs fixing belongs to the recipient. All you can do is tell them — which is why every block carries a specific reason rather than a generic failure.
It is not end-to-end encryption. This protects the message in transit only. Once the recipient's mail server accepts it, the message is in their hands and what their provider does next is not something we control. What it removes is passive reading on the network between us and them — the leg of the journey you otherwise have no visibility into at all.
The setting is on the key, not the account
Change it in one step in the dashboard, key by key, with no redeploy.
Create an account