How to Set Up a Custom Domain for Temporary Email (Full Walkthrough)

To set up a custom domain for temporary email, add a domain you control in Inboxto, copy the MX and TXT records shown on its configuration screen into your DNS provider, wait for DNS propagation, and run Verify DNS. Once both records pass, send a real test message before using the domain in a workflow. Use a dedicated subdomain if your main domain already receives business or personal mail, because changing its MX records can interrupt that delivery.

Inboxto custom domains are currently a Premium feature. They create a controlled, persistent receiving surface; they do not guarantee that another website will accept an address or override its terms.

Before you change DNS

You need three things:

• a domain whose DNS records you can edit
• an Inboxto Premium account
• access to the DNS provider that hosts the domain's authoritative nameservers

You do not need a web hosting plan. A registrar sells the domain, while the authoritative DNS provider publishes records for it; these may be the same company or two different companies. Check the domain's nameserver settings if you are unsure where to edit DNS.

Decide between the root domain and a subdomain

If example.com already receives mail through Google Workspace, Microsoft 365, Fastmail, or another provider, do not replace its MX records just to test Inboxto. Use an unused subdomain such as:

inbox.example.com

That gives the temporary-email workflow its own routing boundary. Mail for person@example.com can keep going to the existing provider, while mail for test@inbox.example.com goes to Inboxto.

If the domain is new and dedicated entirely to receiving test or privacy mail, using the root domain can be reasonable. Either way, export or screenshot the existing DNS records before changing anything. That small rollback record is much cheaper than reconstructing a working mail setup after a mistake.

For the architecture behind persistent test inboxes and controlled domains, read Inboxto for developers.

Step 1: Add the domain in Inboxto

Open Inboxto, sign in to the Premium account that should own the domain, and go to Custom Domains. Select Add Custom Domain, enter the root domain or dedicated subdomain, and continue.

Enter only the hostname, for example inbox.example.com. Do not include https://, a path, an email address, or a trailing slash.

The current setup flow also exposes an optional Enable catch-all address control under Advanced Options. A catch-all receives mail sent to otherwise unregistered local parts on the domain. It is useful for controlled QA naming, but it can also attract typo mail and spam. Leave it disabled unless you have a concrete use for it and a default receiving address you actively monitor.

Step 2: Copy the DNS records from the setup screen

After the domain is added, Inboxto shows two required records:

Purpose	Type	Name shown by Inboxto	Value
Route incoming mail	MX	@	Copy the current Inboxto MX server shown on screen
Prove domain control	TXT	inboxto-verify	Copy the unique verify_... token shown on screen

The current product screen shows MX priority 10. Copy the values from your own screen rather than from this article: service endpoints and verification tokens can change, and every domain receives its own TXT token.

An MX record tells sending mail systems which server accepts mail for the domain. The TXT record does not route mail; it proves that the person adding the domain can publish a secret value in its DNS zone.

First-hand Inboxto product check, August 26, 2026: We reviewed the current domain setup implementation. Its three-step flow is Add Domain → Configure DNS → Complete. Verification checks the expected MX destination and the exact TXT token at inboxto-verify.<your-domain> independently, then reports which check passed or failed. This is why adding only the MX record is not enough.

Step 3: Publish the records at your DNS provider

Create the MX record first:

1. Choose type MX.
2. Use the host or name Inboxto displays. Many DNS panels use @ for the zone root; when connecting a subdomain, follow the panel's rules and confirm the resulting fully qualified hostname.
3. Paste the Inboxto mail server as the target.
4. Set the displayed priority, currently 10.
5. Use the default or automatic TTL unless you have a reason to change it.

Then create the TXT verification record:

1. Choose type TXT.
2. Set the name to inboxto-verify as shown in the setup flow.
3. Paste the full unique verification token without adding spaces.
4. Save the record.

Some DNS panels automatically append the zone name. If you enter inboxto-verify.inbox.example.com where the panel expects only inboxto-verify, it may publish the name twice. Use the provider's preview or DNS lookup tool to confirm the final hostname.

