Custom domains
Point a domain you own at mailfixture and create inboxes on it. A customer-controlled namespace avoids shared testing-domain blocklists, though each signup service still decides which addresses it accepts.
Why a custom domain
Shared domains are a demo funnel, and we're honest about their physics: domains that hand out free programmatic addresses are common targets for disposable-email blocklists (the full story). A custom domain removes the shared-domain identifier: signup-a1@testmail.acme.com lives in a namespace your company controls and strangers cannot use. It is not a universal acceptance guarantee — a service can still inspect MX records or apply its own policy. Custom domains are available on every paid plan.
Setup: two DNS records
Register the domain with POST /v1/domains or the dashboard wizard; either way you get two records to publish, with copy buttons in the dashboard:
; ownership proof _mfx.testmail.acme.com. TXT "mfx-verify=<your-token>" ; mail routing testmail.acme.com. MX 10 <mx-target-from-your-instructions>
testmail.acme.com, not acme.com. The MX record routes ALL mail for that name to mailfixture; putting it on a domain that already receives real email would reroute your actual mail. A subdomain carries your root domain's reputation without touching its mail flow.
Verification
Both records must check out: the TXT proves you control the domain, the MX proves mail will actually arrive. Trigger a check with the dashboard button or POST /v1/domains/{id}/verify — and for a domain's first 7 days a background task re-checks every 60 seconds anyway, so verification usually lands on its own after DNS propagates. You'll get an email when the domain goes fully green. Our checks run with DNS caching disabled, so they never wait out a stale TTL — the remaining delay is your DNS host publishing the record to its own nameservers.
Until verification completes, mail to the domain is rejected — inbound routing switches on only when ownership is proven.
Using it
Pass the domain when creating inboxes; everything else — TTLs, long-polling, extraction — works identically to the shared domain:
$ curl -s -X POST https://api.mailfixture.com/v1/inboxes \ -H "Authorization: Bearer $MAILFIXTURE_API_KEY" \ -H "Content-Type: application/json" \ -d '{"domain": "testmail.acme.com"}'
The domain belongs to your account alone: no other account can create inboxes on it, and addresses you haven't created still 550-reject — a custom domain is not a catch-all.
Removing a domain
DELETE /v1/domains/{id} removes the domain and everything on it — every inbox and every message. Mail to the domain starts bouncing once your MX record is gone; remember to clean up the two DNS records.