BULK QA INFRASTRUCTURE

Bulk test email accounts with a reason for every batch.

Scale account coverage for release, compatibility, and workflow testing while keeping providers, scenarios, credits, results, and owners explainable.

Create accounts →See how it works

✓ Failed items use zero credits · No subscription

CREATE TASK

ProviderTest matrix

QuantityPlanned waves

Estimated totalCalculated first

Failed? Credits returned.

THE SHORT VERSION

Treat a large test pool as provider-specific waves with acceptance gates, not one maximum-size request that becomes difficult to reconcile.

Scale modelWaves

Pilot, review, then bounded expansion

Result formats3

JSON, CSV, and TXT workflows

Cost modelPrepaid

Provider-specific credits for successful output

100%credit-back guarantee

Successful accounts consume credits. Failed accounts do not. Any credits reserved for a failed item return to your MailMaker balance automatically.

Read the guarantee →

A request for 1,000 test accounts can hide several products, releases, providers, and retention rules. Segment it before execution so a failure or configuration mistake can be isolated without blocking unrelated coverage.

Each segment needs a provider, scenario family, environment, requested quantity, credit estimate, downstream destination, result owner, and expiration or review date. Aggregate totals should be derived from those records instead of replacing them.

Provider and address type
Release or environment
Scenario family
Quantity and concurrency
Result and retention owner

MailMaker currently prices Gmail and Yahoo at one credit per successful account, Outlook and Proton at two, and iCloud at three. Calculate each provider segment separately, then combine the approved totals for the overall test budget.

Keep pilot cost, planned production quantity, and bounded contingency as separate lines. Failed items consume zero credits, but replacement work should still require reconciliation and an approved unresolved quantity.

The pilot must use the same provider, request method, result format, storage destination, and test harness as the intended larger wave. Confirm that successful results are accepted, failures are understood, credentials stay within the approved boundary, and final credits reconcile.

Record a scale, pause, or stop decision. A successful account file without downstream acceptance is not enough evidence to expand the batch.

A workspace balance should not be the only protection against an incorrect request. Define maximum quantity per task, provider concurrency, daily credit use, maximum job age, and an owner who can pause later waves.

Expand only after the previous wave reaches a terminal state and its result has been reconciled. If one provider changes behavior, pause that segment without hiding the status of other providers.

Per-task quantity ceiling
Provider concurrency limit
Credit budget
Pause threshold
Manual stop owner

For every task, preserve requested, successful, failed, provider rate, charged credits, and returned credits. A partial result may still satisfy some scenarios and should not be discarded or ordered again automatically.

Ask the receiving test system which successful results it accepted. If a replacement is required, create a new approved task for the remaining scenarios or quantity and link it to the original task record.

Assign each retained account to a provider segment, scenario set, environment, and owner. Track whether it is available, in use, blocked, awaiting review, or retired without putting raw credentials in the tracking record.

Review the pool after each release. Remove unnecessary exports, retire accounts without a continuing purpose, and update the next batch using actual utilization rather than repeating the previous quantity by habit.

QUESTIONS

What teams ask before they start.

What is a bulk test email account pool?−

It is an owned set of provider accounts allocated to defined QA scenarios, environments, and lifecycle rules rather than an unstructured credential file.

Should all five providers receive the same quantity?+

No. Allocate quantity using customer distribution, scenario risk, parallel-test requirements, and previous defects. Equal volume does not guarantee useful coverage.

How should a large test-account request be divided?+

Separate it by provider, purpose, environment, owner, and retention rule, then execute representative pilots and bounded waves.

How are failed items charged?+

Failed MailMaker items use zero credits. If credits were reserved while processing, the failed portion returns automatically, including within a partial task.

Can completed accounts be reused for regression testing?+

They can be retained when the approved scenario permits reuse and an owner controls state, access, recovery, review, and retirement. Clean-state tests may require a different fixture strategy.

READY WHEN YOU ARE

Credits in. Accounts out.

Start with the provider already selected. If an item fails, its credits return automatically.

Create your first task →

Bulk test email accounts with a reason for every batch.

Split the test pool by provider, purpose, environment, and owner.

Estimate the provider mix before approving the batch.

Prove the real export and test path before increasing volume.

Set quantity, credit, and concurrency ceilings outside the balance itself.

Replace only the unresolved test requirement.

Manage the pool after creation instead of losing it after export.

What teams ask before they start.

Credits in. Accounts out.

Bulk test email accounts with a reason for every batch.

Split the test pool by provider, purpose, environment, and owner.

Estimate the provider mix before approving the batch.

Prove the real export and test path before increasing volume.

Set quantity, credit, and concurrency ceilings outside the balance itself.

Replace only the unresolved test requirement.

Manage the pool after creation instead of losing it after export.

What teams ask before they start.

Build the complete workflow.

Credits in. Accounts out.