Do not add SPF or DKIM values merely by copying a generic tutorial. Those records primarily authorize and authenticate sending systems. This setup is for receiving mail, and Inboxto's verification screen currently asks for MX routing plus TXT ownership proof. If you later send mail from the same domain through another provider, follow that provider's official SPF, DKIM, and DMARC instructions.

Step 4: Wait, then verify DNS

DNS updates are not visible everywhere instantly. Inboxto's current screen advises waiting about 5–10 minutes before checking, but caches and provider behavior can make some changes take longer.

Select Verify DNS. A healthy result shows:

Domain verified successfully
✓ MX record is correct
✓ TXT record is correct
✓ Your domain is ready to receive emails

A failing result identifies the missing side instead of presenting one generic error:

Domain verification failed
• MX record not found or incorrect
• TXT record not found or incorrect
• Please check your DNS settings and try again

If only one record fails, repair that record rather than deleting the whole domain.

Troubleshoot a failed check

Work through these causes in order:

Symptom	Likely cause	Fix
MX fails, TXT passes	Wrong MX target, host, or stale cached answer	Compare every field with the current Inboxto screen and query the exact connected hostname
TXT fails, MX passes	Token is truncated, quoted incorrectly, or published under the wrong name	Recopy the full token and confirm it resolves at inboxto-verify.<your-domain>
Both fail	Records were edited in a non-authoritative DNS zone	Check the domain's nameservers and edit records at the provider they point to
DNS passes but no message arrives	Sender delay, wrong recipient, or old MX still being used	Send a fresh uniquely titled message and inspect current public MX answers
Existing company mail stops	Root-domain MX records were replaced	Restore the previous records and move Inboxto to a dedicated subdomain

Do not repeatedly change records while caches are updating. First confirm the authoritative zone, then make one correction and wait.

Step 5: Prove real delivery

DNS verification proves that the required records are visible. It does not prove that your complete workflow is correct. Create an address on the verified domain, then send it a harmless message from a mailbox you control. Use a unique subject such as domain-check-20260826 so you cannot mistake an older message for the test.

Confirm all four points:

1. the sender reports a successful send
2. the exact recipient appears in Inboxto
3. the message arrives in the expected inbox
4. a second address on the domain behaves as intended, especially if catch-all is enabled

Inboxto addresses are persistent, while ordinary message retention is a separate plan limit. That makes a custom domain useful for repeatable QA and long-lived privacy identities without turning a primary mailbox into a test fixture. If you later automate this check, use the disposable email API getting-started guide.

What a custom domain does and does not solve

A custom domain gives you ownership, stable naming, and isolation from shared public disposable domains. It can keep testing mail away from your primary domain and make failures easier to trace. One address per service can also help identify where spam started; see the broader guide to stopping spam email.

It is not a universal acceptance pass. A platform can reject any domain, require a business mailbox, or prohibit temporary addresses. Do not rotate domains to force a blocked signup through. Use a custom domain for legitimate privacy, development, staging, and email testing, while following the receiving service's rules.

Also avoid sending sensitive production data to a test inbox. A private receiving domain reduces exposure, but it does not replace access controls, retention policy, or a strongly protected recovery mailbox. The email privacy guide explains where address separation fits in a larger security plan.

Finish the setup

The safe sequence is simple: choose a dedicated domain or subdomain, add it in Inboxto, publish the exact MX and TXT values shown, wait for DNS, verify both records, and prove delivery with a controlled message. Keep the old DNS values until the end-to-end test passes.

Open Inboxto, upgrade only if custom domains fit a real workflow, and start with one non-critical test domain before moving any important receiving identity.

Sources checked

• Inboxto official homepage and pricing
• Cloudflare: Configure an email server
• Cloudflare DNS record types: MX

Public product and DNS documentation, plus the current Inboxto domain setup flow, were reviewed on August 26, 2026. DNS fields, plans, and product screens can change; the values shown inside the live product are authoritative.