How to send triggered emails: 4 methods and which one to choose

But you can also trigger emails from a CLI or use an MCP server to send emails triggered by an AI agent.

In this article, we’ll break down these methods for sending triggered emails and highlight when you might want to use each one. We’ll also direct you to resources where you can learn more about each method and get set up.

What is a triggered email?

A triggered email is an automated message that is sent the instant a specific event happens. This is typically a signup, a failed payment, or a password reset request, but it could also be things like internal notifications of code checks or even AI workflows. 

To send the email, your app either makes a request to an email API or delivers the message over SMTP the moment the trigger fires. This causes your email service provider to send the email you have set up that’s related to the trigger. 

Triggered emails can be promotional or transactional. This guide focuses on transactional emails, which are for essential information related to how the recipient interacts with your business, such as order confirmations, password resets or shipping updates. 

What actually fires a send?

A triggered email starts with an event somewhere in your system, and the send is the response to it.

Common event sources include:

• App events: A user signs up, performs an action, or completes a purchase

• Property changes: A subscription status flips from trialing to active, or a plan field updates

• Webhooks: Your billing system, payment processor, or another third-party service notifies your app that something happened

• Scheduled checks: A job runs periodically and finds a condition worth acting on, like a trial ending in three days or an account gone inactive

• AI agents: With MCP, you can give AI agents access to your email sending infrastructure, which they can use to send emails triggered during their workflows

The pattern is the same for all 4 sources: something happens, and your system sends an email if you have a rule set up related to the action.

4 ways to send a triggered email

There are 4 main ways to send a triggered email, all offered by MailerSend. Our email API and SMTP relay server are the most commonly used methods, especially when it comes to adding transactional email sending to an app or website. You can also use our CLI and MCP server for specialist use cases. 

1. Sending a triggered email with API

Using an email API is a popular choice for adding triggered email sending to an app. You connect your app to MailerSend’s email sending infrastructure with one of MailerSend's SDKs and then use the API to trigger emails based on events. 

Using an API to connect to an external tool like MailerSend means you don’t have to run your own mail server and manage sending infrastructure. Instead, MailerSend handles delivery, authentication, and monitoring on your behalf.

This is important because deliverability can be a major blocker for transactional sending, and if you get it wrong, your emails won’t land in the inbox. MailerSend has a reliable infrastructure already set up, so your emails are more likely to land. 

MailerLite offers SDKs for PHP, Node.js, Python, Go, Ruby, and Java that you can install based on your chosen language. 

Plus, you can configure emails to be triggered based on pretty much any event in your app, and, with MailerSend, you can use templates to send the triggered emails and even accept inbound responses to these messages in your app. You can even use the MailerSend code examples from GitHub to set up sending faster.

This makes sending via API an extremely flexible way to send triggered emails. Check out our guide to learn more about sending emails using the MailerSend API. 

2. Sending a triggered email over SMTP

SMTP is a well-established way to send email and is the protocol most mail servers and libraries already speak. 

It’s easy to get started with SMTP if the application you want to enable email sending for already supports SMTP sending or if you're already using a mailing package like nodemailer, smtplib, Jakarta Mail, or PHPmailer. 

For example, many WordPress plugins let you send emails via SMTP by adding your credentials in the plugin’s settings and then configuring the relevant tools.

This familiarity is the main benefit: if you're already set up to use SMTP, you can get started extremely fast. Especially if you use MailerSend’s SMTP relay server, rather than hosting your own. Just generate the SMTP credentials and drop them into the settings for the tool you're using.

The tradeoff is that SMTP is more limited than an email API. Templates and advanced template personalization are typically API-only, so with SMTP, you're usually building the full email content yourself before sending. You can also run into email sending limits if the SMTP isn’t configured correctly. 

MailerSend offers an SMTP relay service you can drop into an existing setup with just a host, port, username, and password. Learn how to use our SMTP service here.

3. Sending a triggered email with the MailerSend CLI

An email command-line interface (CLI), like the one we recently released for MailerSend, lets you send email directly from the terminal, or from a script, without writing any integration code against an API. 

That makes it a good fit for triggers that live outside application code entirely, such as a deploy finishing, a CI/CD pipeline step passing, or a scheduled job completing. 

In these cases, the event is the pipeline step itself, and the CLI command is what fires in response. It’s the same pattern as the API examples earlier, just invoked as a shell command instead of an SDK call.

MailerSend's CLI is simple to use; just install it, go through the authentication process, and any triggered send becomes a single command callable from a script, a cron job, or a pipeline step. Get more instructions for using the CLI here.

The tradeoff is that there's no dynamic per-recipient personalization built into the command itself, which makes it unsuitable for an app that needs to fire many different triggered emails a day with per-user data. In this case, using an API remains the better fit.

4. Sending a triggered email with the MCP server

Email Model Context Protocol (MCP) servers connect your AI tool to your email sending platform, which lets AI assistants or automated agents call the same sending and management functions you'd otherwise reach via API or CLI. 

