SMTP for Developers: Send Email from Any Application

Why Developers Need a Dedicated SMTP Provider

Every application that interacts with users needs to send email. Registration confirmations, password resets, notification digests, invoices, alerts, and reports all depend on reliable email delivery. Yet email is one of the most challenging parts of application infrastructure to get right. The SMTP protocol is decades old, deliverability depends on dozens of factors outside your code, and debugging email issues in production is notoriously difficult.

Using a third party SMTP service like QUEENSMTP eliminates the infrastructure burden so you can focus on building your application. You do not need to configure and maintain a mail server, manage IP reputation, handle bounce processing, implement retry logic, or worry about blacklisting. The SMTP provider handles all of this, exposing a simple interface: connect to our SMTP server, authenticate, send your message, and we deliver it.

A free SMTP server for developers is essential during the development and testing phases. You need to send real emails to verify your templates render correctly, your transactional triggers fire at the right time, and your email content passes spam filters. But you do not want test emails reaching real users or consuming production sending quotas. QUEENSMTP provides a free sandbox environment that captures all outgoing email for inspection without delivering it to recipients, giving you a safe space to develop and test your email functionality.

Beyond the development phase, a dedicated SMTP provider gives you production infrastructure that scales with your application. As your user base grows from hundreds to millions, your email volume grows proportionally. A third party SMTP server for development that also handles production traffic means you never need to migrate your email integration between environments. The same code, configuration, and credentials work from your first test email to your millionth production delivery.

QUEENSMTP Developer Experience

QUEENSMTP is built by developers for developers. Every aspect of the platform is designed to minimize the time between signing up and sending your first email, while providing the depth of functionality and observability that experienced developers expect in production.

Free Sandbox Environment

Every QUEENSMTP account includes a free sandbox that accepts and captures email without delivering it to recipients. The sandbox records every message with full headers, rendered HTML preview, plain text content, and attachment metadata. You can inspect captured emails through the dashboard or retrieve them via API, making it easy to verify your email integration during development. The sandbox supports up to 500 emails per day at no cost, with no credit card required.

Quick Setup

From account creation to sending your first email takes less than five minutes. Sign up, copy your SMTP credentials from the dashboard, configure your application with the host (smtp.queensmtp.com), port (587), and credentials, and send. There is no mandatory domain verification for sandbox mode, no waiting for account approval, and no configuration wizard to click through. Developers who want to test immediately can do so within minutes of creating an account.

SDKs and Libraries

QUEENSMTP provides official SDKs for Node.js, Python, PHP, Ruby, Java, Go, and C#. Each SDK wraps both the SMTP and REST API interfaces with idiomatic code for each language. SDKs handle connection management, authentication, retry logic, and error handling, so you can send email with a single function call. All SDKs are open source, published to their respective package managers (npm, PyPI, Composer, RubyGems, Maven, Go modules, NuGet), and include comprehensive documentation with examples.

SMTP Integration Guide: All Major Languages

Integrating QUEENSMTP into your application is straightforward regardless of your programming language. Below are complete, working code examples for the most popular languages. Each example demonstrates connecting to the SMTP server, authenticating, and sending a basic email.

Node.js (using Nodemailer)

Nodemailer is the standard email library for Node.js applications. Install it with npm install nodemailer and configure the SMTP transport with your QUEENSMTP credentials.

const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  host: 'smtp.queensmtp.com',
  port: 587,
  secure: false, // STARTTLS
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  },
  pool: true,        // enable connection pooling
  maxConnections: 5, // reuse up to 5 connections
  maxMessages: 100   // send 100 messages per connection
});

