0.1%. That's the complaint rate that puts an email-sending account under review on Nylas Agent Accounts — one spam report per thousand sends. At 0.5%, sending is d outright. For bounces, the review threshold is 5% and the kicks in at 10%. These aren't suggestions; they're enforced by the platform, and a doesn't clear itself on a timer — you have to contact support with evidence of a fix.
Here's my position: those numbers shouldn't be your rate limit. They should be your last line of defense, behind a stricter limit you set yourself. Rate-limit your own agent before someone else does it for you.
Traditional email code sends when a human or a cron job tells it to. An autonomous agent sends when a model decides to, and models inside feedback loops make weird decisions. A reply triggers a webhook, the webhook triggers a reply, and a benign bug becomes a thousand sends before lunch. Nothing in the model's reasoning says "this is my 400th message this hour, that seems off." That awareness has to live in infrastructure.
Agent Accounts (in beta) bake the infrastructure in through policies. A policy bundles daily send quotas, storage caps, retention windows, and spam settings, and applies to every account in a workspace. Without one, an account runs at your billing plan's maximums — 200 messages per account per day on the free plan — which is exactly what you don't want for an experiment that might loop. Every limit on a policy is optional; omit one and it defaults to the plan maximum, ask for more than the plan allows and the API rejects it.
The useful mental shift: a self-imposed quota isn't throttling, it's an assertion. "This support agent should never need more than 150 sends a day. If it asks for number 151, something upstream is wrong." That's the same logic as a circuit breaker in a service mesh — you're not limiting capacity, you're encoding an expectation so violations become visible instead of expensive.
Policies let you encode different expectations per agent archetype. A prototype gets a tight quota; a production sales agent gets a higher one. The docs explicitly suggest separate workspaces per archetype, because a triage agent and an outreach agent have completely different send profiles.
Outbound rules go a step further than volume — they constrain direction. A rule with trigger: "outbound"
evaluates before the message reaches the provider, and a block
action rejects the send with a 403
:
curl --request POST \
--url "https://api.us.nylas.com/v3/rules" \
--header "Authorization: Bearer <NYLAS_API_KEY>" \
--header "Content-Type: application/json" \
--data '{
"name": "Block outbound to example.net",
"trigger": "outbound",
"match": {
"conditions": [
{ "field": "recipient.domain", "operator": "is", "value": "example.net" }
]
},
"actions": [{ "type": "block" }]
}'
The recipient.*
fields match any recipient, including BCC and SMTP envelope recipients — so an agent can't smuggle a send past the rule by hiding the address. You can also match outbound.type
(compose
vs reply
) to, say, let an agent reply freely but block it from starting brand-new threads.
The bounce and complaint rates that trigger s are computed from events you can subscribe to: message.transactional.delivered
, message.transactional.bounced
, message.transactional.complaint
, and message.transactional.rejected
— four webhook triggers that are your only real-time window into those rates. The docs' advice is blunt: wire them up and your own outbound logic when bounces or complaints climb. You'll see the problem in your own telemetry before the platform tells you about it, and "we d ourselves" is a much better incident report than "we got d."
It also helps to know what's actually being counted. Bounce rate only counts hard bounces — addresses that don't exist — divided by a recent representative send volume; soft bounces from full mailboxes or greylisting don't touch it, and healthy is under 2%. Complaint rate counts recipients clicking Mark this email as spam or dragging your mail to junk, measured only across domains that send complaint feedback. That's why 0.1% is so easy to hit at low volume: a handful of annoyed recipients in a 2,000-send week puts the account under review.
The error responses are worth knowing too. A reputation surfaces as a 400
on send; a per-account or per-domain rate limit returns 429
(back off and retry); an abuse restriction returns 403
with send blocked by abuse restriction
. That last one can be scoped to a single sender address, a domain and its subdomains, a grant, or the entire application — and an application-level restriction stops every Agent Account under the app, not just the one that misbehaved. If your agent treats all send failures as retryable, it will hammer a d account and learn nothing.
Two details make the rule layer trustworthy enough to bet on. First, evaluation fails closed: if a block
rule can't be evaluated because of a transient infrastructure error — say, a list lookup failure during in_list
matching — Nylas blocks the message rather than letting it through. The failure is surfaced as retryable: an API send returns 503
instead of 403
, and inbound SMTP answers with a 451
tempfail so the sending server retries instead of bouncing. A safety mechanism that silently disables itself under load isn't a safety mechanism.
Second, every evaluation writes an audit record. GET /v3/grants/{grant_id}/rule-evaluations
lists, most recent first, which rules matched, what actions were applied, and the normalized sender and recipient data that was considered. When a block happened because evaluation errored rather than matched, the record carries blocked_by_evaluation_error: true
. So when your agent's send comes back 403
at 2 a.m., "why was this blocked?" is one API call, not an archaeology project. A circuit breaker without observability is just a mystery outage.
The honest objection is that real workloads spike. A support agent during an outage might legitimately need 5x its normal volume, and a hard quota turns your safety net into an availability incident. That's true — if the quota is a dead end.
So don't make it a dead end. Make hitting the quota an escalation path: alert a human, queue the overflow, require an approval to raise the cap. The failure mode of a too-tight quota is a Slack ping and an hour of delayed email. The failure mode of no quota is a 10% bounce rate, a platform-level that requires a support ticket to lift, and a sender reputation you rebuild over weeks. Those aren't symmetric risks.
There's also a softer dial worth knowing: policies expose spam_sensitivity
from 0.1 to 5.0 for inbound filtering. Inbound hygiene matters for outbound health, because agents that reply to junk generate complaints.
Concrete next step: before your agent's next deploy, create one policy with a daily quota at roughly 2x the agent's observed peak, attach it to the workspace, and subscribe to the four message.transactional.*
triggers. Then deliberately make your agent hit the quota in staging and check that your alerting fires. If it doesn't, you've found the gap while it's still cheap.