Sandbox mode

Test your integration with deterministic mock responses. No credits consumed, no real SMTP connections.

How to enable

Add the X-Sandbox: true header to any verify request, alongside your normal API key. Use addresses ending in @test.mailsentry.dev.

curl -X POST https://mailsentry.dev/api/v1/verify \
  -H "Content-Type: application/json" \
  -H "X-API-Key: ms_live_your_key_here" \
  -H "X-Sandbox: true" \
  -d '{"email": "disposable@test.mailsentry.dev"}'

Sandbox calls don't count toward your monthly quota. The response includes an X-Sandbox: true header so you can confirm the mock path was taken.

If you send a non-@test.mailsentry.dev email in sandbox mode, the API returns a 400 error listing all available test addresses.

Test addresses

Each address returns a specific, predictable response:

Address	Score	Verdict	What it triggers
`valid@test.mailsentry.dev`	95	valid	Clean address — happy path
`invalid@test.mailsentry.dev`	10	invalid	No MX records, SMTP failure
`disposable@test.mailsentry.dev`	15	invalid	Disposable provider
`role@test.mailsentry.dev`	75	caution	Role-based address
`spamtrap@test.mailsentry.dev`	20	risky	Honeypot pattern
`catchall@test.mailsentry.dev`	85	valid	Catch-all domain (name-like local part)
`typo@test.mailsentry.dev`	85	valid	Returns a typo suggestion

Any other @test.mailsentry.dev address defaults to a clean "valid" response.

Sample response

A sandbox call to valid@test.mailsentry.dev returns:

{
  "email": "valid@test.mailsentry.dev",
  "score": 95,
  "verdict": "valid",
  "recommendation": "Safe to send",
  "verification_level": "confirmed",
  "verification_depth": "standard",
  "warning": null,
  "response_time_ms": 12,
  "checks": {
    "syntax": { "valid": true },
    "mx_records": { "valid": true, "records": ["mx1.test.mailsentry.dev"] },
    "disposable": { "is_disposable": false },
    "role_based": { "is_role_based": false },
    "free_provider": { "is_free": false, "name": null },
    "typo": { "has_typo": false, "suggestion": null },
    "smtp": { "valid": true, "catch_all": false },
    "gibberish": { "is_gibberish": false, "score": 0 },
    "spam_trap": { "is_potential_trap": false, "type": null },
    "domain_age": { "domain_created": "2026-01-01T00:00:00Z", "age_days": 90 },
    "abuse": { "is_toxic": false, "type": null }
  }
}

The response shape is identical to a live call — all 11 checks are present. This makes it safe to build and test your parsing logic against sandbox data, then switch to production with zero code changes.

When to use sandbox

Building your integration. Write and test all your error handling, UI states, and business logic without using real credits.
CI/CD pipelines. Include sandbox calls in your test suite to verify your integration still works after code changes.
Demos. Show stakeholders how validation works without burning credits or depending on real mail servers.

← Email Finder

Authentication →