async function sendEmail(to, subject, html) {
  try {
    const info = await transporter.sendMail({
      from: '"My App" <noreply@example.com>',
      to: to,
      subject: subject,
      html: html,
      // Bulk or marketing mail: set these and we pass them through unchanged.
      // Gmail, Yahoo and Outlook look for List-Unsubscribe, and mail without
      // it is far more likely to be refused as unsolicited.
      headers: {
        'List-Unsubscribe': '<https://example.com/unsubscribe?id=SUBSCRIBER_ID>, <mailto:unsubscribe@example.com>',
        'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click'
      }
    });
    console.log('Message sent:', info.messageId);
    return info;
  } catch (error) {
    console.error('Send failed:', error.message);
    throw error;
  }
}

// Usage
sendEmail('user@example.com', 'Welcome!', '<h1>Welcome to our app</h1>');

Python (using smtplib)

Python's built-in smtplib module provides everything you need to send email through an SMTP server for development and production. No additional packages are required.

import smtplib
import os
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

def send_email(to_addr, subject, html_body):
    msg = MIMEMultipart('alternative')
    msg['From'] = 'noreply@example.com'
    msg['To'] = to_addr
    msg['Subject'] = subject
    msg.attach(MIMEText(html_body, 'html'))

    try:
        with smtplib.SMTP('smtp.queensmtp.com', 587) as server:
            server.starttls()
            server.login(
                os.environ['SMTP_USER'],
                os.environ['SMTP_PASS']
            )
            server.send_message(msg)
            print(f'Email sent to {to_addr}')
    except smtplib.SMTPException as e:
        print(f'Failed to send email: {e}')
        raise

# Usage
send_email('user@example.com', 'Welcome!', '<h1>Welcome</h1>')

PHP (using PHPMailer)

PHPMailer is the most popular email library for PHP. Install it with composer require phpmailer/phpmailer and configure it with your QUEENSMTP SMTP credentials.

use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

require 'vendor/autoload.php';

function sendEmail($to, $subject, $htmlBody) {
    $mail = new PHPMailer(true);
    try {
        $mail->isSMTP();
        $mail->Host       = 'smtp.queensmtp.com';
        $mail->SMTPAuth   = true;
        $mail->Username   = getenv('SMTP_USER');
        $mail->Password   = getenv('SMTP_PASS');
        $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
        $mail->Port       = 587;

        $mail->setFrom('noreply@example.com', 'My App');
        $mail->addAddress($to);
        $mail->isHTML(true);
        $mail->Subject = $subject;
        $mail->Body    = $htmlBody;

        $mail->send();
        echo "Email sent to {$to}\n";
    } catch (Exception $e) {
        echo "Send failed: {$mail->ErrorInfo}\n";
        throw $e;
    }
}

// Usage
sendEmail('user@example.com', 'Welcome!', '<h1>Welcome</h1>');

Ruby (using Net::SMTP)

Ruby's standard library includes Net::SMTP for sending email. For production applications, the mail gem provides a higher-level API with MIME support and template rendering.

require 'net/smtp'

def send_email(to, subject, body)
  message = <<~MESSAGE
From: My App <noreply@example.com>
To: #{to}
Subject: #{subject}
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

#{body}
  MESSAGE

  Net::SMTP.start(
    'smtp.queensmtp.com', 587,
    'example.com', ENV['SMTP_USER'], ENV['SMTP_PASS'],
    :login
  ) do |smtp|
    smtp.enable_starttls
    smtp.send_message(message, 'noreply@example.com', to)
    puts "Email sent to #{to}"
  end
rescue Net::SMTPError => e
  puts "Send failed: #{e.message}"
  raise
end

# Usage
send_email('user@example.com', 'Welcome!', '<h1>Welcome</h1>')

Go

Go's standard library net/smtp package provides SMTP client functionality. For production use, consider the gomail package which adds connection pooling and MIME support.

package main

import (
    "fmt"
    "net/smtp"
    "os"
)

