Read the hosted service's custom-domain instructions and identify your authoritative DNS provider. Record existing apex addresses and mail records. Confirm whether the service supplies fixed A/AAAA values or explicitly supports a provider-specific apex alias.

1. Add and verify the domain in the destination hosting service before directing visitors to it. Arrange certificate issuance for the apex name.
2. If the service supplies stable IP addresses, use its exact current A and, where supported, AAAA records. Do not derive permanent addresses by resolving an undocumented provider hostname once.
3. If your DNS provider supports apex flattening or an equivalent feature, follow that provider's instructions for the exact hosted target. This is a provider feature, not permission to publish an ordinary conflicting CNAME.
4. Keep required NS, SOA, MX and TXT data. Do not remove email authentication records merely to satisfy a misleading CNAME conflict message.
5. Configure the service's preferred public hostname and any apex-to-www redirect. DNS pointing alone does not create an HTTP redirect.

For a conventional hosted website with an assigned IPv4 address, an apex A record and a www alias can be a valid design. Replace these documentation values with the settings required by your hosting service before editing the authoritative zone.

example.com.      300  IN  A      192.0.2.10
www.example.com.  300  IN  CNAME  example.com.

Read the result: The apex remains able to hold its required zone data and mail-related records. The www name follows example.com. Do not place an ordinary CNAME at the apex alongside its SOA, NS, MX or other data and assume every DNS provider will make that combination valid.

If a hosted platform requires a changing hostname at the apex, use a supported provider feature such as its documented alias or flattening service, or the platform's alternative configuration. The website application and HTTPS certificate still need to recognise both names.

Query authoritative A/AAAA answers for the apex, then open its HTTPS website. Confirm the correct account serves the request and that email DNS remains intact.

If flattening returns no addresses, check that the target exists and has usable address records. If your provider lacks the required feature, use a supported alternative from the hosting service or plan a DNS-provider move.

• Make www and the root domain reach the same website consistently
• Find a CNAME loop or an alias chain that points to an absent target
• Prepare a reversible DNS change with an exact before-and-after record list
• Move a signed domain to another DNS provider without a stale DS record

• RFC 2181
• Cloudflare: apex records and flattening

• ISC BIND: dig and delv reference