Written and reviewed by the team operating TempMail Cloud. Product claims are checked against our live service and our editorial standards.
To receive email, publish an MX record on the exact domain or subdomain that will appear after the @ sign. Its value must be a mail-server hostname, not an IP address. That hostname needs an address record, and the server must listen for SMTP and accept the receiving domain.
DNS and mailbox acceptance are separate jobs
DNS answers “which server handles mail for this name?” It does not create users, start a mail service, open a firewall, or tell an application who may read a message. Those tasks remain on the receiving server.
MX priority is a preference order where lower numbers are tried first. Multiple records can provide redundancy, but publishing several unrelated providers can create unpredictable delivery unless every destination is intentionally configured.
Plan the mail route before changing records
For a dedicated subdomain, create a mail host such as mail.example.com with an A or AAAA record, then set the MX on inbox.example.com to that hostname. Keep the root domain’s workplace MX records unchanged.
After DNS is visible, query an independent resolver and send from an external provider. Inspect the SMTP log for a final accepted and delivered result rather than judging only from a DNS panel’s success message.
Configure the receiving path in order
- Choose the exact receiving domain shown in user addresses.
- Create the MX target hostname and its IP address record.
- Add an MX record with an intentional priority.
- Configure firewall, TLS, mail server, and application domain acceptance.
- Send an external test and trace it into the intended inbox.
Prove the route with an outside sender
Check for a trailing-dot display convention, accidental duplicate labels, proxying on providers that do not proxy SMTP, and stale higher-priority MX records. Confirm port 25 is reachable from outside.
Verify the certificate name used during SMTP and maintain reverse DNS for the server where appropriate. These controls improve operational clarity even though inbound acceptance does not require the same reputation as outbound sending.
DNS mistakes that look correct in a control panel
- Avoid: Putting an IP address in the MX value
- Avoid: Creating the record on the root when the address uses a subdomain
- Avoid: Opening the application domain before the mail server accepts it
- Avoid: Deleting existing workplace MX records unintentionally
Operational limits of receive-only domains
A public MX record invites legitimate mail and abuse probes. Use recipient restrictions, spam scoring, size limits, rate limits, TLS, monitoring, and clear abuse handling.
Inbound DNS does not authorize outbound mail. SPF, DKIM, DMARC, reputation, and a sending service are separate concerns when replies or transactional sending are required.
How TempMail Cloud handles approved domains
TempMail Cloud expects approved receiving domains to route MX traffic to its configured mail host. The admin panel verifies the route and can synchronize active domains with the receiver when automation is enabled.
After setup, users can generate or choose addresses on the active domain. The full domain remains part of the mailbox identity and cannot be omitted during login.
Common questions
Can MX point directly to my VPS IP?
No. Point it to a hostname whose A or AAAA record resolves to the VPS.
What priority should one server use?
A single intentional value such as 10 is common; consistency matters more than the exact number.
Why does DNS look right but mail still fail?
The firewall, SMTP service, TLS, recipient pattern, or application ingestion may still be misconfigured.
Related guides
- Create an address on a custom domain
- Receive-only business email explained
- Temporary email with saved login