You can send email from any MailSlurp inbox you create in the dashboard or API. This guide covers the practical sending paths teams use in production: direct API sends, recipient controls, attachment handling, template sends, and delivery protections.

Free plans have destination restrictions for some common consumer domains (for example Gmail and Yahoo) to reduce abuse risk. See free-plan limits when validating your test matrix.

Quick start

The smallest possible send call only needs an inbox and at least one recipient:

That pattern is enough for smoke tests and low-friction integration checks. For release-grade delivery, add headers, template variables, verification, and queue controls.

Choose your sending path

Use this rule of thumb before adding complexity:

  • API send first: best default for deterministic test automation and observability.
  • SMTP send when required: useful when validating an application that already sends over SMTP.
  • Template send for transactional workflows: password reset, OTP, notifications, and account lifecycle mail.

If your team is deciding between transports, use SMTP vs HTTP email APIs.

Sender identity and reply behavior

MailSlurp uses the inbox address as the default and . You can override headers, but most teams should keep sender identity stable and set display name on the inbox for better deliverability and trust.

Recipients: to, cc, and bcc

Send calls support recipient arrays. Keep recipient generation explicit in tests so failures are easy to trace.

Recipient formats:

  • Plain:
  • Named:

For localized addresses, use internationalized email guidance.

Subject and content

Use meaningful subjects so test assertions and support triage can classify traffic quickly.

For HTML emails, set and keep a text equivalent where possible.

Attachments

Upload file content first, then pass attachment IDs in your send call.

In Node.js, encode binary files to base64 before upload:

Bounce and deliverability protection

Delivery quality depends on recipient hygiene and sender behavior. Use these controls in production pipelines:

  • Validate recipients before high-volume sends.
  • Filter known-bad recipients at send time.
  • Track bounces and complaints with webhooks.
  • Gate release jobs when rejection rates spike.

Filter bounced recipients automatically:

Pre-validate email addresses:

Validate during send and enforce policy (filter or fail):

For incident response patterns, review reduce email bounces with webhooks and deliverability testing.

Queue-backed and scheduled sending

When a workflow must tolerate transient failures, use queue-backed sends and retries instead of synchronous-only delivery.

Queue-backed sending:

Send later using schedule controls:

See send email later for delayed and batch scheduling patterns.

Templates and variables

Templates are useful when product, QA, and support teams need a shared source of truth for email bodies.

Create a template:

Define variables with handlebars syntax:

Send with runtime values:

MailSlurp validates missing or mismatched variables, which helps prevent broken releases.

Send to contacts and groups

If you maintain audience objects in MailSlurp, use contact and group sending primitives:

Practical checklist before production rollout

  • Verify SPF, DKIM, and DMARC for your sender domain.
  • Test the full flow in Email Sandbox before sending from your app.
  • Add webhooks for delivery, bounce, and complaint events.
  • Run integration email tests for signup, reset, and notification paths.
  • Keep a recipient validation and suppression strategy in place.

Next steps