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.
Why MX record for receiving email is a specific problem
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.
The practical approach
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.
Step-by-step workflow
1. Choose the exact receiving domain shown in user addresses.
2. Create the MX target hostname and its IP address record.
3. Add an MX record with an intentional priority.
4. Configure firewall, TLS, mail server, and application domain acceptance.
5. Send an external test and trace it into the intended inbox.
Turn the workflow into verifiable evidence
A useful result for MX record for receiving email 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. Choose the exact receiving domain shown in user addresses. 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 MX target hostname and its IP address record. 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. Add an MX record with an intentional priority. 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. Configure firewall, TLS, mail server, and application domain acceptance. 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 an external test and trace it into the intended 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 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.
Common mistakes to avoid
- Putting an IP address in the MX value.
- Creating the record on the root when the address uses a subdomain.
- Opening the application domain before the mail server accepts it.
- Deleting existing workplace MX records unintentionally.
Security, privacy, and product boundaries
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 fits this workflow
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.
Frequently asked 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 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.