Email and SMS deliverability load testing with MailSlurp

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.

When you're sending a batch of OTPs, alerts or receipts, checking one successful message leaves a lot unanswered. This test shows which of your selected inboxes or phone numbers are still waiting.

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

What this feature is for

The test checks what arrives while your own system sends the traffic.

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.

Use it for:

• receipt checks across many recipients before a launch
• cohort-level receipt checks for campaign reliability
• SMS receipt checks for OTPs, 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:

• Create inboxes
• Receive SMS text messages
• Email testing explained

How to create a deliverability test in the web app

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

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.

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.

Recommended setup

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.

Scenario 2: Test inbound email with inboxes

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

Recommended setup

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.

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.

// Define an inbox-scoped deliverability test with explicit inbox targets and a minimum-count expectation.
const createdTest = await deliverabilityTestController.createDeliverabilityTest({
  createDeliverabilityTestOptions: {
    name: `deliverability-test-${Date.now()}`,
    description: 'admin-sdk deliverability progression test',
    scope: 'INBOX',
    selector: {
      type: 'EXPLICIT',
      entityIds: [inboxA.id!, inboxB.id!]
    },
    expectations: [
      {
        name: 'expect-1-each',
        minCount: 1
      }
    ],
    maxDurationSeconds: 300
  }
});
deliverabilityTestId = createdTest.id;

2. Start the test before triggering your send batch.

// Start the deliverability test so progress polling can begin.
const startedTest = await deliverabilityTestController.startDeliverabilityTest({
  testId: createdTest.id
});
expect(['SCHEDULED', 'RUNNING']).toContain(startedTest.status);

3. Poll or wait until the run is complete.

// Poll until the test reaches COMPLETE with all entities matched.
const completedPoll = await waitForDeliverabilityPoll(
  createdTest.id,
  (poll) =>
    poll.test.status === 'COMPLETE' &&
    poll.test.matchedEntities === 2 &&
    poll.test.unmatchedEntities === 0,
  240_000,
  currentStep
);
expect(completedPoll.test.completionPercentage).toEqual(100);

4. Fetch and inspect results, including unmatched entities.

// Fetch final result rows and verify each selected inbox satisfied the expectation.
const finalResults = await deliverabilityTestController.getDeliverabilityTestResults({
  testId: createdTest.id,
  size: 50
});
expect(finalResults.content.length).toEqual(2);
expect(finalResults.test.status).toEqual('COMPLETE');
expect(finalResults.test.matchedEntities).toEqual(2);
expect(finalResults.test.unmatchedEntities).toEqual(0);
expect(finalResults.content.map((result) => result.entityId).sort()).toEqual(
  [inboxA.id!, inboxB.id!].sort()
);

for (const result of finalResults.content) {
  expect(result.matched).toEqual(true);
  expect(result.matchedExpectationCount).toEqual(result.totalExpectationCount);
  expect(result.expectationResults.length).toEqual(1);
  expect(result.expectationResults[0].passed).toEqual(true);
  expect(result.expectationResults[0].actualCount).toBeGreaterThanOrEqual(1);
}

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.

Save each release's export so you can compare missing messages and run duration with the previous test.

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.
• Exporting missing-message results without assigning someone to investigate them.

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?

Use inbox placement testing to measure inbox, Promotions and spam outcomes at real provider seed accounts. This load-testing workflow checks receipt expectations across selected MailSlurp inboxes and phone numbers.

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

• MailSlurp documentation
• Email integration testing product
• Phone and SMS services

For framework setup and API lifecycle details, see load testing documentation and examples by task.