Transactional suppression policy

The transactional stream follows one explicit, always-on rule set for who a message may be sent to. This page is the exact policy: the four checks, the order they run in, which ones you can influence, and how a refusal surfaces in the API.

The suppression matrix

Every send is checked against four rules, in this order. The first match refuses the send and its token is returned to your application verbatim.

Token	Refused because	Can you override it?
`blacklisted`	The address is on your account's blacklist — hard bounces from both streams (marketing and transactional) feed this table, alongside addresses you add by hand. When the platform-wide shared blacklist is enabled, addresses that hard-bounced anywhere on the platform are refused too.	Remove the entry from your blacklist — only if you are certain the address is deliverable. There is no per-send bypass.
`spam-reported`	The address belongs to a contact in your account who reported one of your emails as spam (a complaint from the mailbox provider's feedback loop). Mailing an address that flagged you is the fastest way to destroy sender reputation.	No. Always enforced.
`transactional-feedback`	A previous transactional message to this address hard-bounced or drew a complaint — the stream keeps its own feedback memory in the message log, independent of the shared tables above.	No. Always enforced while a bounced or complained message for the address exists in your log (messages are retained 13 months).
`unsubscribed`	The address belongs to a contact who unsubscribed from your marketing — only when you have switched on Honor marketing unsubscribes for the transactional stream. By default this rule does not run.	Yes — it is your policy toggle. Default off.

Why unsubscribes don't block transactional mail by default

Unsubscribing from a newsletter withdraws consent for marketing. Receipts, password resets, security alerts, and other messages a person needs to use your service are a different category, and the industry standard — reflected in anti-spam regulation such as CAN-SPAM, which distinguishes commercial from transactional or relationship content — is that an unsubscribe does not stop them. EmailFlow AI follows that default.

That default carries an obligation: the stream is for genuinely transactional content only. Promotional messages sent through the transactional API to unsubscribed contacts violate our Acceptable Use Policy and, in most jurisdictions, the law. If some of your notifications are marketing-adjacent — digests, re-engagement nudges, upsells — send those as campaigns, or flip the toggle below so unsubscribes are honored on this stream too.

The Honor marketing unsubscribes policy card on the Transactional page, with a toggle switch that extends unsubscribe suppression to the transactional stream, shown above the transactional message log — The per-account policy toggle on Sending → Transactional. Off by default; flipping it makes the unsubscribed rule part of your matrix immediately.

Where the policy is enforced

The matrix runs at two seams, so a refusal can never slip through the gap between them:

At the API, synchronously. POST /api/v1/transactional/send checks the recipient before queuing anything. A suppressed address is refused with 409, code: "CONFLICT", details.reason: "suppressed", and the matrix token in details.suppression — your application learns immediately, and no message row is created.
At send time, again. The background job re-runs the matrix just before handing the message to the mail infrastructure, because feedback may have arrived between queue and send — a bounce notification can land seconds after you queued a second message to the same address. A message suppressed at this seam ends as status: "failed" with error: "suppressed: <token>" in the log.

# A suppressed recipient, refused synchronously (409)
{
  "code": "CONFLICT",
  "message": "The recipient address is suppressed.",
  "details": { "reason": "suppressed", "suppression": "blacklisted" },
  "suggestion": "Hard-bounced or complained addresses are refused on the
    transactional stream. Remove the address from your blacklist only if
    you are certain it is deliverable."
}

Operational notes

Handle 409 in your application. Treat a suppression refusal as a signal about the address, not a transient error — do not retry it on a timer. Surface it to your own user-management flow (a customer whose receipt address hard-bounces needs a new email address on file).
Watch the log. The Transactional page under Sending shows a 30-day issues counter; each bounced or complained message's timeline names the exact event that suppressed the address for future sends.
Suppression tokens are stable API vocabulary. The four strings in the table above are the complete set your integration will ever see in details.suppression — safe to switch on.
The two streams share bounce intelligence deliberately. A hard bounce on a marketing campaign protects your transactional reputation too, and vice versa — both feed the blacklist that rule one enforces.