How system email works
How Mail sends transactional messages, records delivery outcomes and separates product resources.
Lepsto Mail sends the messages your product needs to work: address confirmations, colleague invitations, account recovery links and payment receipts. These messages go to the person whose action prompted them. Register a domain, publish its DNS records and verify it before sending. Mail signs the messages, handles delivery to receiving servers and records the outcomes.
You can read each message’s status or receive its delivery events through a webhook. For the complete setup and first send, follow send your first email.
What you work with
- Product: the boundary for domains, templates, audiences, contacts, suppressions and webhooks. Resources in one product are invisible to another. Manage the product through the platform; see the platform model.
- Domain: the verified sender domain, with settings for open and click tracking, tracking host and delivery encryption. Publish Mail’s DNS records before sending from it. See set up a sending domain.
- Public key: your application’s credential for public sending routes. An Owner or Admin manages it in Settings → Public Access. Route scopes do not restrict sender domains. See authenticate the public API.
- Email: one message for one or more recipients, with inline or template content, a subject, bodies, cc, bcc, reply-to, headers and tags. See send a message.
What happens to a message
An accepted request creates a message with an identifier; delivery happens later. Mail queues an immediate send or marks a later send scheduled. While it remains scheduled, you can reschedule or cancel it. Once Mail hands the message to receiving servers, its status becomes sent. Later outcomes update that status:
Status | Meaning |
|---|---|
scheduled | Accepted and waiting for its send time. Can still be rescheduled or canceled. |
queued | Accepted and about to be handed to the receiving mail servers. |
sent | Handed over. The receiving server has not reported an outcome yet. |
delivered | The receiving server accepted the message for its recipient. |
bounced | The receiving server rejected it. |
complained | The recipient marked it as spam. |
suppressed | Every recipient was on your suppression list, so nothing was sent. |
blocked | A sending limit or your sender reputation stopped it before it went out. |
failed | The message could not be handed over. |
canceled | You canceled it before it went out. |
Use the message identifier to read its current status. Register a webhook to receive events as they happen.
Hard bounces and spam complaints suppress the affected recipient, so later sends skip that address. Mail also measures hard-bounce and complaint rates over a rolling window. A rate above its threshold pauses sending until it recovers. See handle bounces and protect your sending.
Transactional email and marketing broadcasts
Transactional messages and marketing broadcasts use different recipient and unsubscribe rules.
A transactional message responds to a person’s action, such as requesting a password reset, making a purchase or triggering an alert. You supply the recipient addresses directly. The product’s suppression list still applies to these direct sends.
A broadcast sends marketing content to an audience. Creating the draft sends nothing. Queuing it creates one email per eligible contact, skips suppressed and unsubscribed contacts, and adds a one-click unsubscribe header to each message.
Transactional | Broadcast | |
|---|---|---|
Addressed to | A specific person, because of something they did | Everyone in an audience |
Created by | Sending directly, to addresses you supply | Drafting, then queuing, which fans out into one message per eligible contact |
One-click unsubscribe header | No | Yes, on every message |
Suppression list | Applies | Applies, and unsubscribed contacts are skipped as well |
Progress reported | Per message | Per message, and for the broadcast as a whole |
These Mail guides cover transactional sending. For marketing, use send one message to a list of people.
A broadcast unsubscribe also adds the address to the product’s suppression list. That blocks transactional mail to the same address, including receipts and password resets. If the recipient asks to return, the broadcasts guide explains how to clear both the contact’s unsubscribe state and the suppression.
Where Mail sits in the workspace
Open Mail in your product’s navigation to reach these screens:
Screen | What it answers |
|---|---|
Mail | The dashboard: how much you have sent lately and how much of it arrived. |
Mail → Domains | The domains you have registered, and the dialog that registers another. |
Mail → Domains → <domain> | One domain: the DNS records to publish, the status they add up to, and a re-check you can run on the spot. |
Mail → Emails | Sending one message by hand, and finding out what became of a message you already sent. |
Mail → Templates | Your templates, one template’s revisions, and the rollback and archive switches. It does not author content. |
Mail → Logs | Every message the product has sent, narrowed by subject, recipient, domain or status. |
Mail → Logs → <email> | One message and the events it went through, in order. |
Mail → Suppressions | The list of addresses nothing is ever sent to. |
Mail → API keys | A status screen only: whether the product has a public key configured, and where keys are created and revoked. |
Manage the sending credential under the product’s Settings → Public Access. Public keys are platform credentials and can cover routes across toolkits; that screen is where you create, rescope and revoke them. See authenticate the public API.
Use the documented tools for contacts, audiences, broadcasts, webhooks and the reputation report; these have no workspace screen. Template authoring also uses tools or REST.
The guides show available workspace steps alongside MCP tools and REST operations.
Next steps
- Send your first email: Complete domain setup and a first delivery.
- Set up a sending domain: Register and verify your sender domain.
- Authenticate the public API: Manage route scopes and sending credentials.
- Send a message: Use message fields, batches, scheduling and limits.
- Receive delivery events: Receive signed outcome notifications.
- Handle bounces and protect your sending: Inspect suppressions and sending reputation.