Every send passes one final safety battery immediately before it goes out, and any single failed check stops it. The block names itself: you get a failed_check code and a plain reason, both of which appear below with what to do about each.
If you have a code already, find it in the table. If you are here to understand why the product works this way, start at Why it fails closed.
The denial codes
failed_check | What it means | What to do |
|---|---|---|
recipient_invalid | The address is not a valid email address. | Fix the address. |
tenant_suspended | Your whole account is email-suspended — including by your own pause breaker. | SEND-9 · SEND-10 |
domain_unverified | Your sending domain has no SPF/DKIM/DMARC proof on file. | SEND-3 |
suppression | This person is on your suppression list, or — for cold outreach — has been contacted before. | SEND-4 |
ledger_dedup | This exact draft has already gone to this person. | SEND-5 |
frequency_hard_ceiling | This person is at their 30-day ceiling for campaign email. | SEND-6 |
list_quality | The address is a non-human role account (noreply@, abuse@, …). | SEND-7 |
within_cap | Your workspace is at its monthly marketing send cap. | SEND-8 |
entitlement_sends_limit | The designed denial for your plan’s monthly send limit; it is not active while enforcement is in off mode. | SEND-8 · BILL-10, What happens when I hit a plan limit |
unknown_tenant | Your workspace could not be resolved. Internal — you should not see this. | Contact support. |
ops_unavailable | Deloosh could not reach the sending ledger, so it refused to send blind. | Transient. Retry. |
evaluation_error | A check itself failed unexpectedly, so the send was refused. | Transient. Retry; contact support if it persists. |
Through the API the block is an HTTP 403 carrying the same information: {"error": "blocked by chokepoint", "failed_check": …, "reason": …}.
The order the checks run in
Roughly: is the address real → is your account allowed to send at all → is your domain verified → is this person suppressed → have they already had this exact email → have they had too much email → is this a role account → are you over your monthly cap → if plan enforcement is enabled, are you over your plan limit.
The order is why an account-level problem masks everything else. A paused account denies with tenant_suspended regardless of how clean the audience is, so fix the broadest thing first.
Why it fails closed
If a check cannot be evaluated — the ledger is unreachable, something throws — Deloosh blocks the send rather than letting it through. The safe direction is not to send.
If the suppression or ledger check is unavailable, Deloosh cannot prove that the recipient is eligible. It refuses the send because a message sent to the wrong person cannot be recalled.
For the same reason, a blocked send creates no send-ledger reservation and consumes no usage. An email.send_denied event may still be recorded so the refusal can be diagnosed. Nothing was half-sent.
The two things this list is not
A block is not the same as a warning. Some things Deloosh tells you about without stopping you: the soft cap on frequency, an image-heavy draft, an amber placement estimate. Those are coaching, and you can proceed. Everything in the table above is a stop.
A block is not the same as pacing advice. The safe-send-by projection can recommend splitting the audience or moving the deadline, but Deloosh does not yet hold or defer recipients automatically. See SEND-12, Safe-send-by, pacing, and “split or move the deadline”.
Stopped, but not by a denial code
Three other things stop a send, and none of them produce a code from the table:
- An approved send halted. The approval no longer matches what is about to happen — usually because the audience grew after you approved it. See SEND-13, Why did my approved send halt?.
- Deloosh refused to draft at all. A red sending-health light stops drafting before there is anything to send.
- A play is locked. It needs data you have not connected. See SIG-10, Why is a play locked (“connect data”)?.
If a deadline looks too tight, check the send plan’s advisory pacing projection. Automatic pacing and the new-sender ramp are design commitments, not live causes of a slower send today.
If a send was blocked and you disagree
Read the reason — it names the specific recipient or condition. Then check the recipient dossier for that person, and the send plan for the audience. A dossier shows what actually happened to every past message — delivered, clicked, bounced, complained. There is no open data there, deliberately.
The one thing to know before you go looking for an override: approving a send does not bypass these checks, and it is not meant to. See SEND-1, Nothing sends without your approval.