Land your AI agent's email in the inbox, not spam

You give your AI agent a real mailbox, it sends its first batch of email, and half of it lands in spam. The agent did nothing wrong. The domain did — it's new, it has no sending history, and mailbox providers treat an unknown domain that suddenly sends volume the same way they treat a spammer. Deliverability is the work of proving the mail is really yours, sending at a pace providers trust, and watching the signals that say whether recipients want it.

An Agent Account sends from a domain you own, so its inbox placement is yours to manage like any other mail from your company. This post is a practical playbook for getting and keeping an agent in the inbox, from two angles: the HTTP API for your backend, and the , which returns each record's host, type, and value to copy into your DNS provider. Verification usually succeeds within a few minutes, though DNS can take up to 24 hours depending on the record's TTL — the you'd use any time, or nylas email send from the terminal:

nylas email send \

  --to [email protected] \

  --subject "Your booking confirmation" \

  --body "Thanks for booking with us. Here are your details..."

Monitor delivery with webhooks

You can't manage deliverability you can't see, and for an Agent Account the four deliverability webhooks are your real-time signal. Subscribe to message.delivered, message.bounced, message.complaint, and message.rejected to track exactly what happens to each outbound message — the same events Nylas uses to calculate your bounce and complaint rates. From the CLI, one command registers them:

nylas webhook create \

  --url https://yourapp.example.com/webhooks/nylas \

  --triggers message.delivered,message.bounced,message.complaint,message.rejected

The same subscription over the API is a POST /v3/webhooks with the triggers and a callback URL — see the . Pause or slow your outbound when bounces or complaints climb, and stop mailing any address that hard-bounces. Catching a problem in your own telemetry is what keeps you under the thresholds that pause sending.

Stay under the bounce and complaint thresholds

Nylas tracks a rolling bounce rate and complaint rate for each Agent Account, and crossing either threshold has consequences. Bounce rate is hard bounces — addresses that don't exist, not transient soft bounces — divided by your recent send volume. Complaint rate is spam reports divided by recent volume, counted only against recipient domains that report complaints back to senders. The denominator is a recent volume window, so the rate stays meaningful whether you send a hundred messages a day or a million.

Here's where each rate puts an account:

The complaint threshold is low enough — 0.1% — that even a handful of recipients reporting your mail can put a low-volume account under review. Under review is silent to your application; a pause returns immediate feedback on the send call.

What a pause looks like to your code

When enforcement kicks in, your send requests start failing, and the status code tells you which problem you have. These are the three you'll see, and they call for different handling:

One thing to design for: a reputation pause does not clear itself on a timer. Resuming requires Nylas to lift it, so you contact support with the bounce or complaint source and the fix you've applied. That's the opposite of a 429, which clears as soon as you slow down. An abuse restriction returns 403 with the body send blocked by abuse restriction and is also cleared by support, not by waiting.

Sending limits that interact with deliverability

Beyond reputation, a few hard limits shape how an agent can send, and hitting them returns 429. Each Agent Account has a daily send quota — 200 messages on the free plan, with no daily cap on paid plans by default. Your organization shares a per-second rate too: all sandbox applications pool to 1 request per second, and all production applications to 5 per second. A single message should address at most 50 recipients across to, cc, and bcc, and must be 25 MB or less in total size.

These interact with warm-up in a way that's easy to miss. Calendar invitations count against the daily send quota, and when an account is over quota the event still saves but the invitation is skipped silently — so an agent that both emails and schedules can quietly stop notifying people. Batch large audiences into groups of 50 or fewer, and keep your per-second send rate under the pooled cap so a burst doesn't start returning 429 mid-warm-up.

Keep in mind

A short list of habits keeps an agent inside the deliverability envelope once it's sending for real. Each one heads off a specific way reputation slips.

• 
  Validate addresses before sending and skip any that have hard-bounced before. Hard bounces are the fastest way to a paused account.


• 
  Honor unsubscribe and removal requests immediately. At a 0.1% complaint threshold, ignoring a few costs you.


• 
  Wire up all four deliverability triggers and pause your own outbound when bounced, complaint, or rejected rates climb — you'll see it in your telemetry before Nylas tells you.


• 
  Keep the From domain consistent with the domain your accounts are verified on, so DMARC alignment holds. Forwarding breaks SPF, but DKIM survives it, which is exactly why DMARC accepts a pass from either.


• 
  Warm each domain separately. Reputation doesn't transfer, so a second domain starts from zero no matter how good the first one's record is.

Wrapping up

Deliverability for an agent is the same discipline as for any sender, with the advantage that you own the domain end to end. Authenticate first, layer DMARC on in stages, warm the domain over four weeks, and let the four deliverability webhooks feed your own pause-and-slow logic. The thresholds are strict — 10% bounces or 0.5% complaints pauses an account — but every signal that feeds them is one you can watch in real time and act on before Nylas has to.

Where to go next:

• 
  — the full ramp schedule and a daily send script


• 
  — schemas for the delivery, bounce, complaint, and rejection events