CNAME record

Suppose app.customer.com has a CNAME to customers.yourproduct.com. A browser's resolver asks for the address of app.customer.com, and the customer's nameservers answer that the name is an alias for customers.yourproduct.com. The resolver then asks for that name's addresses, which your own DNS controls, and hands both answers back together. Each step is cached for its own TTL.

Nothing about HTTP changes. The browser still sends Host: app.customer.com, and it still expects a TLS certificate for app.customer.com. A CNAME moves traffic to your servers; it does not tell them which customer the traffic belongs to, and it does not issue a certificate. Both are your application's job.

• Nothing else may share its name. RFC 1034 section 3.6.2 says so and RFC 2181 section 10.1 restates it as absolute. A name with a CNAME cannot also have a TXT, MX or A record. DNSSEC signature records are the one exception.
• It cannot sit at a zone apex, because the apex always carries SOA and NS records. See apex domain.
• The target must be a hostname, never an IP address. To point a name at an address, use an A record.
• MX and NS records must not point at a CNAME (RFC 2181 section 10.3). Many providers accept the input anyway; some mail servers then fail in ways that are hard to trace.
• Chains work but cost lookups. An alias of an alias is legal, and each hop is another query and another cache entry that can be stale.

A CNAME hands control of the addresses to you. If the customer's record says "app.customer.com is customers.yourproduct.com", you can move to a new load balancer, add regions or change providers without asking a single customer to edit DNS again. An A record would pin your current IPs into every customer's zone.

The cost is the apex restriction and the "nothing else at this name" rule. If your verification flow also needs a TXT record, it must live at a different name, which is why ownership proofs sit at names like _dodomain-challenge.app.customer.com rather than at app.customer.com itself.

Look up a name you know has a CNAME and sometimes the authoritative nameservers answer with addresses instead. That is a proxy or flattening feature at the DNS host: with Cloudflare's proxy enabled, for example, a proxied name answers with Cloudflare's edge addresses, and a flattened CNAME answers with the target's current addresses. The record is saved correctly; the answer is rewritten. The DNS propagation checker shows what the authoritative nameservers actually return, which is the value verification will see.

• DNS propagation checker

  Read a CNAME straight from the authoritative nameservers and three public resolvers.

• ALIAS and CNAME flattening

  What providers offer when the name you need an alias at is the apex.

• The connect flow (docs)

  How DoDomain gets a customer's CNAME written and verified.

• DoDomain with Cloudflare for SaaS

  Where the CNAME ends and the certificate for the customer's hostname begins.