A custom domain for a live stream is a branded address, but first decide whether it is for viewers to open or for your encoder to send video to. Choose the streaming service, add the hostname there, use only the DNS records it gives you, and wait for its HTTPS readiness confirmation before relying on the address.
A viewer-facing playback hostname and an encoder ingest endpoint do different jobs. They may need separate hostnames and DNS records; copying a target from one service or feature can send traffic to the wrong place.
Decide what the custom hostname is for
Start by writing down who or what will use the hostname. A viewer-facing name such as live.example.com or watch.example.com might lead to a hosted live page or a player. An ingest name such as ingest.example.com is for an encoder, and is useful only if the streaming service explicitly supports custom ingest domains.
A hostname does not make a page or player appear by itself. It is an address that a service must recognise and serve. Likewise, adding a DNS record does not automatically change the destination in your encoder. A viewer page and an ingest endpoint can both be described casually as a “live-stream domain”, but treating them as interchangeable is a common source of avoidable setup problems.
If your aim is to let viewers find a continuous YouTube stream, check whether you actually need a custom playback page. The YouTube watch page is a separate destination from the address your encoder sends video to. A custom domain may provide a more memorable page on a service that supports it, but it does not replace your channel or change the stream’s delivery behaviour on its own.
For an always-on channel, consider the practical path before changing anything. If the link is printed on a shop sign, shared in a devotional group, or put on a study-channel timetable, it is a viewer-facing URL. If you are configuring software to publish video, it is an ingest endpoint. Keep the tasks separate in your notes and, if both are needed, choose distinct hostnames.
Choose the streaming service first
The service determines which hostnames it accepts, which DNS records it expects, how ownership is checked, and how HTTPS is enabled. Choose it before opening the DNS panel. A registrar or DNS host can publish records, but it cannot tell you which target a streaming platform expects.
Check the service documentation and dashboard for the exact feature you intend to use: hosted live page, custom playback domain, video delivery domain, or custom ingest domain. Those labels refer to different capabilities. For example, OneStream Live’s hosted-page instructions describe a viewer page, while Cloudflare Stream’s custom ingest documentation describes custom domains for RTMPS input. Neither service’s DNS target is a general-purpose value for other providers.
Before proceeding, confirm you control the domain and can edit its DNS records. You may have registered the domain with one company and manage DNS through another. Locate the active DNS management panel rather than assuming the registrar’s own panel is authoritative. Interfaces also differ: a record’s Name or Host field may ask for the complete hostname or just its leading label.
A compact comparison helps keep the requirements distinct:
| Question | Viewer-facing hostname | Encoder ingest hostname |
|---|---|---|
| Who uses it? | A viewer’s browser or a page linking to the stream | Your encoder or streaming software |
| What should it open or reach? | A hosted page, player, or playback service | The provider’s specified ingest protocol and endpoint |
| What must the provider support? | Custom page or playback-domain hosting | Custom ingest-domain configuration |
| What should you test? | The exact public URL over HTTPS | The configured endpoint and an encoder connection |
Use the table to identify the workflow, not to infer DNS values. Even two services offering the same kind of hostname can require different records and verification steps.
Add the hostname in the service dashboard
Register the hostname with the selected platform before changing DNS. Enter the precise subdomain you intend to use, such as live.example.com, rather than changing the whole domain unless the platform’s instructions explicitly require that. The service may then display a CNAME target, a TXT ownership record, certificate guidance, or a combination of steps.
Keep a record of what the dashboard asks for. Note the hostname, the record type, the value or target, and any proxy or TLS condition. If the service has a status indicator, use it as the authoritative confirmation for that platform. Do not substitute a record from a tutorial for another provider simply because its setup looks similar.
If the dashboard does not offer a custom hostname setting, check the provider’s help page or support route before editing DNS. A DNS record alone cannot add a feature the service does not support. For a hosted video service, the provider’s own custom-domain documentation is a useful example of why the platform’s requirements should be checked directly: domain configuration can involve DNS updates and TLS as well as the hostname itself.
Plan for existing traffic as well. If the chosen name is already used for a website, email-related service, or another destination, do not overwrite its records casually. Prefer a new subdomain for the stream, and understand which current record you are replacing before saving changes. Avoid changing the apex domain, such as example.com, unless you understand every service currently depending on it.
Copy the provider’s DNS instructions exactly
Now make only the records requested for the hostname you registered. Record type, name, target, and any requested ownership value all matter. A CNAME points one name to another name; a TXT record is commonly used to prove domain control. A provider may ask for one, both, or another method. Follow its current instructions rather than guessing from the feature name.
The differences are concrete. Cloudflare Stream’s documented custom ingest workflow uses a CNAME to live.cloudflare.com. OneStream Live’s hosted-page instructions use a CNAME to hostedpage.onestream.live. These targets are examples for those named services and their respective features only. They are not interchangeable, and neither should be reused for a different provider.
In your DNS panel, check whether the Name field expects live or the full live.example.com. Entering the full name where the panel automatically appends the domain can create an unintended record such as live.example.com.example.com. Conversely, entering only a label into a panel that expects the full hostname may not create the record you intend. The DNS host’s own help text can clarify how its fields work.
Do not delete unrelated records to “clean up” the zone. Preserve the existing website and mail settings unless the provider specifically identifies a record for the hostname you are configuring. If a requested record conflicts with something already in use, pause and identify what depends on it before proceeding.
For practical context, if you are considering a self-managed delivery path, our guide to what to expect from CloudFront video-streaming costs covers a different operating model. That is not a DNS recipe for a hosted live-stream service; it is a reminder that a delivery setup you manage yourself can involve separate decisions beyond choosing a memorable hostname.
Complete ownership verification
Publishing a routing record and proving ownership are separate steps. A provider may ask you to add a TXT record, click a verification control, or wait while it checks the DNS change. Complete the method shown for the hostname in your service dashboard. A record visible in your DNS panel does not by itself mean the service has accepted the domain.
Some general hosting workflows separate ownership verification, routing, and certificate setup. For background, Firebase Hosting’s custom-domain instructions show these as distinct parts of a custom-domain process. That explanation can help you understand the concepts, but it does not replace the selected streaming platform’s instructions. Do not transfer Firebase’s values or sequence to a streaming service.
After adding a verification record, return to the service and run its verification step if one is provided. Check spelling carefully, including dots and the full hostname. If verification does not complete, compare the record in the authoritative DNS panel with the exact value requested and consult the provider’s troubleshooting guidance. Do not add several guessed variants: that can make it harder to identify which value is correct.
DNS changes and certificate provisioning may take time, and provider estimates vary. OneStream’s help article gives its own estimate for its verification process, while Firebase describes timing for its own DNS and TLS workflow. These are service-specific descriptions, not a universal waiting period or a promise that another platform will be ready within the same interval. Use the selected service’s status rather than a clock alone.
Follow proxy and TLS guidance
Some DNS providers offer a proxy or CDN switch alongside a record. That setting changes how requests are handled, so do not assume the default is compatible with your streaming service. If the provider says the hostname must be DNS-only, disable proxying for that record; if its instructions support or require a proxy, follow those instead.
The requirement can differ even between features from the same vendor. Cloudflare Stream’s custom ingest instructions specify DNS-only for a Cloudflare-managed ingest hostname. OneStream Live’s hosted-page guidance also tells its users to disable proxying where the DNS provider offers that option. These are instructions for those documented configurations, not a universal rule that every custom live-stream domain must be unproxied.
TLS is the mechanism behind HTTPS. Depending on the service, it may provision a certificate automatically after DNS and verification succeed, or ask you to complete additional steps. Do not import a certificate workflow from a separate cloud or CDN setup unless your provider explicitly directs you to it. For example, AWS’s CloudFront alternate-domain guidance is relevant to a CloudFront-managed delivery configuration, not a generic hosted stream page.
If a proxy is involved, check which host the certificate covers and whether the provider expects requests to reach it directly. A working DNS lookup is not the same as a valid HTTPS connection. The platform’s instructions and readiness state should tell you whether the requested proxy mode and certificate state are acceptable.
Confirm HTTPS readiness before sharing or switching
Wait until the streaming service confirms the custom hostname is configured and HTTPS-ready. Do not treat a saved DNS record, a successful verification click, or the passage of a particular number of hours as proof that the public URL is ready. The decisive confirmation should come from the selected provider’s status or support guidance.
For a viewer-facing hostname, open the exact URL in a browser using https://. Confirm that the browser shows a secure connection and that the intended page or player appears. Then check that the page points viewers to the right stream. If you are using the domain in a printed QR code or recurring announcement, test the same address someone else will use, rather than only checking the service dashboard.
For an ingest hostname, use the exact secure ingest URL and protocol supplied by the platform. Update the encoder’s server or URL field only when the service says the custom endpoint is configured. Then check the encoder’s connection status and the provider’s stream status. RTMPS, SRT, and other ingest methods have provider-specific addresses and settings; changing a hostname does not authorise you to keep every other encoder value unchanged.
If the stream is built from a repeating file or playlist, keep the content workflow separate from the domain task. Our guide on making an FFmpeg playlist repeat on YouTube Live covers playlist behaviour, while this guide concerns the address viewers open or the endpoint the encoder uses. If your setup is intended to avoid keeping a desktop open, see running a YouTube meditation stream from a playlist instead of OBS; it addresses a different operational choice, not custom DNS.
Once tests pass, update the places where the viewer-facing address appears: channel descriptions, website buttons, QR codes, and scheduled posts. Keep the previous destination available until the new one is confirmed in actual use, especially if viewers already rely on it. For ingest, retain the previous encoder configuration until you have confirmed the new endpoint connects and the intended stream is visible.
If you need the stream to continue while your own computer is switched off, StreamNeo removes the specific burden of keeping a local machine running for a file-based YouTube broadcast; its focus is turning an uploaded video into a 24/7 YouTube live stream, not providing a custom domain for other platforms.
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 use the same hostname for viewers and my encoder?
Usually, treat these as separate jobs and use different hostnames if you need both. A viewer page and an ingest endpoint can require different platform features, DNS records, and settings; use a single name only if the provider explicitly documents that configuration.
Can I copy a CNAME target from another streaming service?
No. A CNAME target is supplied for a specific provider and feature, such as a hosted page or ingest endpoint. Register the hostname with your chosen service and copy the exact record it requests.
Does a DNS change mean my custom stream URL is ready?
No. DNS routing, ownership verification, and TLS readiness can be separate steps. Wait for the service to confirm the hostname is configured over HTTPS, then test the actual viewer page or encoder path.
Should I leave a DNS proxy switched on?
Follow the selected provider’s instructions for that hostname. Some documented configurations require DNS-only records, while another service or feature may have different guidance; do not infer the setting from a different provider’s setup.