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
    });
    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 can send email using server-side templates (pass template variables instead of rendered HTML), manage recipient lists programmatically, query delivery status, and configure webhooks per message. The API also supports batch sending, where a single API call can address a message to multiple recipients with per-recipient variable substitution.

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 need specific API-only features like server-side templates, batch sending, or per-message webhook configuration.

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://api.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',
      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

Webhooks provide real-time notifications when delivery events occur. Instead of polling the API to check message status, QUEENSMTP pushes event data to your application's webhook endpoint as events happen. This enables you to build responsive features like delivery confirmation displays, bounce handling workflows, and engagement tracking without polling overhead.

QUEENSMTP supports webhooks for the following events: delivered (message accepted by recipient server), bounced (hard bounce or soft bounce), complained (recipient marked message as spam), opened (recipient opened the message), clicked (recipient clicked a link), and unsubscribed (recipient clicked an unsubscribe link). Each webhook payload includes the message ID, recipient address, timestamp, and event-specific metadata.

// Express.js webhook endpoint
app.post('/webhooks/email', express.json(), (req, res) => {
  const event = req.body;

  switch (event.type) {
    case 'delivered':
      console.log(`Delivered to ${event.recipient} at ${event.timestamp}`);
      break;
    case 'bounced':
      console.log(`Bounce: ${event.recipient} - ${event.bounce_type}`);
      // Remove invalid address from your database
      markEmailInvalid(event.recipient);
      break;
    case 'complained':
      console.log(`Complaint from ${event.recipient}`);
      // Unsubscribe the user to protect sender reputation
      unsubscribeUser(event.recipient);
      break;
  }

  res.status(200).send('OK');
});

Webhooks should be idempotent because QUEENSMTP may retry delivery if your endpoint does not respond with a 2xx status code within 10 seconds. Use the event ID to deduplicate events and ensure your processing logic can safely handle the same event multiple times without side effects.

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

The QUEENSMTP dashboard includes an interactive API playground where you can construct and send API requests directly from your browser. The playground auto-populates your credentials, provides request and response examples for every endpoint, and displays the equivalent cURL command for any request. This is the fastest way to explore the API and test specific functionality without writing code.

OpenAPI Specification

The QUEENSMTP REST API is documented with a complete OpenAPI 3.0 specification. You can import this specification into Postman, Insomnia, or any OpenAPI-compatible tool to generate a complete API client. The specification includes request and response schemas, authentication requirements, error codes, and examples for every endpoint. Auto-generated client libraries are available for TypeScript, Python, Go, and Rust from the OpenAPI spec.

Real-Time Event Stream

For developers building monitoring dashboards or real-time delivery tracking, QUEENSMTP provides a Server-Sent Events (SSE) stream that pushes delivery events as they occur. Connect to the event stream endpoint with your API key, and receive a continuous feed of delivery, bounce, open, click, and complaint events in JSON format. This is simpler than configuring webhooks for real-time monitoring use cases.

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.