Pointing a subdomain at an external service (a help desk, a status page, a booking system, a landing-page builder) is a routine DNS job with three details that decide whether it works: which record type, whether the certificate follows, and what the service needs to verify.
Use the record they specify
The service tells you what to create. Do that rather than translating it into something that looks equivalent.
A CNAME to their hostname is the usual instruction, and it is the right one. They can change the address behind it without you doing anything.
An A record to a fixed address appears when the service has stable addresses. It works and it means you must update it if they ever renumber, which they will not warn you about individually.
Substituting one for the other is how this goes wrong. Looking up their CNAME target and hard-coding the address you find breaks the moment they move. There is more on the difference in which DNS record type do you need.
A CNAME cannot share a name
The rule that catches people, and it produces a failure that looks unrelated.
A name with a CNAME on it cannot have any other record. So if shop.example.com has a CNAME, it cannot also have a TXT record for verification or an MX record for mail.
This matters when a service asks for both a CNAME and a TXT verification record at the same name. Put the TXT record on the verification hostname they specify (usually something like _verify.shop.example.com) rather than on the name itself.
And never put a CNAME at the domain root. Standard DNS does not allow it, and providers that appear to support it are doing something non-standard behind the scenes. Understanding CNAME records has the detail.
The certificate is theirs to issue
Once the subdomain points at their servers, they serve the traffic, so they issue the certificate for it, usually automatically once the DNS resolves.
Two consequences.
Your own certificate does not cover it. Running AutoSSL on your server does nothing for a name that no longer resolves there.
Their issuance needs your DNS to be correct first. A CNAME that has not propagated means their certificate request fails, and the subdomain shows a browser warning until it succeeds, which reads as the service being broken.
Wait for DNS to settle before concluding anything is wrong. For the timing, see understanding DNS propagation.
If you have a CAA record
A CAA record naming only your usual certificate authority will block the external service from issuing for that subdomain.
The failure is delayed and confusing: everything resolves, the service says it is provisioning, and the certificate never appears.
Either add their authority to your CAA records, or add a CAA record on that specific subdomain naming theirs, noting that a record on a subdomain replaces the parent's for that name rather than adding to it. For the inheritance, see understanding CAA records.
Mail is a separate question
Pointing a subdomain at a service does not affect mail for your domain, because mail follows MX records at the domain itself.
The exception is when the service sends mail as your domain; a help desk replying from [email protected], for instance. That needs their sending servers included in your SPF record and their DKIM keys published in your DNS.
Miss it and the mail sends and gradually lands in spam, which is discovered weeks later. Understanding SPF, DKIM and DMARC goes into the one-SPF-record rule when adding a second service.
Do not delegate the whole subdomain unless asked
Some services ask for NS records, which hands the entire subdomain to their nameservers.
That is legitimate when they need to manage records under it. It also means anything you add for that subdomain in your own zone is ignored, and the delegation takes precedence, which is a genuinely confusing failure if you have forgotten it happened.
Write down anywhere you have delegated. It is the kind of thing that is obvious today and inexplicable in two years.
Removing one properly
When you stop using a service, remove the DNS record.
A CNAME left pointing at a service you no longer use is a subdomain of yours serving whatever they now put there, and on some platforms an abandoned name can be claimed by someone else, who then controls a page on your domain.
That is worth doing promptly rather than eventually, and it belongs on the list of things to check when a client or a service relationship ends. What to Do When a Client Leaves sets out the equivalent cleanup.
Check it end to end
dig CNAME shop.example.com +short curl -I https://shop.example.com/
The first confirms the record resolves to their hostname. The second confirms the service is answering and the certificate is valid. A certificate error appears here as a failure rather than a status code, which is itself the answer.
Then load it in a browser on a device that has never visited, since a desktop browser can hide a missing intermediate certificate that a phone will not. Understanding the certificate chain sets out that specific trap.
When subdomains are created by an application rather than by hand, a single record can cover all of them. Understanding Wildcard DNS Records walks through the trade.
Watch for the day the provider changes their address
A record pointing at somebody else's platform depends on their arrangements staying as they are. Platforms move addresses, retire hostnames and change the record type they want you to use, and they announce it to an address nobody reads. Check the value against their current instructions once a year, and check that the name still resolves at all. A subdomain quietly pointing at nothing is the usual result, and nobody notices because nobody visits it deliberately.