Skip to content

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

Was this page helpful?
Esc

Start typing to search the docs.

↑↓navigate↵select