14-day free trial on every plan
Every test run gets its own inbox. Signup links, OTP codes and receipts land in it within seconds — parsed, extracted and ready to assert on. Nothing is ever delivered to a real person.
acme / inboxes/ci-run-4187Your login code is 481-330
otp@acme.devvia Amazon SESto ci-run-4187@acme.mailqa.ioreceived 0.8s after send
Acme
Your login code
Enter this code to finish signing in. It expires in 10 minutes.
481 330
If you did not request this code, you can ignore this email.
Verify your email address
Acme <noreply@acme.dev>via Postmarkto ci-run-4187@acme.mailqa.ioreceived 0.8s after send
Acme
Verify your email address
Thanks for signing up. Confirm this address to finish creating your account.
Verify email
This link expires in 24 hours. If you did not create an account, ignore this email.
// how it works
Three steps and no infrastructure. Point your app at mailQA once, and every email it sends becomes data your tests — and your team — can read.
01 · your app sends
Send to an address on your subdomain over the public internet, or point SMTP at the sink with your organization's credentials. Keep SendGrid, Postmark, SES or Resend as they are.
// or send to qa@acme.mailqa.io
02 · mailQA catches and extracts
MIME parsed, SPF, DKIM and DMARC verified on arrival, links and one-time codes extracted. The raw .eml is kept as the source of truth, and nothing is forwarded anywhere.
Verify your email address
noreply@acme.dev · via Postmark · 0.8s
codes[]links[]spf · dkim · dmarc
03 · your test asserts
waitForLink() and waitForCode() resolve the moment the message lands and reject with a typed timeout if it never does. The team watches the same inbox fill up live in the dashboard.
// 14 days free
Create an inbox from your test and automate the entire email workflow — signup, verification, one-time codes, resets, invites. The first 14 days are free.
// why mailQA
Flaky waits, mail escaping to a real customer, having to change the mailer, and nobody but the test seeing what arrived. Each one has an answer in the product, not in a workaround.
waitForLink() and waitForCode() resolve the moment mail lands — typically well under a second. Your suite stops polling a mail log and hoping.
mailQA captures and stops. A misconfigured staging environment cannot email a customer through it — on any plan, ever.
Stay on SendGrid, Postmark, SES or Resend. Send to anyone@your-org.mailqa.io — or point SMTP at the sink — and nothing else changes.
Rendered HTML, plain text, raw .eml, headers and auth verdicts, streamed to the dashboard as they arrive over server-sent events. Everyone in the organization sees every inbox.
SPF, DKIM and DMARC are checked the moment a message lands on the MX address, and the verdicts sit next to the parsed body in the API and the dashboard.
A real MX address on your subdomain, or the SMTP sink that catches everything your app sends in local dev, CI and staging. Both land in the same inbox model.
// in your test suite
One import. The test creates its own inbox, drives your app normally, and gets the email back as data — no shared mailbox, no sleep(), no message left over from the last run.
tests/signup.spec.ts· @playwright/test
const inbox = await mailqa.inboxes.create({ name: 'signup' });
await page.goto('https://example.com/signup');
await page.fill('[name="email"]', inbox.address);
await page.click('button[type="submit"]');
const link = await mailqa.waitForLink({ inbox: inbox.id });
await page.goto(link);
await expect(page.getByText('Email verified')).toBeVisible();cypress/e2e/signup.cy.ts· cy.task
// the mailqa:* tasks are registered in cypress.config.ts
cy.task<Inbox>('mailqa:createInbox', 'signup').then((inbox) => {
cy.visit('/signup');
cy.get('[name="email"]').type(inbox.address);
cy.get('button[type="submit"]').click();
cy.task<string>('mailqa:waitForLink', { inbox: inbox.id })
.then((link) => cy.visit(link));
cy.contains('Email verified').should('be.visible');
});scripts/verify-email.sh· REST /v1 from any language
API=https://api.mailqa.io/v1
AUTH="Authorization: Bearer $MAILQA_API_KEY"
inbox=$(curl -sf -X POST $API/inboxes -H "$AUTH" \
-H 'Content-Type: application/json' -d '{"name": "signup"}')
id=$(jq -r .id <<<"$inbox")
# sign up with $(jq -r .address <<<"$inbox"), then wait:
latest="$API/inboxes/$id/messages?limit=1"
until msg=$(curl -sf "$latest" -H "$AUTH" | jq -er '.data[0].id')
do sleep 1; done
curl -sf "$API/messages/$msg" -H "$AUTH" \
| jq -r '.links[].url | select(test("/verify"))'@mailqa/clientPlaywright guide →✓ 1 passed (1.2s)
// pricing
Every plan starts with a 14-day free trial. Cancel before it ends and you pay nothing — and there is no mail infrastructure to tear down either.
One project, a small suite.
$4.99/ mo
billed monthly
Start free trialTeams testing email flows every day.
$9.99/ mo
billed monthly
Start free trialMany environments, a large team.
$19.99/ mo
billed monthly
Start free trial// questions
A mail server that captures instead of delivering. Your application sends email to mailQA rather than to a real mailbox; you read what arrived in a dashboard and assert on it from a test suite. Nothing is ever forwarded or relayed onward, so a misconfigured staging environment cannot reach a real customer through it.
Two ways, one inbox model. Point your app at the SMTP sink — smtp.mailqa.io, port 587 or 2525, with your organization’s credentials — and everything it sends is captured, whoever the recipient is. Or let it send to a real address on your subdomain, qa@your-org.mailqa.io, over the public internet. Both land in the same inbox and read identically. On Pro and above that address can be on a domain of your own — qa@test.yourcompany.com — by adding a single MX record.
Use the @mailqa/client SDK. waitForMessage, waitForCode and waitForLink are promises that resolve the moment a matching message lands and reject with a typed timeout if it never does — so a test is as fast as your app is, and a failure says what was being waited for. The waiting semantics and the runner recipes are in the SDK guide.
No. mailQA captures and stops; there is no forwarding path and no relay to enable. It is for the environments you test in — local development, CI and staging — and the Acceptable Use Policy says so explicitly.
// get started
No servers. No DNS. No mail infrastructure to run — and nothing ever delivered by mistake.
14-day free trial · cancel anytime · $0 today