What stops a send
Every send passes one gate
All workspace mail goes through a single function, and the suppression check happens there rather than in each feature. That is deliberate: a check that lives at every call site is a check a new feature forgets, and the first symptom of forgetting is mail to an address that has already bounced.
So there is no path — not a quote, not an invoice, not an automation — that skips it.
The suppression list
An address lands on the suppression list for one of these reasons:
| Reason | Where it comes from | Stops |
|---|---|---|
bounce | The receiving server rejected the message | All mail |
complaint | The recipient marked it as spam | All mail |
unsubscribe | The recipient clicked unsubscribe | Marketing mail only |
manual | An operator added it | All mail |
admin_block | An operator blocked it | All mail |
provider | The sending provider's own list | All mail |
Suppressions are scoped. An entry can be yours — this address does not hear from your business — or platform-wide, which applies to every workspace. Yours is the normal case; the platform-wide scope exists for addresses nobody should be mailing at all.
Why an unsubscribe is treated differently
Somebody who unsubscribes from your newsletter has opted out of marketing. They have not asked to stop receiving their invoice, their receipt, or their password reset, and withholding those would be its own kind of failure.
Every other reason is about deliverability or an explicit block, and those stop all mail. Sending again to an address that hard-bounced is how a sending domain earns a place on a blocklist, and it does not matter how transactional the message was — the receiving server does not grade your intentions.
Anything a recipient could reasonably call promotional is sent as marketing class, so it respects unsubscribes. That classification is made by the feature sending it, not by the recipient.
What a block looks like
| Situation | What happens |
|---|---|
| Some recipients suppressed | The message sends to the rest |
| Every recipient suppressed | Nothing is sent, and the attempt is logged as suppressed |
A fully suppressed send is logged as suppressed, not as failed. The system did exactly what it was supposed to do, and a log that calls that a failure sends somebody debugging a problem that does not exist.
If the suppression lookup itself cannot run, the send goes through. A transient database error must not silently swallow a password reset, and the risk it briefly un-guards — one more message to a bounced address — is the smaller of the two.
Bounces and complaints arrive on their own
You do not maintain the suppression list by hand. When a receiving server bounces a message or a recipient reports it as spam, the sending provider reports it back and the address is suppressed for your workspace automatically, with the provider's own reason recorded.
The two are treated differently where it counts:
- A complaint is the person's own opt-out. The contact is marked unsubscribed as well as suppressed.
- A bounce is a deliverability verdict. The bounce is recorded on the contact, but it is not read as the person having chosen anything.
Campaigns check more than that
A campaign send checks three things for each recipient, at the moment of sending rather than when the campaign was queued:
| Check | Recipient is marked |
|---|---|
| No contact record for this address | skipped, reason contact_not_found |
| The contact is unsubscribed | unsubscribed |
| The address is suppressed | skipped, reason suppressed |
| The contact is on your do-not-contact list for email | skipped, reason contact_dnc |
Checking at send time is the point. A campaign to twenty thousand people takes a while, and somebody who unsubscribes from the first batch must not receive the fifteenth. Eligibility checked at queue time could not do that.
The audience itself is materialised when you start the campaign, so later changes to a segment do not change who a running send reaches. Eligibility is live; membership is frozen.
Sending caps
Every workspace has a ceiling, because all orgs share the sending reputation of the platform's sending account. One tenant sending at an abusive rate is a deliverability problem for everyone else.
| Default | |
|---|---|
| Per hour | 250 |
| Per day | 1,000 |
The count is taken from everything your workspace actually sent in the window. A workspace can also be suspended from sending outright, which is an operator action and not something a plan change causes.
Today the caps are enforced when sending from a hosted mailbox. Other workspace mail is counted toward the totals but is not blocked by them yet, and the per-campaign recipient ceiling in the same settings is not enforced at all. Treat the numbers as the intended ceiling rather than a guarantee.
What got sent, and what did not
Every outbound email is recorded — recipients, subject, the address it was sent from, what triggered it, the provider's own message id, and whether it was sent, failed or suppressed. Failures are recorded too, because a message that silently never went out is the worst outcome for the person waiting on it.
Message bodies are not stored. The log answers "what went out, to whom, when, and did it land". Keeping every body indefinitely is a separate decision with its own privacy consequences, and it is not made as a side effect of logging.
You can read the log at Reporting → Email send logs, filtered by what triggered each message.