Pointing a Domain at Your Windows Server: DNS Records, IIS Host Headers, and HTTPS

Pointing a Domain at Windows Server in Four Steps

Pointing a domain at a Windows Server VM is a four-step job: create the DNS records, add the site in IIS, bind the host header, and attach a certificate. Each step fails in predictable ways — wrong record type, cached TTLs, a missing binding — so this guide shows the exact records and settings to use, from a fresh server to a working https://yourdomain.com.

Step 1: Decide Where DNS Lives

You can manage DNS at your domain registrar (default, fine for most setups), at your hosting provider if they offer a DNS panel, or at a third-party DNS service. For a single domain on one server, the registrar’s DNS panel is sufficient; the plans listed in our Windows VPS comparison table note which hosts include their own DNS management panel. What matters is that the records below resolve to your server’s public IPv4 address, so write that address down before you start.

Step 2: Create the Records

In the DNS panel, create these records:

Type	Name	Value	Purpose
A	@	your server’s IPv4	Resolves the bare domain to your server
AAAA	@	your server’s IPv6	Optional, only if the host assigns IPv6
CNAME	www	yourdomain.com	Aliases www to the bare domain
MX	@	mail server hostname	Only if you run email; never point MX at the VPS otherwise

Set the TTL to 300–600 seconds (5–10 minutes) while you are migrating, then raise it to 3600 or more once everything works. A low TTL during setup means your test machines pick up changes quickly instead of caching a stale IP for an hour.

Step 3: Add the IIS Site and Host Header

Open IIS Manager, right-click Sites and choose Add Website. Give the site a name, point the physical path at your content folder, and under Binding set: Type http, IP address All Unassigned, Port 80, and Host name yourdomain.com. Add a second binding with host name www.yourdomain.com on the same port.

The host header is what lets IIS tell requests for yourdomain.com apart from requests for any other domain on the same IP. If you skip it, IIS serves the default site for every host name, which is the most common reason “the domain shows the wrong website”.

Step 4: Add HTTPS

Get a certificate for both yourdomain.com and www.yourdomain.com. The practical options are a free Let’s Encrypt certificate issued and renewed automatically with win-acme, or a commercial certificate from your registrar. Then add a https binding on port 443 with the certificate selected and SNI enabled, and use IIS URL Rewrite to redirect all HTTP traffic to HTTPS. If you skip the www binding, visitors to www.yourdomain.com will hit a certificate name mismatch.

Step 5: Verify End to End

• Run nslookup yourdomain.com and nslookup www.yourdomain.com — both must return your server’s IP.
• Flush the local DNS cache (ipconfig /flushdns) and retest from a phone on mobile data to bypass local caching.
• Test the site over HTTP and HTTPS, then check the certificate with SSL Labs’ analyzer for chain and TLS issues.
• Confirm ports 80 and 443 are open in Windows Firewall — a blocked port looks exactly like a DNS problem from the outside.

Common Mistakes to Avoid

• A record still pointing at the old server IP after a reinstall or migration.
• TTL set to hours before a planned IP change, forcing you to wait out the cache.
• Host header only on the http binding, so the https site serves the wrong content.
• Certificates without the www SAN, producing browser warnings on the www URL.

If you are pointing a subdomain rather than the bare domain — for example app.yourdomain.com — the flow is identical: create an A record named app instead of @, and add an IIS binding with host name app.yourdomain.com. Wildcard certificates can cover many subdomains with a single cert, but each subdomain still needs its own host header binding. One more tip: if the site previously lived elsewhere and its old pages are indexed, keep the TTL low for a few days after switching so visitors and search engines converge on the new IP quickly instead of caching connection errors.

Before You Bind: Choose a Host With Full DNS Control

Binding a domain cleanly requires a server with its own public IPv4 address, an unfiltered firewall you control, and ideally a DNS panel or registrar integration. Our Windows VPS comparison table lists providers that include a dedicated IPv4 and firewall control out of the box, so you are not fighting NAT or carrier-grade restrictions. If you plan to host several domains on one machine, our guide to IIS bindings, host headers, and SNI covers multi-site setups in depth.

Need a Windows Server VM with a dedicated IPv4 and full firewall control for your domain setup? Hostwinds’ Windows VPS plans include dedicated IP addresses and unmanaged access to Windows Firewall, and their support team can walk you through DNS configuration if you get stuck.