Email and SMS deliverability load testing helps you validate that messages are actually received when you send to many recipients at once. Instead of checking one inbox or one phone at a time, MailSlurp can monitor large sets of inboxes and phone numbers in a single run and show exactly what matched or failed.

If your team is testing bulk campaigns, OTP rollouts, alerts, or transactional flows, this gives you faster feedback than manual spot checks and much better coverage than ad hoc sms testing or single-inbox checks.

Quick answer

MailSlurp deliverability tests let you:

  • Scope a test to inboxes or phone numbers
  • Select all assets, a pattern-based subset, or explicit IDs
  • Define expected message counts and metadata expectations
  • Track progress while traffic is running (matched, unmatched, completion percentage, runtime)
  • See which assets are missing expected messages
  • Export results for analysis and reporting

This is useful for both email deliverability testing and sms deliverability verification in one workflow.

What this feature is for

Think of this as practical email load testing plus inbound message verification.

You create a test in MailSlurp, then run traffic from your own system (app backend, notification service, campaign platform, or test harness). MailSlurp evaluates what arrived for each target inbox or phone number against your expectations.

This is especially useful when you need:

  • testing email deliverability across many recipients before a launch
  • Inbox placement testing and seed list testing style checks for campaign reliability
  • sms delivery testing for OTP, alerts, and user notifications
  • A single dashboard for pass/fail status across many assets

Before you start

  1. Make sure you have enough inboxes or phone numbers for your test scope.
  2. Decide what success means per asset (for example, each target must receive at least one matching message).
  3. Prepare your sending system so it can send traffic to the selected email addresses or phone numbers during the test window.

Helpful setup guides:

How to create a deliverability test in the web app

Open https://app.mailslurp.com/test/deliverability and create a new test.

MailSlurp deliverability test creation screen

1) Choose test scope

  • INBOX for email coverage
  • PHONE for SMS coverage

2) Choose selector type

  • ALL: include all assets in the selected scope
  • PATTERN: include assets matching a wildcard or naming pattern
  • EXPLICIT: include a specific list of asset IDs

Use ALL for broad baseline coverage and PATTERN when you segment by environment, team, or naming convention.

3) Set expectations

For each expectation, define:

  • minCount: minimum number of matching messages expected per selected asset
  • Optional matchers: from, to, and subject (subject is email-only)

Use strict expectations for release gates and looser expectations for exploratory checks.

4) Configure timing

  • Start now or schedule a start time
  • Set a maximum runtime for the test window

5) Start and run traffic

Start the test, then execute your sender workflow (campaign send, transactional trigger, OTP flow, or load harness).

6) Monitor progress and inspect gaps

While running, monitor:

  • Status (CREATED, RUNNING, PAUSED, COMPLETE, FAILED, etc.)
  • Completion percentage
  • Matched vs unmatched entity counts
  • Runtime and last evaluation time

Use the unmatched view to find exactly which inboxes or phone numbers missed expected messages.

Deliverability test unmatched entities view

Scenario 1: Test inbound SMS at scale with phone numbers

Use case: your platform sends OTP or alert SMS to many users and you need high confidence in inbound receipt before release.

  1. Scope: PHONE
  2. Selector:
    • ALL for full fleet checks, or
    • PATTERN to target a subset (for example a staging naming pattern)
  3. Expectation:
    • minCount: 1
    • optional from matcher for the expected sender identity
  4. Runtime:
    • enough time for your send batch plus delivery lag buffer

Execute

  1. Start the deliverability test.
  2. Trigger your OTP or notification batch in your system.
  3. Watch unmatched phone numbers in real time.
  4. Export unmatched results and hand them to delivery/SRE teams for route investigation.

This pattern is a practical way to move from one-off sms testing to repeatable sms deliverability checks with auditability.

Scenario 2: Test inbound email with inboxes

Use case: you are validating transactional email (verification, reset, billing, alerts) across many test inboxes.

  1. Scope: INBOX
  2. Selector:
    • ALL for broad regression coverage, or
    • PATTERN for targeted cohorts (for example release-*)
  3. Expectations:
    • minCount: 1
    • from: expected sender address/domain
    • to: expected recipient target shape
    • subject: expected subject value for the workflow

Execute

  1. Start the test from /test/deliverability.
  2. Trigger your transactional sends from the app or pipeline.
  3. Monitor completion and focus on unmatched inboxes.
  4. Use per-entity expectation details to identify whether the issue is sender, routing, or template-level targeting.

This gives teams stronger email deliverability testing coverage than checking only a few test addresses manually.

API workflow (TypeScript, inbox-scoped)

If you want to run the same flow in automation, use the Deliverability Test API in four stages:

  1. Create an inbox-scoped deliverability test.
  1. Start the test before triggering your send batch.
  1. Poll or wait until the run is complete.
  1. Fetch and inspect results, including unmatched entities.

Reading results and exporting for analysis

After or during the run:

  1. Filter results by matched and unmatched entities.
  2. Inspect per-entity expectation outcomes (actualCount vs minCount).
  3. Export results for spreadsheet or BI analysis.
  4. Track run duration and failure reasons for trend reporting.

A useful operating model is to keep historical exports by release so you can compare reliability over time and catch regressions quickly.

Deliverability test results and summary view

Common mistakes to avoid

  • Setting expectations before confirming test traffic is actually being sent.
  • Using a selector that resolves to too few assets to be meaningful.
  • Running tests with no runtime buffer for message lag.
  • Treating "sent" as success without checking inbound receipt.
  • Ignoring unmatched exports instead of closing the loop with remediation owners.

FAQ

What is the difference between send testing and deliverability testing?

Send testing confirms your system attempted to send. Deliverability testing confirms expected messages were actually received by target inboxes or phone numbers.

Is this useful for inbox placement testing and seed list testing?

Yes. Teams can use scoped inbox sets as seed groups and evaluate which recipients received expected traffic, which supports inbox placement testing workflows.

Can I use this for both email and SMS in one place?

Yes. The same feature supports inbox (INBOX) and phone (PHONE) scopes so teams can run consistent processes for both channels.

Does this replace deep content assertions?

No. This feature is best for receipt and expectation coverage at scale. Pair it with content/template assertions in your automated test suites when needed.

Next steps