func sendEmail(to, subject, body string) error {
    from := "noreply@example.com"
    user := os.Getenv("SMTP_USER")
    pass := os.Getenv("SMTP_PASS")

    msg := fmt.Sprintf("From: %s\r\nTo: %s\r\nSubject: %s\r\n"+
        "MIME-Version: 1.0\r\nContent-Type: text/html; charset=UTF-8\r\n\r\n%s",
        from, to, subject, body)

    auth := smtp.PlainAuth("", user, pass, "smtp.queensmtp.com")
    err := smtp.SendMail(
        "smtp.queensmtp.com:587",
        auth,
        from,
        []string{to},
        []byte(msg),
    )
    if err != nil {
        return fmt.Errorf("send failed: %w", err)
    }
    fmt.Printf("Email sent to %s\n", to)
    return nil
}

func main() {
    sendEmail("user@example.com", "Welcome!", "<h1>Welcome</h1>")
}

Java (using Jakarta Mail)

import jakarta.mail.*;
import jakarta.mail.internet.*;
import java.util.Properties;

public class EmailSender {
    private static Session createSession() {
        Properties props = new Properties();
        props.put("mail.smtp.host", "smtp.queensmtp.com");
        props.put("mail.smtp.port", "587");
        props.put("mail.smtp.auth", "true");
        props.put("mail.smtp.starttls.enable", "true");

        return Session.getInstance(props, new Authenticator() {
            protected PasswordAuthentication getPasswordAuthentication() {
                return new PasswordAuthentication(
                    System.getenv("SMTP_USER"),
                    System.getenv("SMTP_PASS")
                );
            }
        });
    }

    public static void sendEmail(String to, String subject, String html)
            throws MessagingException {
        Session session = createSession();
        MimeMessage message = new MimeMessage(session);
        message.setFrom(new InternetAddress("noreply@example.com"));
        message.setRecipient(Message.RecipientType.TO,
            new InternetAddress(to));
        message.setSubject(subject);
        message.setContent(html, "text/html; charset=UTF-8");
        Transport.send(message);
        System.out.println("Email sent to " + to);
    }
}

C# (.NET)

using System.Net;
using System.Net.Mail;

public class EmailService
{
    private readonly SmtpClient _client;

    public EmailService()
    {
        _client = new SmtpClient("smtp.queensmtp.com", 587)
        {
            Credentials = new NetworkCredential(
                Environment.GetEnvironmentVariable("SMTP_USER"),
                Environment.GetEnvironmentVariable("SMTP_PASS")
            ),
            EnableSsl = true
        };
    }

    public async Task SendEmailAsync(string to, string subject, string html)
    {
        var message = new MailMessage
        {
            From = new MailAddress("noreply@example.com", "My App"),
            Subject = subject,
            Body = html,
            IsBodyHtml = true
        };
        message.To.Add(to);

        try
        {
            await _client.SendMailAsync(message);
            Console.WriteLine($"Email sent to {to}");
        }
        catch (SmtpException ex)
        {
            Console.WriteLine($"Send failed: {ex.Message}");
            throw;
        }
    }
}

REST API vs SMTP Protocol for Developers

QUEENSMTP supports both SMTP protocol and REST API for sending email. Each approach has trade-offs that depend on your application architecture, language ecosystem, and specific requirements.

The SMTP protocol is universally supported. Every programming language has an SMTP library, and most application frameworks include built-in email functionality that speaks SMTP. Using SMTP means you can switch between email providers by changing configuration variables without modifying any code. This portability is valuable for applications that may need to change providers or support self-hosted deployments where customers bring their own SMTP credentials. For a deeper dive into API-based sending, see our Email API documentation.

The REST API provides richer functionality for applications that need it. With the API, you send a message as a JSON request, get back a message id, and query its delivery status by that id. Each request carries one recipient, which gives every message its own delivery status, unsubscribe link and tracking. Event webhooks are in development.

For most applications, the SMTP protocol is the right starting point. It is simpler to configure, universally compatible, and does not create a vendor dependency in your code. Move to the REST API when you want JSON requests, a message id and delivery status per send, and, once they ship, webhooks.

Testing Email in Development