This means you can set up agents that trigger emails in response to certain actions. For example, you could create an agent that tests for code errors, and when it finds one, autonomously invokes the MailerSend MCP tool to send an email alert to your engineering team with the error stack trace. 

MCP servers don't introduce a new kind of trigger; they just offer a different way of accessing the MailerSend API. What changes is that an agent, not application code, decides what to do about it and calls the tool that sends the email.

See the MCP server docs and MCP use cases for the full list of available tools, including domain and webhook management, alongside sending.

So which path should you pick?

The four paths cover different situations more than they compete with each other. Here’s when you might want to choose each type of trigger:

1. API: Use an API when you want to build complex workflows and use advanced features like templates and inbound email routing

2. SMTP: Use SMTP for simple setups when SMTP credentials are supported, for example, WordPress sites or plugins and mailing libraries.

3. CLI: Use a CLI for system events like CI/CD pipelines, deploy hooks, scheduled jobs, or a quick one-off send.

4. MCP: Use MCP to send emails triggered by an agent or automated workflow. 

None of these ways to trigger emails is mutually exclusive. You might send transactional email through the API, use the CLI for internal deploy notifications, and have an agent using MCP to monitor the delivery of emails that the API sends.

Keeping triggered emails out of spam

Transactional emails often contain essential information, such as password reset links, so landing in the spam folder can have a hugely negative impact on your customer experience. 

With that in mind, you need to take real steps to ensure your emails get delivered. The best thing you can do is use a service with a reliable sending infrastructure like MailerSend, which has automated authentication, a deliverability team, premium shared IPs that are already warm, built-in deliverability tools, and activity logs that let you catch problems early.

Beyond that, here are some tips you can use to keep your triggered emails out of spam: 

• Authenticate your domain with SPF, DKIM, and DMARC: This ensures receiving servers can verify the message actually came from you

• Keep transactional and marketing emails separate: Marketing emails tend to have lower engagement than transactional ones. Sending them from a different domain and IP from your transactional emails ensures that a drop in marketing engagement doesn’t hurt your transactional emails

• Warm up your domain and IP address: Start by sending a low volume of emails and then ramp up gradually to help your IP address and domain build trust

• Prepare for sending spikes: If you need to send a large volume of emails, be sure to prepare for this increase by properly warming up your domain and IP, batching and queuing emails, and using the Precedence: Bulk header to tell Gmail that your email was intentionally sent to multiple recipients

Also, be sure to keep an eye on your deliverability metrics, such as bounce rate and spam complaints, and use DMARC monitoring to track sending activity on your domain. This will help you spot any issues that do occur as soon as they happen.

Types of triggered emails by industry

Here is a look at the most common types of triggered emails for SaaS, e-commerce and agencies. 

SaaS

There are many reasons to send triggered emails for SaaS, for everything from account management to security and retention. Here are some of the most common types of emails.

• Account and authorization: Email verification, welcome emails, password resets, 2FA or OTP codes, new device or login alert, account deletion confirmations

• Billing and subscription: Trial notifications, payment status messages, plan status messages, cancellation confirmations

• Usage and limits: Plan limit warnings, usage updates, usage milestone emails

• Team and account activity: Member notifications, role or permission changes, account activity, import or export updates, scheduled job status emails

• Security: Suspicious activity warnings, API key creation

• Retention: Inactivity nudges, win-back cancellations.

E-commerce

The most common types of triggered emails for e-commerce are based around ordering and delivery. Here’s a look at the most common types.

• Order lifecycle: Order confirmations, order updates, order cancellation, refund confirmation

• Fulfillment & shipping: Shipping confirmations, delivery notifications, delayed shipment alerts

• Product & inventory: Back-in-stock alerts, price-drop alerts on a saved item, low-stock warnings on cart items

• Post-purchase: Review and feedback requests, warranty or registration confirmations, subscription box renewal notices, replenishment reminders

• Account & authentication: Account creation, email verifications, password resets, guest-checkout order lookup links

• Support: Return or exchange status updates, support ticket updates.

Agencies

Agencies use triggered emails to help manage clients and billing. Here are some common kinds of emails to explore. 

• Client and workspace management: Client domain updates, client creation, client user invites, role or permission changes

• Billing and account: Client plan usage limit warnings, invoice emails, payment updates and confirmations

• Reporting and handoff: Client report delivery, monthly summaries, activity exports

• Security and access: API keys, suspicious login on a client account, access-audit notifications.

Choose the email trigger implementation path that suits your needs

With triggered emails, you can deliver essential emails to your users, clients or team at the exact moment they need them.

To set them up, choose the implementation path that matches your tech stack and the types of messages you want to send. For most apps, this means using the API, although SMTP, CLI and MCP can all be used for certain types of triggered emails. 

Whichever option you choose, choose MailerSend as your email sending partner, so you can work on your project without having to manage your email sending infrastructure on top of everything else.