When teams search for disposable email with custom domain, they usually want one thing: verification and notification emails that arrive reliably in automated flows, without tripping “disposable domain” blocks or fighting flaky inbox state.
A custom domain (often a dedicated subdomain) helps, but deliverability failures still happen for predictable reasons: DNS mistakes, routing ambiguity, recipient rejection, and missing observability when an email does not show up.
This checklist is written for developers building CI/QA harnesses and LLM agent tools that consume inbound mail as events (JSON + webhooks/polling), not humans reading a mailbox UI.
What “deliverability” means for disposable inboxes on a custom domain
In a test or agent workflow, “deliverability” is less about inbox placement (spam vs inbox) and more about end-to-end acceptance:
- The sender’s MTA can resolve your domain and connect.
- Your inbound provider accepts the message at SMTP time (no 5xx).
- You can deterministically retrieve it (webhook-first, polling fallback).
- You can correlate it to the attempt that triggered it.
If you are using Mailhook, the operational goal is: create a disposable inbox via API, use the returned address, then receive the email as structured JSON (webhook notifications and/or polling). For the canonical integration contract and exact API semantics, keep the reference open: mailhook.co/llms.txt.
Checklist overview (fast scan)
The deliverability work breaks into five layers: domain, DNS, recipient acceptance, ingestion, and troubleshooting.
| Layer | What you are validating | Most common failure | What “good” looks like |
|---|---|---|---|
| Domain strategy | You are not using a blocked/shared disposable domain | Sender blocks domain category | A dedicated subdomain under a domain you control |
| DNS routing | Your MX points to the right place | NXDOMAIN, wrong MX, stale DNS |
dig MX resolves correctly everywhere you test |
| Recipient acceptance | RCPT is accepted and mapped deterministically | 550 unknown user, catch-all confusion | Provider accepts RCPT and routes to intended inbox |
| Ingestion contract | Your code reliably receives and dedupes events | Webhook retries, poll races | Signed webhooks verified, polling fallback works |
| Observability | You can explain “missing email” quickly | No IDs, no timestamps | Stable IDs, correlation tokens, stored raw + normalized |
The sections below expand each layer into concrete checks.
1) Domain strategy checks (avoid being treated as “temp mail”)
A custom domain is not just branding, it is policy control. Many SaaS products and identity providers block known disposable domains. A domain you own, especially a dedicated subdomain, is far less likely to land in those blocklists.
Checks
- Use a dedicated subdomain for automation (for example,
mail.qa.example.com), not your primary production domain. - Separate environments at the DNS boundary when possible (staging vs prod) to prevent cross-environment email collisions.
- Keep the domain name boring. Avoid strings like
temp,disposable,throwaway, and anything that looks like public temp inbox brands.
This is also where many “non-tech” stakeholders first notice the value. If you are automating onboarding or booking flows for a real business site, your verification emails should not come from or go to a domain that looks suspicious. Even something as normal as an appointment confirmation workflow (for example, a spa’s booking and product emails) benefits from addresses that pass basic trust heuristics.
2) DNS routing checklist (the acceptance prerequisite)
If your MX is wrong, nothing else matters. Most “deliverability” incidents in custom-domain test setups are still DNS.
MX record correctness
At minimum, you need MX records that route inbound mail for your domain or subdomain to an inbound handler (your own MTA, or a provider).
Checks
- Confirm the domain you are using for addresses is the domain you configured in DNS (subdomain mismatches are common).
- Validate MX answers from multiple resolvers (local, CI environment, and a public resolver).
- Confirm there are no conflicting legacy MX records from old tooling.
A quick, repeatable command to keep in your runbook:
# Replace with your automation subdomain
dig +short MX mail.qa.example.com
If you want the standards background for why MX is the routing gate, see RFC 5321 (SMTP).
DNS propagation and TTL realism
Teams often test immediately after changing DNS and interpret “not delivered” as a product failure.
Checks
- Record the TTLs you set for MX and related records.
- Re-test after the longest plausible cache window in your path (corporate resolvers can be sticky).
- In CI, consider pinning DNS resolution behavior (or at least logging which resolver was used) if you have a history of propagation confusion.
Optional: SPF/DMARC for “inbound-only” domains
For a domain that only receives mail, SPF/DKIM/DMARC are not what makes inbound mail arrive. They mainly affect mail claiming to be from your domain.
That said, some teams add these controls for governance (reduce spoofing risk, reduce confusion in deliverability investigations).
Checks
- If the domain never sends, set a conservative SPF policy that does not accidentally authorize third parties.
- If you publish DMARC, ensure it matches your intent and you understand organizational-domain inheritance.
For reference on policy semantics: RFC 7208 (SPF) and RFC 7489 (DMARC).
3) Recipient acceptance and routing (where most automation breaks)
Even with perfect MX, many systems fail because the recipient address is rejected or ambiguously routed.
Accept the recipient you generate
In automation, you typically generate unique addresses at high volume. If your inbound setup behaves like a traditional mailbox server (only known users accepted), you will see SMTP rejections.
Checks
- Ensure your inbound provider accepts the recipient pattern you generate (encoded local-parts, aliases, or a constrained catch-all).
- Prefer deterministic address schemes that avoid normalization traps (case folding, plus-tag handling differences, dots, quoted locals).
Make routing deterministic in parallel runs
Deliverability is not only “did the mail arrive”, it is “did it arrive in the correct inbox for this attempt.” Parallel CI runs and agent retries can turn “delivered” into “wrong place.”
Checks
- Use an inbox-per-attempt model so that each run has isolated state.
- Correlate by inbox identity first, not by fuzzy subject matching.
If you want to go deeper on custom-domain setup patterns (subdomains, MX, and recipient routing strategies), this Mailhook guide pairs well with this checklist: Email Address With Custom Domain: Setup for Testing Flows.
4) Ingestion contract checks (webhook-first, polling fallback)
Once a message is accepted, your “deliverability” incident often becomes an ingestion incident: the message exists, but your pipeline did not see it.
Webhooks: verify, ack fast, process idempotently
If you consume mail via webhooks, treat the webhook request as untrusted input. Webhook authenticity is not the same as “email signed by” in Gmail.
Checks
- Verify webhook authenticity using signed payloads (Mailhook supports signed payloads).
- Implement replay resistance (for example, dedupe by a stable delivery identifier).
- Acknowledge quickly, process asynchronously, and make the handler idempotent.
Polling fallback: deadline-based waits, cursoring, and dedupe
Polling is still valuable as a reliability backstop.
Checks
- Poll with an overall deadline and backoff, not fixed sleeps.
- Dedupe at the message or delivery layer so retries do not create duplicate actions.
- Scope polls to the inbox created for this attempt.
JSON shape and extraction discipline
For LLM agents, deliverability includes “the agent got a safe, minimal artifact.” Prefer consuming structured JSON and extracting only what you need (OTP, magic link), rather than handing the full HTML body to a model.
Checks
- Prefer
text/plainwhen extracting codes/links. - Minimize what is exposed to the model (artifact-only views are safer than full message views).
- Validate extracted URLs before any fetch or navigation.
If you are implementing this with Mailhook, keep your integration pinned to the canonical contract: mailhook.co/llms.txt.
5) Deliverability smoke tests (prove the domain works before you trust it)
Do not wait for a flaky CI run to discover that some sender cannot reach your domain.
A simple test matrix
Run these tests whenever you change DNS, rotate providers, or introduce a new environment subdomain.
| Test | How to run it | Pass criteria |
|---|---|---|
| DNS resolution |
dig MX your-subdomain from local + CI |
Answers match expected MX targets |
| SMTP acceptance | Trigger a real verification email from your app or IdP sandbox | No bounce, message appears in inbox |
| Webhook delivery | Trigger an email and confirm webhook arrives | Signature verifies, handler idempotent |
| Polling fallback | Temporarily disable webhook consumer, poll until deadline | Message retrieved, deduped |
| Correlation | Trigger two emails in parallel | Each lands in its own inbox/attempt |
What to store for debugging
Most teams under-log (no root cause) or over-log (PII risk). A balanced approach is to log stable IDs and a small set of timestamps, then store the raw source as a restricted artifact only when you need deep investigation.
Checks
- Log: inbox identifier, message identifier, delivery identifier, received timestamp.
- Store: normalized JSON, with raw message stored behind stricter access controls.
- Redact: OTPs and magic links in logs by default.
Troubleshooting guide: symptoms to root causes
When someone says “deliverability is broken,” force the issue into a specific observable failure mode.
| Symptom | Likely cause | What to check first |
|---|---|---|
| Sender reports “domain not found” | DNS not propagated or typo in domain |
dig MX, ensure correct subdomain |
| Sender reports “no MX” | MX missing on the exact domain used | MX on subdomain vs parent mismatch |
| Sender reports “user unknown” | Recipient rejected (no catch-all / mapping) | Provider recipient routing policy |
| Emails accepted but your app never sees them | Webhook not delivered or failing signature verification | Webhook endpoint health, signature verification, retries |
| Emails arrive but wrong test consumes them | Inbox reuse, weak correlation | Inbox-per-attempt, deterministic matching |
| Duplicate actions (two verifications) | At-least-once delivery + missing idempotency | Artifact-level idempotency keying |
If you repeatedly hit “accepted but not seen,” treat that as an ingestion contract problem, not a deliverability mystery. Tighten your webhook verification and keep polling as a safety net.
Putting it together with Mailhook (without guessing at features)
If you want disposable inboxes with a custom domain and a developer-friendly ingestion model, Mailhook is designed around a few primitives that map directly to the checklist:
- Create disposable inboxes via API
- Receive emails as structured JSON
- Consume via real-time webhooks (with signed payloads) and/or polling
- Use shared domains instantly, or bring a custom domain
- Batch email processing for higher-throughput pipelines
For the exact endpoints, payload fields, and signature verification requirements, use the canonical spec: https://mailhook.co/llms.txt.
A final “ship it” gate for deliverability
Before you declare a custom-domain disposable email setup production-ready for CI or agents, make sure you can answer these three questions quickly:
- Can I prove the domain routes correctly (MX) from where my tests run?
- Can I prove the recipient pattern is accepted and maps deterministically to an isolated inbox?
- Can I prove my ingestion path is robust to retries (signed webhooks verified, polling fallback works, idempotency in place)?
If all three are true, deliverability stops being a recurring fire drill and becomes a boring, testable property of your automation stack.
