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

# Email

> Your SMTP server, the templates every email uses, and what was sent.

FireTone sends email through **your** mail server: sign-up confirmations,
password resets, invitations, sign-in codes, spend alerts, new voicemail, AI agent callbacks and an
IVR's Send email step. Set it up once in **Settings → Email**.

## The mail server

| Field                       | What to put                                                                                                                           |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Server**                  | Your relay's host, e.g. `email-smtp.ap-south-1.amazonaws.com`, `smtp-relay.brevo.com`, `smtp.gmail.com`                               |
| **Port** / **Security**     | `587` with STARTTLS, or `465` with TLS from the start. **None** is for a relay on your own network only                               |
| **Username** / **Password** | The relay's credentials. The password is stored encrypted and never shown again                                                       |
| **Send from**               | The address every email comes from, e.g. `no-reply@firet.one`. Your relay must be allowed to send as it (SPF and DKIM on that domain) |
| **Sender name**             | The name on platform email                                                                                                            |

Press **Send test email**. FireTone sends one straight away and shows the
server's own answer when it fails, for example
`535 5.7.8 Username and Password not accepted`. A test that goes through marks
the server **Working**; changing the server, port, security, username, address
or password clears that until the next test.

<Note>
  Sign-up and two-step sign-in both depend on email arriving, so they can only
  be switched on once a test email has gone through.
</Note>

### Who each email is from

Email sent on an organisation's behalf carries its name:
`"Acme via FireTone" <no-reply@firet.one>`. Platform email (sign-up, sign-in
codes) carries the brand name alone. The address is always **Send from**,
because a relay will not send as anyone else.

## Brand and base domain

* **Brand name**: shown in every email and after "via".
* **Base domain**: organisation handles hang off it. With `firet.one`, the
  organisation `acme` is `acme.firet.one`: its SIP domain and its panel address.

## Alerts and voicemail

* **Spend and call alerts.** When a toll-fraud alert fires (see Alerts), it is
  emailed once to the organisation's admins and, separately, to your operator
  admins, so neither side sees the other's addresses. An alert that stays open
  is not emailed again; one that re-opens after being acknowledged is.
* **New voicemail.** An extension with **Email new voicemail to** gets each
  message by email with the recording attached.
* **AI agent callbacks.** When a virtual agent arranges a callback, the person
  in its profile's **Callback from** is emailed the number, the question and
  the ticket, if they have a panel login. The ticket is assigned to them
  either way.

## Two-step sign-in

**Two-step sign-in** (Settings → Email → Brand) chooses who must enter a code
that is emailed at each password sign-in: nobody except those who turn it on
for themselves, operator admins, or everybody who signs in with a password. It
can only be required once a test email has gone through. See
[signing in](/guides/signing-in#two-step-sign-in). If email then breaks,
`firetonectl mfa-off --policy` on the server lifts the requirement.

## Templates

Every email is rendered from a template you can change in **Settings → Email →
Email templates**. Each kind of email has its own variables, listed beside the
editor. Click one to insert it: `{{org.name}}`, `{{caller}}`, `{{link}}`.

* **Every email** has `{{brand.name}}`, `{{brand.domain}}`, `{{org.name}}`,
  `{{org.handle}}`, `{{org.panel_url}}`, `{{org.sip_domain}}`,
  `{{recipient.email}}` and `{{now}}`.
* A variable the email does not have is refused when you save, naming it and
  listing the ones it does have.
* Values are escaped in the HTML, so a caller's name cannot add markup to an
  email. Scripts are refused.
* Leave the plain-text version empty and it is made from the HTML.
* The preview beside the editor uses sample values and your real brand.

**Which template is used:** the organisation's own, else the platform's, else
the one built into FireTone. **Reset** goes back to the one it inherits.

**Templates are yours alone.** Organisations do not see this screen: the relay
is yours, the mail leaves under your domain, and the wording is part of your
platform's voice. What you can keep per organisation:

| Email                                                     | Per organisation?                                                            |
| --------------------------------------------------------- | ---------------------------------------------------------------------------- |
| New voicemail, spend alert, invitation, AI agent callback | Yes — choose the organisation in the page header and edit its version        |
| Sign-in code, password reset, sign-up                     | No: account-security email is the platform's everywhere                      |
| IVR email templates                                       | Yes — named templates that organisation's IVRs pick in their Send email step |

Choose an organisation in the page header to edit its versions; with none chosen
you are editing the platform's.

## Sent email

**Sent email** lists every email with its status: waiting, sent or failed.
Nothing waits on the mail server: an email is queued and sent within seconds,
and a refusal is retried after 1, 5 and 30 minutes and 2 hours, then marked
failed with the server's answer. **Retry** sends a failed one again.

Email queued before the server was set up waits, and goes once it works. The
daemon log says `email waiting: mail is not configured` meanwhile, and every
failed send is a warning naming the server's reply.

An organisation's administrator sees the email sent for their organisation,
never the account email (codes, resets, invitations) of its people.
