How Do You Receive Email on a Custom Domain?

To receive email on a custom domain, point that domain’s MX record to a mail server that is configured to accept it. If the MX target is a hostname such as mail.example.com, that hostname also needs an address record. Add the receiving domain to the application only after DNS and server acceptance are ready.

DNS and mailbox acceptance are separate jobs

Owning a domain does not automatically create mailboxes. DNS tells remote senders which mail server is responsible, while the mail server decides whether it accepts the recipient. Both layers must agree or messages will bounce, time out, or reach an unrelated provider.

A subdomain such as inbox.example.com can be delegated to a receive-only product without changing mail for the root domain. This is often the safest design when the root already uses a workplace provider for normal sending and replies.

Plan the mail route before changing records

Choose the exact receiving name first. Add an A record for the mail host if needed, then an MX record on the receiving domain pointing to that host. Do not point an MX record directly to an IP address because MX values are hostnames.

Configure the mail server and application to recognize the same domain. Verify DNS from an independent resolver, send a controlled external test, and read the mail logs if it does not arrive.

Configure the receiving path in order

1. Select the root domain or a dedicated receiving subdomain.
2. Create the mail-host address record on the receiving server IP.
3. Create the MX record for the chosen receiving name.
4. Add the domain to the approved receiver configuration.
5. Send a real message from an outside provider and confirm it in the inbox.

Prove the route with an outside sender

Check the exact host labels shown by your DNS panel. Many providers use @ for the root, while a subdomain requires only its leftmost label. Confirm there is no older MX record with higher preference sending mail elsewhere.

A local injection checks the application path. An authorized external message adds evidence about the public receiving route for that sender at that time. Confirm negotiated TLS and routing from the relevant server logs; message arrival alone does not prove encryption, every MX path or every sender’s delivery behavior.

DNS mistakes that look correct in a control panel

• Avoid: Adding the domain in an admin screen without configuring DNS
• Avoid: Creating an MX value that is an IP address
• Avoid: Replacing root-domain workplace mail when only a subdomain was intended
• Avoid: Assuming DNS changes appear everywhere immediately

Operational limits of receive-only domains

Publishing an MX record makes the server reachable by the public mail ecosystem, so spam filtering, size limits, recipient controls, monitoring, and abuse handling are operational requirements.

Receiving on a custom domain does not provide outbound reputation or reply capability. Use a dedicated sending provider if the domain must send transactional or human email.

How TempMail Cloud handles approved domains

TempMail Cloud can accept multiple administrator-approved receiving domains. Once DNS points to the VPS and the domain passes the configured check, adding it in the admin panel synchronizes the receiver and makes it available for mailbox generation.

Users can then select that domain for a custom address, while random generation can distribute addresses across all active domains. Existing mailboxes continue to use the domain recorded in their full address.

Common questions

Do I need a website on the domain?

No. Web hosting and inbound email routing are separate, although the mail host still needs a reachable server address.

Can I keep normal email on the root domain?

Yes. Use a dedicated receiving subdomain and leave the root MX records with the existing workplace provider.

How do I know it works?

Send from an unrelated external mailbox and confirm the message appears, then review mail logs for a final delivered status.

Related guides

• Create an address on a custom domain
• Receive-only business email explained
• Temporary email with saved login

Primary references used for this guide

• Cloudflare guidance for email DNS records
• IETF Simple Mail Transfer Protocol

A dated DNS observation with a negative control

On 29 September 2026 PKT, a DNS query for `tempmail.cloud` returned an MX preference of 10 pointing to `mail.tempmail.cloud`; an A query for that host returned `168.231.117.125`. The reserved name `example.invalid` returned no DNS name and was used only as a safe negative control. View the captured command and output.

This observation demonstrates how to record an MX target and resolve that target to an address. It does not prove that another domain is configured correctly, that a sender will accept it, or that SMTP delivery succeeds. Repeat the queries for the exact domain being configured and test from an authorized outside sender.

Read DNS evidence in the right order

1. Query the exact recipient domain for MX records.
2. Remove a trailing dot only when comparing host names; do not rewrite the configured value.
3. Resolve each MX target and confirm it is the intended receiver.
4. Send one controlled message and retain the sender's SMTP result.
5. Confirm the intended mailbox receives that message before changing production workflows.

Common failed setup reproduced safely

The negative control shows the clearest failure: a name that does not exist cannot publish an MX route. Real failures can be subtler—an MX target that does not resolve, a record on the wrong subdomain, a lower-preference legacy server receiving first, or a receiver that does not recognize the recipient domain. DNS output alone cannot distinguish all of them.