Mail Gateway

Transactional email for applications: password resets, receipts, alerts — the messages your product sends to one person because that person did something.

There are two ways in, and they carry the same mail from the same verified domains. Which one you use is a property of your codebase, not of your plan.

HTTP API

A JSON POST. No connection to hold open, no MTA to configure, and errors come back as data you can branch on. Sending over HTTP

SMTP

For anything that already speaks SMTP — a framework mailer, a CMS, an appliance. Change four settings and you are done. Sending over SMTP

Before the first message

Two things, in this order:

1. A verified sending domain. Mail is rejected unless the address in from belongs to a domain you have verified. This is the first thing that goes wrong for most people — see Sending domains.
2. A credential. An API key (mg_live_...) for HTTP, or an SMTP username and password. Both come from your panel, and they are not interchangeable: the API key will not authenticate an SMTP session.

What lives where

Mail Gateway has two surfaces, and they do different jobs:

You want to	Use
Send a message	mg.truo.cloud — this guide
Add a domain, issue a key, read delivery stats	/v1/mail-gateway in the public API

Setting the service up belongs to the public API and is documented in the reference. Everything under this section is about the sending itself.