Unlimited test accounts on one catch-all domain

Why a mail provider is the wrong shape for QA

Every way of giving a test suite email addresses has been tried, and each one leaks in a different place:

The fourth row is this guide. It is the same mechanism the public disposable domains run on — a server that accepts every address on a domain rather than a list of mailboxes — applied to a name nobody but you is using.

The one DNS record

At your DNS provider, add a single MX record on the apex of a domain you own. No other record here, no TXT to prove anything, no account on this site:

MX record for the domain10 smtp.grabmail.ioCopy

1. Publish the MX. Priority 10, pointing at smtp.grabmail.io. Delete any other MX on the domain — mail can only be delivered to one place, and a leftover record sends part of it somewhere else.
2. Wait for DNS. Usually minutes; occasionally the TTL of whatever record was there before. dig MX qa-example.com shows when it has taken.
3. Send one message to any address on it. The first delivery is what connects the domain: the server looks the MX up at that moment, sees itself, and accepts. From then on every address on the domain is a mailbox.

A naming scheme that says who made the mailbox

With every address valid, the local part is free to carry information — and at two in the morning, with a failed run and a mailbox open, you will want it to. Three parts, joined by dashes, in this order:

// one helper, every runner: who made it, which run, and eight random characters
export const testAddress = (who: string, run = process.env.GITHUB_RUN_ID ?? 'local') =>
  `${who}-${run}-${crypto.randomUUID().slice(0, 8)}@qa-example.com`;

testAddress('signup');        // signup-1234567890-3f9a1c2e@qa-example.com

Reading any address, the same three calls

Nothing about the API changes for your own domain. The same listing call, the same message call, the same delete — no key on the public tier, and the domain in the address is the only thing that differs:

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=signup-1234567890-3f9a1c2e@qa-example.com"

Which means every helper on this site works unchanged after one constant is edited: the Playwright fixture, the Cypress task, the Python and Node modules. Three things are worth knowing that the public domains do not make you think about:

A 404 means the MX is not there yet

The listing answers 404 for a domain that is not hosted here. On your own domain that is a DNS problem — the record has not propagated, or points elsewhere — not an API one. dig MX first.

The alias works on your domain too

Every mailbox, on any domain, has a second address on a separate domain that delivers into it and cannot read it. Hand that to a site when you would rather it could not open the inbox; poll your own address.

A busy address is paged

A catch-all address that collects bounces or a day of notifications can hold more than one page of 200. Pass next back as before until it is null.

Keeping a test domain usable

A domain of your own is not on any disposable-mail blocklist, which is often the reason to use one in the first place: the application under test refuses grabmail.io and every other public domain, exactly as it should. Four habits keep it that way:

• Use a dedicated domain — qa-example.com, not a subdomain of production and not the domain customers write to. The service takes registrable domains only (example.com, never mail.example.com), and a test domain should have no other job.
• Do not publish it. The lists are built from what appears on public temp-mail sites and in shared address dumps. A domain that only ever appears in your own test suite has no way onto them.
• Lock it with SPF and DMARC. A receive-only domain with no SPF is a domain anyone can spoof mail from; two records close that, and cost nothing.
• Do not point real mail at it. The moment a staging system sends customer notifications to a catch-all address, a public mailbox holds customer data. Test domains carry test mail.

If the application refuses all catch-all domains — some fraud checks do, by probing whether a random address on the domain is accepted — there is a paid pool of ordinary-looking .com domains kept off the lists, described on the pricing page. Why sign-up forms block disposable email explains what each kind of check sees.

For a team: one domain, many testers, many pipelines

One catch-all domain serves everyone, because the local part is the only thing that has to differ and it is free. What a team needs is agreement on the naming above and three small conventions:

A prefix per pipeline and per person

e2e-, nightly-, alice-. Searching a job log for the prefix finds every mailbox it made; searching for a colleague’s finds the bug they are looking at.

Nothing shared, ever

There is no “team inbox” on the domain and no fixture that hands out a fixed address. If two people need the same mailbox, one of them sends the other the address.

The rate limits are per client

One read a second per address, 1200 requests a minute per client — a CI runner is one client, a laptop is another. A team of ten running suites at once is ten clients, not one.

The limits that apply

Your own domain gets the same service as the public ones, with the same ceilings. None of them is adjustable, and none is a problem for a test suite:

Before you call it done

• A dedicated registrable domain, with one MX record: 10 smtp.grabmail.io, and no other MX.
• One message sent to any address on it, and read back over the API.
• SPF and DMARC published, so nobody can send as the domain.
• A naming helper — who, which run, eight random characters — used by every suite.
• The domain kept in environment configuration, never in code, screenshots or tickets.
• Nothing that sends real customer mail pointed at it.

From here the suites are the ones already written: Playwright with the domain in its fixture, the runner-agnostic discipline, and the GitHub Actions workflow with the domain in a variable.

Questions