To create a custom address, choose an available name and one of TempMail Cloud’s active receiving domains. If you want to use a domain you own, the domain must first be connected by the administrator with the correct DNS and mail-server configuration. Client self-service domain onboarding is not currently automatic.
The two parts of every email address
An email address has a local part before the @ sign and a domain after it. The user can choose an available local part such as a neutral project or test name. The domain must already be able to route incoming mail to the TempMail Cloud server. A polished address in the interface is not enough; public DNS and the receiving server must agree.
TempMail Cloud supports multiple administrator-configured real domains and subdomains. A custom address on those domains is receive-only, password protected, and has no automatic mailbox expiry. It is “business-style” in appearance but does not include outbound sending, reply, SMTP, or a full office suite.
Create a custom local name
Select Create a custom address on the homepage. Enter a supported local name, choose an active domain, and set a unique password. The application checks whether the full address already exists. If it is available, the mailbox opens and can receive mail after the domain’s DNS is working.
Use names that describe a role without exposing personal data. QA teams can use stable patterns for signup or reset tests. A small business can use neutral receiving names for low-risk confirmations. Avoid impersonating a person or brand, and do not create deceptive addresses. The Terms prohibit fraud, phishing, harassment, and unauthorized access.
What DNS records are required?
For the current architecture, each receiving hostname typically needs an A record pointing to the VPS and an MX record pointing mail for that hostname to the mail server. For example, an `inbox` subdomain can have an A record to the server IP while its MX record points to the configured mail host. The exact values must match the server setup; copying values from another provider without verification can break mail.
DNS is only half of onboarding. Postfix must recognize the domain as a virtual mailbox domain, the application must list it as active, spam filtering must accept it, and the inbound receiver must deliver messages into the correct application state. TempMail Cloud’s admin automation is designed to update these server components when an authorized administrator adds a domain.
Can one root domain have several receiving subdomains?
Yes. A domain owner can create subdomains such as inbox.example.com and another approved receiving name, each with appropriate DNS. Every subdomain is a distinct email domain, so user@example.com and user@inbox.example.com are not the same address. The server must explicitly accept each one.
Creating many near-identical subdomains only to evade blocking or manipulate search visibility is a poor strategy. Use subdomains for clear operational reasons, monitor reputation, and comply with third-party rules. A receiving domain does not give permission to bypass a service’s account limits.
Administrator-assisted custom domains
A customer who controls a domain can request connection, prove ownership, and add the DNS records supplied by the operator. The administrator then enables the domain in the application and receiving server. This assisted process prevents anyone from claiming a domain they do not own and reduces configuration mistakes.
A future self-service workflow would need automatic ownership verification, DNS health checks, rate limits, abuse controls, certificate handling, rollback, and clear status reporting. Until those controls are implemented, do not describe custom domain onboarding as instant client self-service. Accuracy builds more trust than a feature promise the product cannot yet fulfill.
Delivery and reputation considerations
A correctly connected domain can receive ordinary email, HTML messages, OTPs, confirmation links, and notices that pass server limits and spam controls. It still cannot force a sender to deliver or prevent a website from rejecting the domain. New DNS can take time to propagate, and a sender may cache older MX results.
Keep SPF, DKIM, and DMARC concepts separate from receiving. Those records are especially important for outbound mail identity, while this service is receive-only. Do not publish misleading outbound authentication records for a domain that does not send through TempMail Cloud.
Related TempMail Cloud guides
You can also [create a receive-only inbox](/), review our safety guidance, or use the browser-local 2FA code generator.