
An MX record answers one narrow question: which server should receive mail for this domain? For a temporary-email custom domain, Cloudflare can host the authoritative DNS, while GPTMail—not Cloudflare—provides the receiving inbox service. The setup becomes confusing when a DNS dashboard looks correct but the public DNS response says something else.
The cure is to stop judging the form and inspect the answer the internet can actually see.
Before changing DNS
Confirm three details:
- You can edit DNS for the domain's authoritative nameservers.
- The domain is the exact domain you intend to receive mail on.
- You have copied the current public MX target shown by GPTMail.
GPTMail currently displays the required target on the add-domain panel and the domain page. Use that value rather than an old screenshot or a record copied from another service.
The minimal record
For the current GPTMail public target, the record is typically:
Type: MX
Name: @
Target: email.chatgpt.org.uk
Priority: 1DNS providers describe the host field differently. @, a blank value, or the domain itself can all mean the zone apex. Follow the provider's convention; do not literally enter @ if the interface expects a blank field.
Some providers require a trailing dot after the target and some add it automatically. Both forms represent the same DNS name when handled correctly.
Choose public or private before copying the target
GPTMail has two custom-domain modes, and they do not always use the same MX target.
- A public domain uses the public target shown on the domain page. After verification it appears in the public domain list and receives an API key for server-side requests.
- A private domain stays out of the public list and is linked to your GPTMail account: sign in first, and only that account can view its messages. Start from the private-domain tab on the GPTMail homepage and generate the dedicated DNS settings before editing MX.
Do not copy the public example in this article into a private-domain setup. The value displayed for the domain you are adding is the source of truth.
Priority is not a speed setting
Lower numbers have higher preference. Priority 1 is a clear default, but 0 or 10 also works when it is the only MX route. The dangerous configuration is an older record with a lower number pointing somewhere else. Senders will try that route first.
During migration, remove obsolete MX records unless you deliberately operate a tested backup receiver. Multiple records are not harmless decoration; they define alternate delivery routes.
Verify the authoritative answer
After saving the record, query public DNS:
dig MX your-domain.exampleThe answer should contain the GPTMail target. If it does not, check which nameservers are authoritative:
dig NS your-domain.exampleThen ask one of those nameservers directly:
dig @authoritative-nameserver.example MX your-domain.exampleThis separates propagation delay from editing the wrong DNS zone. If the authoritative server already returns the new record but a public resolver does not, wait for cached data to expire. If the authoritative server still returns the old value, waiting will not fix it; the change was saved in the wrong place or not published.
Why a correct record can appear unknown
DNS checks can temporarily return no answer because of resolver timeouts, nameserver problems, DNSSEC errors, or a record that is still propagating. One failed lookup does not prove the domain is misconfigured.
If GPTMail reports that the MX record is not pointed to the required server:
- Copy the actual MX value shown in the domain manager.
- Compare it with the required target, including the full hostname.
- Check for a competing record with a higher preference.
- Query the authoritative nameserver directly.
- Wait several minutes and retry after a new DNS change.
Do not repeatedly delete and recreate the domain while DNS is propagating. That changes the application state without changing what DNS returns.
Cloudflare-authorized setup
Cloudflare is the DNS provider in this flow; GPTMail is the temporary inbox receiver. This setup does not use Cloudflare Email Routing.
Before authorizing, check the following:
- Select the Cloudflare account and zone that actually control the domain.
- If Cloudflare Email Routing is enabled, disable it first. GPTMail detects its routing MX records, stops without changing DNS, and asks you to resolve the conflict.
- Review the target shown by GPTMail. The one-time authorization replaces MX records for that domain only; other DNS record types are not modified, and the access token is revoked after the callback completes.
The automatic record uses priority 0, while the manual example above uses 1. Either is valid when it is the only MX route. Authorization reduces typing errors, but the final verification still relies on public DNS.
If the domain uses another DNS provider, add the record manually and return to GPTMail to retry verification.
Test real delivery
An MX lookup confirms routing, not end-to-end delivery. After verification:
- create a fresh address on the domain;
- send a short plain-text message from an unrelated provider;
- confirm the recipient address exactly matches;
- wait for the sender to complete delivery before assuming failure;
- try a second sender if the first message is delayed.
Avoid testing only from a system that recently cached the old MX route.
Keep ownership and recovery separate
A custom domain gives you naming control, but GPTMail remains a temporary inbox service. Keep registrar access, DNS recovery, and important account recovery on a durable mailbox outside the temporary domain.
For deciding whether a private domain is appropriate in the first place, read Choose an Inbox by Consequence, Not Convenience. If test messages still do not arrive after MX verification, use Verification Email Not Arriving: Find the Broken Step.