# Email Domains (/docs/overview/email-domains)

> For the complete documentation index, see [llms.txt](https://docs.tandemcx.ai/llms.txt). Any page on this site can be fetched as Markdown by appending `.md` to its URL.

<Callout type="info">
    **This page is being rolled out.** If **Admin → Email Domains** isn't in your sidebar, it isn't
    enabled for your organization yet — contact support.
</Callout>

Setting up outbound email takes two steps. First, prove you own the domain it will send from, by
publishing a handful of DNS records — once per domain. Then add the specific **sender addresses**
on that domain that workflows are allowed to use. The [Send
Email](/docs/workflows/reference/category/messaging/sendEmail) node — and any AI agent that
reaches a workflow containing one — picks from those addresses. The node stays out of the
workflow editor until the first domain verifies, so finish this page before you go looking
for it.

Everything here is organization-wide and sits behind the administrator role. The server enforces
it on every change: adding or removing a domain, **Check Status**, adding, editing or removing a
sender, and saving **Email Settings** are refused with a `403` for a user without the role.
Reading the page is not gated. Every role Tandem issues today (Owner, Admin and Member) carries
the administrator role, so in practice everyone in your organization can make these changes. See
[Admin](/docs/overview/admin).

## Add a domain

1. Go to **Admin → Email Domains** and choose **Add Domain**.
2. Enter the domain itself: `acme.com`, not `support@acme.com`. It has to be a domain you
   control the DNS for.
3. Choose **Add Domain**. Tandem registers it and shows you the records to publish.

A domain can only be configured by one organization. If someone else has already claimed it,
you'll be told so rather than silently taking it over.

There is one exception. A claim that has sat unverified for more than **7 days** can be taken
over by another organization that adds the same domain. The takeover removes the old claim and
its sender addresses, and the new organization gets its own DNS records to publish. A domain
that is verified, or has been verified since this check was added, is never taken over, and
Tandem checks with Amazon SES before removing anything. If you added a domain and haven't
verified it, publish the records within 7 days to keep it.

## Publish the DNS records

The **DNS Records** dialog lists everything you need, and each name and value has a copy
button. Add every record exactly as shown at your DNS provider.

| Type                  | What it's for                                                                                                                            |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Three `CNAME` records | **DKIM.** Cryptographically signs your mail so receiving servers can tell it really came from you. These are what verification waits on. |
| One `MX` record       | **MAIL FROM.** Lets the envelope sender use your own subdomain instead of Amazon's.                                                      |
| One `TXT` record      | **SPF**, on the same MAIL FROM subdomain. Names Amazon SES as allowed to send for it.                                                    |

A few things to check before you go looking for a problem:

- **Don't append your domain twice.** Many DNS consoles add the domain to whatever you type in
  the name field. The names here are already fully qualified, so if your provider does that,
  paste only the part before your domain.
- **Some providers strip the quotes** from the SPF value, and some require them. Follow your
  provider's convention for `TXT` records.
- **The MX record's `10` is its priority.** If your provider has a separate priority field,
  put `10` there and the hostname in the value.

## Choose the MAIL FROM subdomain

The `MX` and `TXT` records go on a subdomain of yours, the **MAIL FROM subdomain**. It is
`mail.` unless you change it. Pick a name with no other records: DNS allows no `MX` or `TXT`
record on a name that already has a `CNAME`, and Amazon SES won't use a name that already
receives mail. A common clash is `mail.<your domain>` set up as a `CNAME` for webmail.

To use a different name, open **DNS Records**, type the new subdomain in **MAIL FROM
Subdomain** (one label, such as `send`), and choose **Change Subdomain**. The `MX` and `TXT`
rows move to the new name. Publish them there and delete the old ones. The DKIM records and the
domain's status don't change, and you can keep sending while the new MAIL FROM verifies.

If Amazon SES can't find the `MX` record on the MAIL FROM subdomain within 72 hours, it stops
checking and **DNS Records** shows **MAIL FROM failed**. If the name has no other records,
publish the `MX` record and choose **Retry** to start the check again. If it already has a
`CNAME`, or an `MX` record other than the Amazon SES one, change the subdomain as above.

## Wait for verification

Verification usually completes within a few minutes of the records resolving, but DNS can take
up to 72 hours to propagate. The status is re-checked every time you open the page, so there is
nothing to subscribe to — come back, or use **Check Status** to look again right away.

| Status              | What it means                                                                                              |
| ------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Pending DNS**     | Normal. The records aren't visible to Amazon SES yet.                                                      |
| **Verified**        | Done — you can send from this domain.                                                                      |
| **DNS unreachable** | The records were visible and now aren't. Check they're still published exactly as shown.                   |
| **Failed**          | Amazon SES gave up checking. Remove the domain and add it again to start over with a fresh set of records. |

A domain can read **Verified** while its MAIL FROM record is still pending. That's fine. You
can send. Publishing the `MX` and `TXT` records afterwards improves deliverability; it isn't a
prerequisite.

## Add your sender addresses

A verified domain gives your organization the _right_ to send. It doesn't by itself create any
addresses. **Sender Addresses**, below the domain list, is where you decide which specific
addresses can be used — `support@acme.com`, `noreply@acme.com`, and so on.

Choose **Add Sender**, type the part before the `@`, pick one of your verified domains, and
optionally give it a display name (what recipients see beside the address).

This list is what a workflow author picks from, so it's worth keeping tidy: every address here
is one anyone building a workflow can send as.

<Callout type="info">
    Only configured senders can send. An address on a verified domain that isn't in this list is
    rejected — verifying `acme.com` does not, on its own, let a workflow send as
    `anything@acme.com`.
</Callout>

## Choose a default sender

**Email Settings**, on the same page, holds two organization-wide choices:

- **Default sender** — which of your configured senders a workflow uses when it doesn't choose
  one itself. You can also set a default display name that overrides the sender's own.
- **Let workflows choose their own sender** — on by default. Turn it off to force every send
  through the default sender above, whatever an individual workflow specifies.

Either way, every send is checked against your configured senders. A workflow can never send
from an address your organization hasn't set up.

## Sending from a workflow or an AI agent

<Callout type="info">
    **Send Email appears once a domain is verified.** Until then the node is absent from the Node
    Library, the node picker, and a search for "email". There is nothing to enable. A domain still
    reading **Pending DNS** does not bring it back. If the node is missing, check the domain list
    above rather than your workflow.
</Callout>

Add a **Send Email** node to a workflow and choose its **From Address** from the dropdown — it
lists your configured senders. **From Name** is optional: leave it blank to use the sender's own
display name, or set it to override that for this one message.

If the address is later removed, or its domain falls out of verification, the node takes its
error path rather than sending.

AI agents send email the same way: give the agent a tool bound to a workflow that contains a
Send Email node. There's nothing extra to configure on the agent.

## Limits and billing

A single email can carry up to **10 recipients** in total, counting To, Cc, and Bcc together. A
send that exceeds that is rejected before it reaches your recipients. Split a larger audience
across several sends.

Email draws against your account balance the same way SMS does: **one charge per email**, no
matter how many recipients it went to. A send is only charged once it's been accepted for
delivery — a rejected or failed send costs nothing. If your balance is exhausted, new sends stop
and the Send Email node takes its error path; topping up resumes them.

## Remove a sender or a domain

Removing a **sender** stops it being used immediately. Any workflow still pointed at it will
fail until it's re-pointed at another sender, so re-point them first.

Removing a **domain** removes its sender addresses with it, stops every workflow and agent from
sending on it, and releases the domain so it can be configured again later — by you or by anyone
else. The DNS records become inert; you can delete them at your provider whenever you like.