You cannot put a CNAME on the apex: fixes for Vercel, Railway and AWS

Cloud platforms such as Vercel, Railway and AWS usually give one instruction for custom domains: "Create a CNAME record pointing to this address." For a subdomain like www or app that is fine. Try the same on the bare domain, misol-startap.uz, and the DNS panel either refuses or accepts it and your email stops working. That is not a panel limitation but a rule of the DNS standard.

Why the apex cannot be a CNAME

A CNAME says "this name is an alias of another name", and a name with a CNAME may have no other records. The apex must carry SOA and NS records and usually MX and TXT as well, so a CNAME there conflicts with them. Panels that accept it anyway produce unpredictable results, with some resolvers failing to find MX.

; wrong: apex CNAME conflicts with SOA, NS and MX
@     IN  CNAME  cname.platforma-misol.com.
@     IN  MX 10  mail.misol-startap.uz.

; right: CNAME on a subdomain
www   IN  CNAME  cname.platforma-misol.com.

Solution 1: an A record from the platform

Vercel provides an A record for the apex in the project's Domains settings and a CNAME for www. Copy the values from your own project, not from articles, because recommended addresses change. An A record coexists with MX and TXT and works in any DNS panel.

Solution 2: CNAME flattening, ALIAS or ANAME

Railway and many AWS services (load balancers, CloudFront, Elastic Beanstalk) give only a host name because their IPs change. Here you need flattening: the DNS provider resolves the target itself and answers with plain A records, so the apex stays standard and mail records survive. Cloudflare flattens an apex CNAME automatically, some providers offer ALIAS or ANAME records, and Route 53 has Alias records for AWS resources. These are provider features, not standard record types, so they work only if your name servers are with that provider. Moving name servers also moves every other record, so copy MX, SPF and DKIM to the new provider before switching.

Solution 3: make www primary and redirect the apex

If you do not want to move DNS, use www as the main address via CNAME and point the apex with an A record to a normal hosting server that issues a 301 redirect. That server needs a certificate for the apex too, or https://misol-startap.uz will show a warning.

server {
    listen 443 ssl;
    server_name misol-startap.uz;
    ssl_certificate     /etc/letsencrypt/live/misol-startap.uz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/misol-startap.uz/privkey.pem;
    return 301 https://www.misol-startap.uz$request_uri;
}

Platform	Subdomain	Apex
Vercel	CNAME	A record from dashboard or flattening
Railway	CNAME	Flattening/ALIAS or www + redirect
AWS (ALB, CloudFront)	CNAME	Route 53 Alias, flattening or www + redirect

Requirements change over time, so treat the table as guidance and confirm values in each platform's documentation.

Example: Vercel frontend, Railway API

A small Tashkent startup hosted its frontend on Vercel and its API on Railway, while the domain and company mail stayed with a local provider. Adding Railway's CNAME on the apex failed. Instead, the apex got the A record from Vercel's dashboard, www a CNAME to Vercel, and the API moved to api.misol-startap.uz with Railway's CNAME. MX and SPF stayed untouched and mail never stopped.

Checking the result

dig misol-startap.uz A +short
dig www.misol-startap.uz CNAME +short
dig misol-startap.uz MX +short

The apex should return A records, www a CNAME, and MX should be unchanged; the platform should mark the domain as valid and issue a certificate. If your domain is at sayt.uz, these records are added in the cabinet's DNS section.