Testing email during development requires capturing outgoing messages without delivering them to real recipients. Sending test emails to real addresses during development risks confusing users, violating anti-spam regulations, and consuming production sending quotas. There are several approaches to safely test email, and the best choice depends on your development workflow.

QUEENSMTP Sandbox Mode

The simplest approach is to use QUEENSMTP's sandbox mode. Configure your development environment with sandbox SMTP credentials, and all outgoing email is captured by QUEENSMTP without being delivered. You can inspect captured messages through the dashboard or API, including rendered HTML, headers, and metadata. This approach requires no additional tools and works with any application that sends email via SMTP.

Local Capture Tools

For offline development or when you want to capture email locally, tools like MailHog and Mailtrap provide a local SMTP server that captures all incoming email and displays it in a web interface. MailHog runs as a single binary or Docker container and is particularly popular for local development because it requires no account or internet connection. Configure your application to send to localhost:1025, and MailHog captures every message for inspection at localhost:8025.

# Run MailHog locally with Docker
docker run -d -p 1025:1025 -p 8025:8025 mailhog/mailhog

# Configure your app SMTP settings for development
SMTP_HOST=localhost
SMTP_PORT=1025
SMTP_USER=       # no auth needed for MailHog
SMTP_PASS=

Catch-All Redirect

Another approach is to configure your application to redirect all outgoing email to a single test address in development. This lets you test email delivery end-to-end while ensuring no test emails reach unintended recipients. Many email libraries support a "redirect all" or "intercept" mode that rewrites the To address before sending.

Environment-Based SMTP Configuration

A well-architected application uses different SMTP configurations for development, staging, and production environments. This ensures test emails never reach real users and production credentials are never exposed in development environments.

# .env.development
SMTP_HOST=localhost          # MailHog or local capture
SMTP_PORT=1025
SMTP_USER=
SMTP_PASS=
SMTP_FROM=dev@example.com

# .env.staging
SMTP_HOST=smtp.queensmtp.com
SMTP_PORT=587
SMTP_USER=staging_user       # Sandbox credentials
SMTP_PASS=staging_pass
SMTP_FROM=staging@example.com

# .env.production
SMTP_HOST=smtp.queensmtp.com
SMTP_PORT=587
SMTP_USER=prod_user          # Production credentials
SMTP_PASS=prod_pass
SMTP_FROM=noreply@example.com

Your application code should read SMTP configuration from environment variables and never hard-code credentials. This pattern works with every deployment platform (Docker, Kubernetes, Heroku, Vercel, AWS, etc.) and every secrets management system (HashiCorp Vault, AWS Secrets Manager, Doppler, etc.). The application behaves identically across environments; only the SMTP destination changes.

For staging environments, use QUEENSMTP sandbox credentials to capture email without delivery. This lets your QA team verify that production email workflows generate the correct messages with the correct content, recipients, and timing, all without any risk of test emails reaching real customers.

Serverless Email Sending

Serverless platforms like AWS Lambda, Vercel Functions, and Cloudflare Workers present unique challenges for SMTP because they are stateless, short-lived, and may not support persistent TCP connections. QUEENSMTP supports both SMTP and REST API, giving you flexibility to choose the best approach for your serverless architecture.

For AWS Lambda functions, the REST API is typically the better choice because HTTP requests complete quickly and do not require maintaining a persistent SMTP connection. Lambda functions have a maximum execution time, and SMTP connections that involve multiple round trips (EHLO, AUTH, MAIL FROM, RCPT TO, DATA, QUIT) consume more of that budget than a single HTTP POST request.

For Vercel and Cloudflare Workers, the REST API is the only practical option because these environments run on edge runtimes that do not support raw TCP connections required by the SMTP protocol. The QUEENSMTP REST API works with the standard fetch API available in all edge runtimes.

