A CNAME alone will not make a custom domain open a YouTube Live watch page. It aliases one hostname to another; to give viewers an address such as live.example.com, you also need a web service or provider feature to send an HTTP redirect to the event’s YouTube watch URL.
Keep that viewer address separate from the stream details used by your encoder. YouTube provides a Stream URL and stream key for ingest, while your custom domain is just a convenient route for people watching in a browser.
What a custom stream domain can—and cannot—do
A custom viewer address gives you a short, branded way to point people to a particular Live event. You might put live.example.com on a poster, in a shop window, or in a message to regular viewers. Once configured, visiting that address can redirect a browser to the event’s YouTube watch page.
It does not make YouTube host the event at your domain, and it does not create a permanent YouTube channel address. The redirect is a separate layer between a viewer’s browser and YouTube. If you schedule a new event with a different watch URL, you will generally need to update the redirect destination for the next event.
There is also a difference between a custom domain for one event and a custom URL for your channel. YouTube says new custom channel URLs can no longer be set up and existing custom URLs can no longer be changed. Channel handle URLs are created from the handle you choose or change, while existing legacy custom URLs continue to work. See YouTube’s custom URL overview for the current rules. A domain you control can still redirect to a channel or event page, but that is not the same as changing the YouTube URL itself.
Before touching DNS, decide what viewers should reach: a specific live event, a channel page, or perhaps a page on your own website that explains the schedule. For the event case, create or schedule the YouTube Live event first, then copy its viewer-facing watch URL. Do not use the Stream URL or stream key as the redirect destination.
CNAME records vs. HTTP redirects
DNS answers a naming question: which hostname should a client look up when it asks for live.example.com? A CNAME record answers by making that name an alias of another hostname. It does not carry a web page, a URL path, or a video stream.
An HTTP redirect happens later, after a browser has connected to a web service. That service responds with an instruction to visit another URL, such as the event’s YouTube watch page. The destination belongs in the redirect configuration as a full URL, for example https://www.youtube.com/watch?v=..., not in a CNAME field.
That distinction is easy to miss because a DNS panel may call several features “forwarding”. Check whether the feature is actually an HTTP or URL redirect, rather than merely a DNS alias. If the panel accepts a destination hostname only, it is probably configuring DNS. If it accepts a full URL and lets you choose redirect behaviour, it is likely configuring the browser-facing step as well.
The redirect service must also be able to handle web traffic for your hostname. Merely pointing DNS at a name that happens to belong to a web service will not necessarily make that service issue the redirect. The service must recognise your hostname, have an applicable redirect rule, and support HTTPS if viewers will enter an https:// address.
Choose a DNS and web-traffic service
Start with the provider that already manages your domain’s DNS. Some providers offer a forwarding feature alongside DNS records; others require a separate web host or traffic service to receive requests and return the redirect. Either route can work, but the record target and controls differ. Follow the provider’s current documentation rather than copying a CNAME target from a guide written for another provider.
Compare the options by asking whether they support HTTPS for your hostname, whether they support the hostname you want, and what DNS records or proxy settings they require. Also decide whether you want the redirect to preserve any path or query string. For a simple event address, sending viewers to one exact watch URL is usually clearer than preserving arbitrary additions to the address.
| Approach | What you configure | Useful when | Check before proceeding |
|---|---|---|---|
| Provider forwarding or redirect feature | The provider’s required DNS record and a destination URL | Your DNS provider offers forwarding for the chosen hostname | Confirm HTTPS support, hostname coverage, and whether the feature issues an HTTP redirect |
| Separate web host or traffic service | DNS points the hostname to the service; a rule on that service redirects requests | Your existing provider does not offer the redirect behaviour you need | Confirm the service accepts your hostname, supports HTTPS, and documents its record requirements |
Cloudflare documents one specific implementation using a DNS record that resolves through its proxy and a Redirect Rule. Its procedure is an example, not a universal CNAME recipe. If you use Cloudflare, follow its redirects documentation; if you use another provider, use that provider’s instructions and do not assume it accepts the same record or target.
A subdomain such as live.example.com is often easier to isolate than the root domain, example.com. The root may already serve your website and may have records you rely on. Provider support for root or apex aliases varies; Cloudflare, for example, documents CNAME flattening for apex use in its CNAME record guidance. Check your provider’s rules and the records already in place before making a root-domain change.
Create the hostname record
Use a dedicated hostname if you can. Choose a clear name, such as live, then enter live.example.com as the hostname in the DNS or forwarding panel. The field labels differ: a provider might call it “Name”, “Host” or “Subdomain”. For a subdomain, the value may be just live; check how that provider expects it.
Next, create the record the selected service requires. If it calls for a CNAME, the target is a hostname, not https://, a YouTube watch URL, or a URL path. Some services require a proxied record or another record type instead. Use the exact target and settings in the provider’s documentation, and make sure the service can receive and process web requests for the hostname.
A CNAME generally cannot coexist with other record types at the same name. Before adding one, inspect whether live.example.com already has A, AAAA, MX, TXT or other records that serve a purpose. Do not delete or replace records for your website or email simply to make a redirect work. For example, avoid changing mail-related DNS records when you are adding a new live subdomain; keep the new hostname separate from the domain’s existing mail setup.
The domain’s nameservers matter too. A record added in a DNS dashboard has no effect if another provider’s nameservers are authoritative for the domain. Check which service manages the active DNS zone before making changes, and make the record there. If a domain is managed by a web host but its nameservers point elsewhere, the web host’s DNS screen may not be the one viewers use.
Keep a note of the hostname, record type, target and any proxy setting you chose. This makes it easier to check the setup later without guessing. If your current site or mail provider warns that a record is already in use, pause and identify what depends on it before editing anything.
Configure a redirect to the YouTube watch page
In YouTube Studio, create or schedule the Live event and copy the viewer-facing watch-page URL. Put that full URL into the provider’s forwarding feature or redirect rule. Do not enter it as the CNAME target: the DNS alias and the HTTP destination are different fields for different jobs.
Set the redirect for the hostname you chose and select the behaviour deliberately. For a straightforward public address, a permanent or temporary redirect may both appear to work, but the choice affects how browsers and intermediaries may remember the destination. If you will reuse live.example.com for a new event, avoid treating a changeable event destination as fixed without considering that caching behaviour. Follow the provider’s explanation of each redirect type; terminology can vary.
Use the exact watch URL, including its event identifier or other necessary components. Do not rely on viewers to reach the right event by landing on a generic YouTube page. If the event is unlisted, check that the audience has the link and understands how access works. A redirect does not make a private or otherwise restricted event public.
Some services let you preserve the incoming path or query string. That can be useful for a general-purpose site redirect, but it is not needed for a simple hostname that should always open one event. Cloudflare’s documentation describes path and query handling for its rules; other services may differ. Choose the simplest behaviour that matches your intended address, and test it rather than assuming the setting means the same thing everywhere.
Test DNS and the viewer-facing URL
After saving the record and redirect, test the full address in a browser, including https:// if that is what you intend to share. The expected result is that the browser reaches the particular YouTube watch page you selected. Check the final page and event title, not just whether the custom address loads.
DNS changes can take time to appear consistently because providers and networks cache answers. There is no universal completion time to promise. If one device reaches the new destination and another does not, compare the results later and check the DNS provider’s status and record values before changing settings repeatedly.
If the address fails, work through the layers in order. First confirm that you edited the authoritative DNS zone and that the hostname is spelled correctly. Then compare the record type, target and proxy requirements with the provider’s instructions. Finally, confirm that the redirect rule matches the hostname and points to the full watch-page URL.
If HTTPS produces a certificate warning or fails before redirecting, DNS alone has not solved the web connection. Check that the service covers the custom hostname with HTTPS and that its certificate or domain verification step has completed. Do not ask viewers to bypass a browser warning; correct the service configuration or use a provider-supported address while you troubleshoot.
Test from a device or browser that is not already showing a cached destination, and test the address you plan to publish. If you change the destination for a later event, repeat the check. Keep any screenshots free of private account details and stream keys. For the stream itself, YouTube’s live streaming eligibility guidance is relevant if the channel has not streamed before; a working redirect does not enable live streaming on a channel.
Keep the domain separate from YouTube ingest
The custom domain is for viewers. Your encoder sends video to YouTube using the Stream URL and stream key shown in Live Control Room. Those values are not interchangeable with the watch-page URL, and neither should be replaced with live.example.com.
YouTube’s encoder setup instructions explain how to enter its stream details. Copy the Stream URL and key from the event’s Live Control Room and use the protocol supported by your encoder. YouTube also documents RTMPS, a secure extension to RTMP; retrieve the relevant URL from Live Control Room rather than guessing one.
If viewers report that your custom address does not open the event, troubleshoot DNS, HTTPS and the redirect. If the event page opens but YouTube shows no incoming picture or reports an ingest problem, check the encoder’s server URL, key, protocol and connection separately. A redirect cannot relay video, repair an encoder, or alter YouTube’s ingest settings.
For a 24/7 channel built around prerecorded material, the delivery method is a separate decision from the viewer’s address. If you are preparing a local computer-based loop, the guide to streaming a YouTube live loop from a Windows scheduled task covers a different part of the workflow. If you need a long-running approach for replay content, see how to run a 24/7 YouTube stream of tournament replays. Neither changes the DNS distinction: the encoder still uses YouTube’s ingest details.
When the pain point is keeping a scheduled video broadcast running without leaving your own computer on, StreamNeo can take an uploaded video and run it as a YouTube live stream while you are away from that computer. That solves a broadcast-continuity problem, not the domain mapping: viewers still reach the watch page through the redirect you configure.
Before publishing the address, check both sides once more: the browser link should reach the intended event, and the encoder should be sending to the Stream URL and key supplied for that event. For a further check on channel readiness, read YouTube Live eligibility for an unlisted or hidden channel.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I put the YouTube watch URL in the CNAME field?
No. A CNAME target is a hostname, not a full URL with a protocol, path or event identifier. Put the YouTube watch URL in the redirect or forwarding feature, and use the DNS target required by your provider in the CNAME field.
Can I use my root domain instead of a subdomain?
Possibly, but root-domain handling depends on the DNS provider and on records already used by your website or email. Some providers support apex alias behaviour; others require a different method. Check their documentation and existing records before changing the root.
Does the custom domain change my YouTube channel URL?
No. It is a domain you control that redirects visitors to a YouTube page. YouTube’s current guidance says new custom channel URLs cannot be set up; handle URLs are generated from the channel handle, and existing legacy custom URLs continue to work.
What should I check if the link works but the live stream is offline?
First confirm that the redirect reaches the correct event watch page. Then check the encoder’s YouTube Stream URL, stream key and protocol in Live Control Room; the custom viewer address does not carry or repair the broadcast.