Skip to content
Skip to main content

Send transactional email from a domain

Last updated:

Some email doesn’t belong to a user. Password resets, receipts, and system notifications come from your application, not from someone’s connected inbox. Routing those through a user grant is the wrong model, and you don’t want to make every app user authenticate just so you can email them.

Nylas transactional send fixes this with a domain route. You send from a verified domain instead of a user’s account, so there’s no grant and no OAuth, just your API key and a domain you control.

How do I send email without connecting a user account?

Section titled “How do I send email without connecting a user account?”

Send a POST /v3/domains/{domain_name}/messages/send request. It mirrors the grant send endpoint, but the route is keyed on a verified domain rather than a grant_id, so no user authentication is involved. You reuse the same to, subject, and body fields you’d use for a normal send. Track the outcome through 4 events: message.transactional.bounced, complaint, delivered, and rejected. The feature is currently in beta.

The request below sends a transactional message from a domain.

How do I set up a sending domain?

Section titled “How do I set up a sending domain?”

You need a domain that Nylas has verified before you can send. For testing, use the free nylas.email domain every account can access; for production, verify your own custom domain so mail comes from your brand. Transactional sends follow the same 3 MB JSON and 25 MB multipart attachment limits as a grant send.

See the transactional send quickstart for the domain verification steps.

Things to know about transactional send

Section titled “Things to know about transactional send”

Transactional send is sending infrastructure. It delivers whatever you hand it, whether that’s a single password reset or a product update going out to a large list, and reports delivery, bounces, and complaints back through webhooks. If you’re running marketing sends, the campaign layer (list management, unsubscribes, performance tracking) lives in your application.

Act on the deliverability events. Subscribe to message.transactional.bounced and message.transactional.complaint, and remove any address that appears in them from future sends. Repeat sends to bad addresses push your bounce and complaint rates up until sending is paused. Clean any list before you send to it, and never mail a purchased list.

If you’re sending at volume, use your own verified domain rather than the free nylas.email domain, and warm it first. A new domain needs about 4 weeks of ramped sending before providers trust it. The domain warming guide has a schedule and a script.

Because the domain route mirrors the grant route, you can share most of your send code between authenticated and transactional paths and switch only the URL.

There’s one thing a classic send-only API can’t do. If you have a Nylas Agent Account on the same domain, replies to your transactional mail are delivered to that account’s mailbox automatically, and your code reads and answers them through the same Messages API. A password reset stays one-way; a receipt the customer replies to becomes a conversation instead of a dead end at a no-reply address.

The feature is in beta, so behavior is stable but the API may change before general availability. Monitor the 4 message.transactional.* events to confirm delivery and catch bounces, the same way you would for grant sends.

What’s next

Section titled “What’s next”