> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brew.new/llms.txt
> Use this file to discover all available pages before exploring further.

# Transactional Email

> Send password resets, receipts, and verification codes from Brew. A transactional email is an automation on a domain you mark for transactional purpose.

<Note>
  **August 2026**
</Note>

<Note>
  **Historical Note · August 2026** · This post describes the launch. See
  [Emails vs Automations](/create-emails/emails-vs-automations#a-note-on-transactional-emails)
  for the current model and [Build an Automation](/create-emails/build-an-automation#send-a-transactional-email)
  for the walkthrough.
</Note>

## What Shipped

Password resets, receipts, and verification codes can now go out from Brew.
Until now they had to stay on a separate provider, because every Brew send
carried an unsubscribe link and skipped unsubscribed contacts.

That is the right behavior for marketing and the wrong behavior for a password
reset.

There is no new object to learn. A transactional email is an automation. What
makes it transactional is the domain it sends from.

## The Domain Decides

Every sending domain now carries a **sending purpose**, marketing by default.
Point an automation's **Send Email** step at a domain marked **transactional**.
That send drops the unsubscribe link and reaches unsubscribed contacts.

The same automation on a marketing-purpose domain stays an ordinary marketing
send that honors every unsubscribe.

One switch, one place. You pick the class by picking the domain. There is no
per-message flag to get wrong, and no way for a newsletter to quietly inherit
transactional rules.

Set the purpose when you add the domain in **Settings → Domains**, or with
`POST /v1/domains { sendingPurpose }`. You can change it later, and Brew fails
the change closed while an email still points at the domain.

## Fire It From Your Product

Build the trigger, wire it to a one-step automation, publish, and fire it with
the moment's data:

```bash theme={null}
curl -X POST "https://brew.new/api/v1/automations/triggers/tri_password_reset/fire" \
  -H "Authorization: Bearer $BREW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "payload": { "email": "jane@example.com", "resetUrl": "https://app.example.com/reset/abc123" } }'
```

The design reads the payload as `{{ trigger.resetUrl }}`, and `email` routes
the run to a contact. Nested objects and arrays are fine, addressed by dotted
path.

Every trigger declares a payload contract, and every fire is checked against
it. A `GET` on the same URL is a ready check. It runs the auth, scope, and
permission gates without sending anything, then hands back the contract and
the automations a fire would match.

Agents get the same thing through `list_triggers` and `check_trigger_ready`
over MCP.

## Get Started

Add a transactional-purpose domain in **Settings → Domains**, then build the
flow. Run marketing and transactional mail on separate subdomains. A spike in
marketing complaints then can't drag down the reputation that delivers your
password resets.

## Related

* [Emails vs Automations](/create-emails/emails-vs-automations#a-note-on-transactional-emails)
* [Build an Automation](/create-emails/build-an-automation#send-a-transactional-email)
* [Verify Your Sending Domain](/get-started/verify-your-sending-domain)
* [Merge Tags](/create-emails/merge-tags)
* [What You Can Send With Brew](/get-started/what-you-can-send)
* [API Changelog](/changelog/api)