Custom Domains for QA & Automated Testing — Best Practices

Why Standard Temp-Mail Fails in Testing

If your staging environment or SaaS under test blocks known disposable email domains, your test suite breaks before it even starts. Custom domains solve this because:

Your domain is not on any public blocklist
Addresses look identical to production user emails
You control DNS — no dependency on third-party uptime
Each test can use a unique, deterministic address

Integration with CI/CD Pipelines

OpenInbox exposes a REST API that pairs perfectly with custom domains in your test harness. A typical flow:

# 1. Create an inbox on your custom domain
INBOX=$(curl -s -X POST https://api.openinbox.io/inbox \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domainId": "your-domain-uuid"}' | jq -r '.email')

# 2. Register a new user with that address
curl -X POST https://staging.yourapp.com/signup \
  -d "email=$INBOX&password=Test1234!"

# 3. Poll for the verification email
EMAIL_ID=$(curl -s "https://api.openinbox.io/emails/$INBOX_ID" \
  -H "Authorization: Bearer $API_KEY" | jq -r '.[0].id')

# 4. Extract the OTP or verification link
OTP=$(curl -s "https://api.openinbox.io/email/$EMAIL_ID" \
  -H "Authorization: Bearer $API_KEY" | jq -r '.otp_codes[0]')

# 5. Complete verification
curl -X POST https://staging.yourapp.com/verify \
  -d "email=$INBOX&code=$OTP"

Because the address sits on your own domain, no disposable-email blocklist can interfere. The inbox expires after the test, leaving no state to clean up.

Best Practices

Use a dedicated testing subdomain

Point test.yourdomain.com at OpenInbox so your primary domain stays on your production mail provider.

Generate unique prefixes per test run

Prefix addresses with the CI job ID (e.g. [email protected]) to avoid collisions in parallel runs.

Set short inbox lifetimes

Use the shortest expiry your plan allows. Shorter lifetimes mean less data sitting around after tests complete.

Monitor your monthly quota

The usage API endpoint returns your current email count — add an assertion in CI to fail early if you approach the limit.

Test multiple roles in one suite

Create separate inboxes for admin, user, and support roles — all on the same domain, all disposable.

Custom Domain vs. Shared Domain for Testing

Feature	Shared Domain	Custom Domain
Accepted by blocklists	Often blocked	Never blocked
Looks like real email	No	Yes
DNS control	None	Full
Subdomain support	No	Yes
DKIM signing	Shared key	Your own keys
Parallel CI safety	Possible collisions	Deterministic

Level Up Your Testing Workflow

Connect your domain and start testing with real-looking, auto-expiring inboxes — starting at $3/month.

Get Started