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.
Why receive email on custom domain is a specific problem
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.
The practical approach
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.
Step-by-step workflow
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.
Turn the workflow into verifiable evidence
A useful result for receive email on custom domain should be reproducible by another authorized person. Use this compact review record instead of relying on memory, screenshots without context, or a single green status message:
1. Select the root domain or a dedicated receiving subdomain. Write down the starting state, responsible person, expected evidence, and a safe rollback before acting. This prevents a later success from being confused with an unrelated change and gives support a useful timeline without exposing credentials.
2. Create the mail-host address record on the receiving server IP. Capture a timestamp and a non-secret correlation value, then define what a pass and failure look like. Keep passwords, active codes, complete authentication links, and private message content out of the record.
3. Create the MX record for the chosen receiving name. Perform this step once under controlled conditions and observe every system it touches. If the result differs from the expectation, stop changing other variables until the first unexplained difference is understood.
4. Add the domain to the approved receiver configuration. Repeat the check from an independent session, device, resolver, or receiving account when that is relevant. Independent evidence distinguishes a cached interface result from the real behavior another user will experience.
5. Send a real message from an outside provider and confirm it in the inbox. Record the final state, remaining risk, owner, and review date. Delete temporary evidence that contains sensitive data and keep only the operational facts needed for maintenance or an authorized audit.
What to verify before relying on the result
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.
Test with more than an internal injection. A successful local test proves the application route, but only an external message proves public DNS, port 25 reachability, TLS negotiation, Postfix routing, and inbox ingestion together.
Common mistakes to avoid
- Adding the domain in an admin screen without configuring DNS.
- Creating an MX value that is an IP address.
- Replacing root-domain workplace mail when only a subdomain was intended.
- Assuming DNS changes appear everywhere immediately.
Security, privacy, and product boundaries
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 fits this workflow
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.
Frequently asked 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 TempMail Cloud guides
- Create an address on a custom domain
- Receive-only business email explained
- Temporary email with saved login
Use the [receive-only inbox](/), review our safety guidance, and read our editorial standards before relying on any temporary address for an important workflow.