// Vercel Edge Function / Cloudflare Worker
export default async function handler(request) {
  const response = await fetch('https://queensmtp.com/v1/send', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.QUEENSMTP_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      from: 'noreply@example.com',
      fromName: 'Example Store',
      replyTo: 'support@example.com',
      to: 'user@example.com',
      subject: 'Your Order Confirmation',
      html: '<h1>Order Confirmed</h1><p>Thank you for your purchase.</p>'
    })
  });

  const result = await response.json();
  return new Response(JSON.stringify(result), { status: 200 });
}

Webhook Integration for Delivery Events (In Development)

Webhooks are being built and are not yet available. This section describes what is coming so you can plan for it; until it ships, read per-message status from GET /v1/messages/:id using the id returned by POST /v1/send, or use the dashboard message log.

When released, QUEENSMTP will POST one JSON event per occurrence to an HTTPS endpoint you register from the dashboard or the API: message.delivered, message.deferred, message.bounced (with an explicit bounceType of hard or soft), message.complained, message.opened, message.clicked, message.unsubscribed and message.rejected. Every event has the same shape: an id to deduplicate on, a type, a created timestamp, and a data object whose messageId is the id you received from /v1/send.

// Express.js endpoint for the upcoming webhook format
const crypto = require('crypto');

app.post('/webhooks/queensmtp', express.raw({ type: 'application/json' }), (req, res) => {
  // X-QueenSMTP-Signature: t=<unix>,v1=<hex HMAC-SHA256 of `${t}.${rawBody}`>
  const sig = Object.fromEntries(String(req.get('X-QueenSMTP-Signature') || '').split(',').map((p) => p.split('=')));
  const expected = crypto.createHmac('sha256', process.env.QUEENSMTP_WEBHOOK_SECRET)
    .update(`${sig.t}.${req.body}`).digest('hex');
  const fresh = Math.abs(Date.now() / 1000 - Number(sig.t)) < 300;
  if (!fresh || !crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(sig.v1 || ''))) {
    return res.status(401).send('bad signature');
  }

  const event = JSON.parse(req.body);
  switch (event.type) {
    case 'message.bounced':
      if (event.data.bounceType === 'hard') markEmailInvalid(event.data.to);
      break;
    case 'message.complained':
    case 'message.unsubscribed':
      unsubscribeUser(event.data.to);
      break;
  }
  res.status(200).send('OK');
});

Endpoints will need to be idempotent: delivery is retried with backoff for about 24 hours whenever your endpoint does not answer 2xx within 10 seconds, so the same id can arrive more than once. Deduplicate on it.

Headers, Bulk Mail and Unsubscribe over SMTP

The SMTP relay applies the same contract as the REST API. Each message goes to one recipient, may be up to 1 MB with at most two attachments (paid plans), and costs one credit. Your From must be an address on a verified sending domain; its display name, your Reply-To and your Subject are taken from the message. Identity and authentication headers — Message-ID, Date, DKIM, Feedback-ID, Auto-Submitted, X-Mailer — are set by QUEENSMTP and cannot be overridden.

Headers you may set pass through unchanged (up to 25 per message): List-Unsubscribe, List-Unsubscribe-Post, the other List-* headers, Precedence, In-Reply-To, References, Importance, X-Priority and any X- header except the platform's own X-QS-*. Anything else a mail client adds is dropped silently; the message still sends.

Declaring bulk. A List-Unsubscribe header or Precedence: bulk marks a message as marketing: it rides the marketing lane and is stamped Precedence: bulk. Everything else is treated as transactional and stamped Auto-Submitted: auto-generated, so do not add List-Unsubscribe to a password reset or an order confirmation.

Bulk mail must carry an unsubscribe. Send your own List-Unsubscribe together with List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058) and both pass through untouched; that link is never rewritten by click tracking. Send none and, if the domain has a verified and secured tracking host, QUEENSMTP attaches a one-click unsubscribe hosted on your tracking domain. With neither, the message is refused with 550 [UNSUBSCRIBE_HEADER_REQUIRED]. Either way an opt-out is honoured before the next send to that address.

From: Your Brand <news@yourdomain.com>
To: person@example.com
Subject: September update
List-Unsubscribe: <https://yourdomain.com/unsubscribe?u=42>, <mailto:unsubscribe@yourdomain.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Precedence: bulk

(body)

In code: Nodemailer headers: { 'List-Unsubscribe': '<https://…>', 'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click' }; PHPMailer $mail->addCustomHeader('List-Unsubscribe', '<https://…>');; Python msg['List-Unsubscribe'] = '<https://…>'.

Tracking is always on for single-recipient HTML mail from a domain with a secured tracking host: an open pixel on every message, links rewritten only on marketing mail (never the unsubscribe link and never transactional links), and the same URIs mirrored into the plain-text part so relay-side filters see matching parts. Your own tracking may stay alongside.

Replies. A refusal is a 550 whose text starts with the reason code in brackets, for example 550 [content_flagged] Rejected: message flagged as likely …; a 451 is temporary and should be retried. Refusals that recorded a strike say so in the same text. Every code is explained on the Developer API page of your dashboard, and every refused message appears in your message log with its reason.

Error Handling Best Practices

Robust error handling is essential for production email sending. SMTP errors fall into several categories, and each requires a different response strategy.

Connection errors (timeouts, DNS failures, TLS handshake failures) indicate a network issue between your application and the SMTP server. These are transient and should be retried with exponential backoff. Start with a 1-second delay, double it on each retry, and cap at 60 seconds. Limit total retries to 5 attempts before failing the send and alerting your operations team.

Authentication errors (535 response codes) indicate invalid credentials. Do not retry these; they will fail every time with the same credentials. Log the error, alert your team, and check that your SMTP credentials are correctly configured in your environment variables.

Recipient errors (550, 551, 552, 553 response codes) indicate a problem with the recipient address. Hard bounces (550 "user unknown") mean the address does not exist and should be removed from your database immediately. Soft bounces (452 "mailbox full") are temporary and the message can be retried later.

Rate limiting errors (421 or 450 response codes with "too many connections" or "rate limit exceeded" messages) mean you are sending too fast. Implement exponential backoff and reduce your concurrent connection count. If you consistently hit rate limits, contact QUEENSMTP support to discuss increasing your sending rate.

SMTP in CI/CD Pipelines

CI/CD pipelines often need to send email for deployment notifications, test reports, and alerting. Configuring SMTP in your pipeline is straightforward: store your QUEENSMTP credentials as pipeline secrets (environment variables), and use a command-line email tool or your application's email sending code to send messages during the pipeline run.

For simple notifications, command-line tools like swaks (Swiss Army Knife for SMTP) can send email directly from a pipeline step without any application code. For GitHub Actions, GitLab CI, and Jenkins, install swaks and use it to send a formatted notification at the end of your deployment pipeline.

# GitHub Actions - send deployment notification
- name: Send deployment notification
  env:
    SMTP_USER: ${{ secrets.SMTP_USER }}
    SMTP_PASS: ${{ secrets.SMTP_PASS }}
  run: |
    swaks --to ops@example.com \
          --from deploy@example.com \
          --server smtp.queensmtp.com:587 \
          --auth LOGIN \
          --auth-user "$SMTP_USER" \
          --auth-password "$SMTP_PASS" \
          --tls \
          --header "Subject: Deployed ${{ github.repository }} to production" \
          --body "Commit: ${{ github.sha }} by ${{ github.actor }}"

Email Testing in Automated Tests

Automated test suites should verify that your application sends the correct emails at the correct times without actually delivering messages. There are several strategies for testing email in automated tests, depending on the level of confidence you need.

Mock the SMTP transport: In unit tests, replace your email sending function with a mock that captures the arguments passed to it. This verifies that your application constructs the correct email (recipient, subject, body, headers) without any network calls. This is the fastest and most reliable approach for unit tests.

Use a local capture server: In integration tests, run MailHog in a Docker container alongside your application. Your tests send real emails through the SMTP transport, and then query the MailHog API to verify the captured messages. This tests the complete email sending path including SMTP connection, authentication, and message formatting.

Use the QUEENSMTP sandbox API: For end-to-end tests, send email through the QUEENSMTP sandbox and use the API to retrieve and verify captured messages. This tests the complete path through your production SMTP provider while ensuring no email is delivered to real recipients.

Developer-Friendly Features

QUEENSMTP includes several features specifically designed to improve the developer experience and accelerate email integration.

Detailed Logs

Every email sent through QUEENSMTP is logged with comprehensive detail: SMTP transaction log, authentication status, DNS lookup results, delivery attempts and responses, and final status. You can search logs by message ID, recipient, sender, subject, or date range. For debugging deliverability issues, the transaction log shows the exact SMTP conversation between our server and the recipient's mail server, including response codes and error messages.

API Playground

Your API keys, the full request and response reference, and the current limits live on the API page of your dashboard. That page is generated from the running service, so it is the authoritative reference — if anything here disagrees with it, believe the dashboard.

The whole API

There are two endpoints, both authenticated with Authorization: Bearer YOUR_API_KEY against https://queensmtp.com/v1:

• POST /v1/send — send one message. Fields: from, fromName, to, subject, html, text, replyTo, headers, isBulk.
• GET /v1/messages/:id — delivery status for a message you sent.

One recipient per request: send to a list by making one request per address. Set isBulk: true on marketing mail so it is routed and rate-limited as bulk, and so a one-click unsubscribe header is attached.

Production SMTP Best Practices

Moving from development to production requires attention to several best practices that ensure your email integration is reliable, performant, and resilient under load. Our SMTP server setup guide covers the full configuration process in detail.

Connection Pooling

Opening a new SMTP connection for every email is expensive. Each connection requires a TCP handshake, TLS negotiation, and SMTP authentication, which adds latency and consumes server resources. Connection pooling reuses established connections for multiple messages, dramatically reducing overhead. Most SMTP libraries support connection pooling: Nodemailer has the pool: true option, Java's Session object reuses connections, and Python's smtplib supports keep-alive connections. Configure your pool to maintain 3-10 connections depending on your sending volume.

Retry Logic

Implement exponential backoff with jitter for transient SMTP errors. A simple retry with fixed delays can cause thundering herd problems when many application instances retry simultaneously after a brief outage. Exponential backoff with random jitter spreads retry attempts over time, reducing load on the SMTP server and improving recovery. Use a maximum of 3-5 retry attempts for transient errors, and never retry permanent failures.

Rate Limiting

Even with unlimited SMTP plans, implement application-side rate limiting to prevent runaway processes from sending excessive email. A bug in a notification loop can generate millions of unwanted emails in minutes if there is no rate limit in place. Use a token bucket or sliding window rate limiter to cap your application's sending rate at a sensible maximum, and alert your team if the rate limit is consistently being hit, which indicates either a traffic spike or a bug.

Queue-Based Architecture

For high-volume applications, decouple email sending from your request handling path using a message queue. When your application needs to send an email, it enqueues a message to a queue (Redis, RabbitMQ, SQS, etc.) and returns immediately. A background worker process reads from the queue and sends the email via SMTP. This architecture prevents email sending latency from affecting your application's response times, provides natural retry handling through the queue's redelivery mechanism, and allows you to scale email sending workers independently of your web servers.

Monitoring and Alerting

Instrument your email sending code with metrics for send count, error count, error rate, and send latency. Track these metrics in your application monitoring system (Datadog, New Relic, Prometheus, etc.) and set alerts for anomalies. A sudden increase in error rate may indicate an SMTP configuration issue, a credential expiration, or a deliverability problem. A sudden increase in send volume may indicate a bug. Monitoring lets you detect and respond to these issues before they affect your users.