Bluehost handles two related but distinct jobs: it can register your domain name and it controls the DNS records that decide where that domain points. This guide covers the practical pieces: finding your nameservers, adding new domains, switching your primary domain, editing A and CNAME records, pointing a third-party domain at Bluehost, managing SPF/DKIM/DMARC for email deliverability, creating subdomains, protecting your WHOIS privacy, and transferring a domain away from Bluehost when you move registrars. Each section links to the step-by-step how-to for the task it covers.
What This Guide Covers
Bluehost gives you two layers of domain control. The first is the registrar function: you can buy and renew domains directly from your Bluehost account, and your first domain is free for the first year on any shared plan. The second is DNS management: even if you bought the domain elsewhere, you can use Bluehost as your DNS host and edit records (A, CNAME, MX, TXT) from the Domains tab. This hub explains both, plus when you should let Bluehost handle DNS versus moving DNS to a faster provider like Cloudflare. For broader context on Bluehost plans and pricing, see our Bluehost hosting guide.
Bluehost Nameservers Explained
Default Nameserver Values
A nameserver is the authoritative source for your domain’s DNS records. When you change nameservers, you are telling the registrar which company is allowed to publish DNS records for your domain. Bluehost runs two default nameservers that almost every Bluehost customer uses:
ns1.bluehost.comns2.bluehost.com
If you bought your domain at Bluehost, your nameservers are already set to these values. If you bought the domain at a different registrar (Namecheap, GoDaddy, Cloudflare Registrar, Google Domains, Squarespace), you need to update the nameservers at that registrar to the Bluehost values above before Bluehost can serve your site. The full walkthrough is in how to change nameservers on Bluehost, including screenshots of both the BlueRock dashboard and the older Legacy cPanel layout.
Custom Nameservers (VPS and Dedicated Only)
Custom (private) nameservers are available on Bluehost VPS and dedicated plans only, letting you serve DNS from your own brand (for example, ns1.yourdomain.com). Shared plans do not support custom nameservers.
Adding and Assigning Domains in Bluehost
Bluehost lets you run multiple websites on one account (on Plus, Choice Plus, and Pro plans). Each website lives in its own folder under public_html and is tied to a specific domain through the Assign feature.
Three tasks people run into early:
- Adding a domain to your account. Bluehost separates addon domains (a brand-new site under a fresh domain) from parked domains (an alias pointing at an existing site). Most multisite owners want addon domains.
- Assigning a domain to a specific folder. The Assign workflow tells Bluehost which directory should respond when someone visits that domain, keeping multiple WordPress installs separate inside one hosting account.
- Changing your primary domain. The primary domain is tied to your main account billing and your default cPanel address. Changing it after a rebrand is straightforward but has implications for your SSL certificate and any hardcoded URLs in your WordPress database.
For WordPress users: changing the domain in cPanel only controls where requests get routed. You also need to update the WordPress Address and Site Address inside wp-admin > Settings > General, or run a search-and-replace on the database using WP-CLI or a plugin like Better Search Replace.
Creating and Managing Subdomains on Bluehost
Common Uses for Subdomains
A subdomain is a prefix on your main domain that points to a separate directory or site. Common uses include staging.yourdomain.com for a test environment, store.yourdomain.com for a WooCommerce shop on a separate install, mail.yourdomain.com for webmail access, or app.yourdomain.com for a separate application.
How to Create a Subdomain
Creating a subdomain in Bluehost takes two steps. First, create the subdomain under Domains in BlueRock (or the Subdomains tool in Legacy cPanel): enter the prefix, choose the domain, and Bluehost creates a folder for it under public_html. Second, install whatever is going in that folder (a WordPress site, a Laravel app, a static page). For staging environments, most developers install a second WordPress copy in the subdomain folder and use the same Bluehost hosting account; the subdomain runs on the same server, so there is no speed difference between the main site and the staging copy.
Subdomain DNS follows the same nameserver as your main domain automatically. If your nameservers point to Bluehost, the subdomain resolves through Bluehost DNS with no extra configuration. If your nameservers point elsewhere (for example, Cloudflare), you need to add an A record for the subdomain at that provider pointing to your Bluehost server IP.
Subdomains vs. Subdirectories
One important distinction: subdomains are different from subdirectories. A subdirectory (yourdomain.com/store) lives in a folder inside your main WordPress install. A subdomain (store.yourdomain.com) is a separate DNS entry that can host a completely independent site. Most multisite WordPress setups use subdirectories; most separate apps or staging environments use subdomains.
Pointing a Third-Party Domain to Bluehost
Option 1: Change Nameservers (Recommended)
The cleanest method for using a domain registered elsewhere with Bluehost hosting is to update the nameservers at the source registrar to the Bluehost defaults. This hands DNS control to Bluehost, so any records you add inside the Bluehost Domains tab take effect immediately.
Option 2: Point Only the A Record
If you cannot or do not want to change nameservers (common when using Cloudflare DNS for performance or security), point only the A record instead:
- Find your Bluehost server IP in your account portal under My Sites or in cPanel under Server Information.
- At your DNS provider, create an A record for
@pointing to that IP. - Create a CNAME record for
wwwpointing to the apex domain (or a second A record pointing to the same IP, depending on what your DNS host supports). - If you use email forwarding or third-party email, leave the MX records pointing at the email provider, not at Bluehost.
Cloudflare-Specific Steps
For Cloudflare specifically: set the A record to DNS-only (grey cloud), not proxied, until your SSL certificate is active on Bluehost. If you proxy the record before the SSL is installed, Cloudflare will return a certificate error because it expects HTTPS from the origin. Install the Let’s Encrypt certificate in Bluehost first, confirm the site loads over HTTPS at your Bluehost IP, then switch the Cloudflare record to proxied (orange cloud).
Domain Privacy and WHOIS Protection on Bluehost
When you register a domain, ICANN requires registrars to publish the registrant’s name, address, email address, and phone number in the public WHOIS database. Without domain privacy, anyone can look up who owns a domain and find your personal contact details.
Bluehost offers Domain Privacy as a paid add-on (included free with some plans). When enabled, Bluehost substitutes a privacy service’s proxy contact details in the WHOIS record instead of your own. Your real details are stored privately with Bluehost but are not visible to the public.
What domain privacy protects: your name and address from scrapers who build marketing lists from WHOIS data, your email address from domain-related spam and phishing attempts, and your phone number from cold calls targeting domain owners.
What it does not protect: legal authorities can still access your real details through proper legal channels, the fact that you own the domain is still publicly visible (only the contact details are masked), and privacy cannot be added retroactively to a domain that has already been transferred away from Bluehost.
If you registered your domain through Bluehost and are not sure whether privacy is enabled, check under Domains in your account. Look for a "Privacy" toggle or status next to each domain. If it is not already on and you care about keeping your contact details private, enabling it is straightforward from the same screen.
Managing A, CNAME, and Other DNS Records
The Bluehost DNS editor handles every record type a typical site needs: A, AAAA, CNAME, MX, TXT, SRV, and NS. The Domains tab in BlueRock and the Zone Editor in Legacy cPanel are the two interfaces you might see, depending on when your account was created.
What Each Record Type Does
- A record: Maps a hostname to an IPv4 address. This is the record that controls where your website actually loads from.
- CNAME record: Aliases one hostname to another. Use it for
www.yourdomain.compointing toyourdomain.com, or for verification with services like Cloudflare, Mailchimp, or Google Search Console. - MX record: Tells the world which mail server accepts email for the domain. Bluehost sets these to its own mail servers by default; change them if you use Google Workspace, Zoho Mail, or another provider.
- TXT record: Holds arbitrary text. Used for SPF, DKIM, DMARC, and domain ownership verification.
Record Format Examples
When adding records in the Bluehost DNS editor, you fill in three fields: Name (hostname), TTL (time to live, usually left at the default of 14400), and Value. Here are what common entries look like:
An A record pointing the root domain to your server IP:
Name: @
TTL: 14400
Value: 68.178.232.100A CNAME record pointing www to your root domain:
Name: www
TTL: 14400
Value: yourdomain.comA CNAME for Google Search Console ownership verification:
Name: google-site-verification-XXXXXXXX
TTL: 14400
Value: google.comThe full step-by-step for A and CNAME records lives in how to add an A record and CNAME on Bluehost.
Email DNS Records on Bluehost
This is the section most Bluehost DNS guides skip. If you send any email from your domain (transactional WordPress mail, contact-form submissions, or a real mailbox), three TXT records determine whether that email lands in the inbox or the spam folder. For setting up the mailboxes themselves (Roundcube webmail, POP/IMAP settings, paid Workspace upgrades), the Bluehost configuration and features guide covers the account-side steps that pair with these DNS records.
SPF Record
SPF lists which servers are allowed to send mail as your domain. If you only use Bluehost mail, the default record works. If you also send through Google Workspace, Mailchimp, or SendGrid, add their includes to the SPF record and keep the total under 10 DNS lookups.
Bluehost-only SPF record:
Name: @
Value: v=spf1 include:bluehost.com ~allBluehost plus Google Workspace:
Name: @
Value: v=spf1 include:bluehost.com include:_spf.google.com ~allBluehost plus Google Workspace plus Mailchimp:
Name: @
Value: v=spf1 include:bluehost.com include:_spf.google.com include:servers.mcsv.net ~allThe ~all at the end is a soft fail: mail from unlisted servers is flagged but not outright rejected. Use -all (hard fail) only once you are certain your SPF record includes every sending service you use.
DKIM Record
DKIM is a cryptographic signature proving the email actually came from your domain. Bluehost generates a DKIM key automatically when you enable Email Authentication in cPanel. The value Bluehost shows you looks like this:
Name: default._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
... rest of public key ...Copy the exact value Bluehost provides into a new TXT record at the default._domainkey subdomain. Do not modify the key string. If you use Google Workspace for email, Google generates its own DKIM key inside the Workspace Admin console under Apps > Google Workspace > Gmail > Authenticate email. The Google-provided DKIM selector is typically google._domainkey rather than default._domainkey, so both records can coexist without conflict.
DMARC Record
DMARC tells receiving mail servers what to do when SPF or DKIM fails. A starter record is safe to publish immediately and gives you reporting data before tightening the policy:
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]p=none means no action is taken on failing mail, but reports are sent to the address in rua. After reviewing a few weeks of reports, you can tighten to p=quarantine (send to spam) or p=reject (block the message entirely).
Skipping these three records is the single biggest reason Bluehost-sent email ends up in Gmail’s spam folder. They live in the same Domains > DNS editor as your A and CNAME records.
Setting Up Google Workspace MX Records on Bluehost
Google Workspace requires five MX records. When you migrate your domain’s email to Google Workspace, remove any existing Bluehost MX records first, then add all five of the following in the Bluehost DNS editor:
- Priority 1:
ASPMX.L.GOOGLE.COM - Priority 5:
ALT1.ASPMX.L.GOOGLE.COM - Priority 5:
ALT2.ASPMX.L.GOOGLE.COM - Priority 10:
ALT3.ASPMX.L.GOOGLE.COM - Priority 10:
ALT4.ASPMX.L.GOOGLE.COM
In the Bluehost DNS editor, set the Name field to @ for each MX record, and set TTL to 3600 (one hour) or leave at the default. After saving all five records, allow up to 24 hours for propagation. You can confirm they are live by running dig MX yourdomain.com @8.8.8.8 in a terminal and checking that all five Google servers appear in the output.
One common mistake: leaving the old Bluehost MX records in place alongside the new Google ones. Mixed MX records cause mail to route unpredictably between providers. Delete all pre-existing MX entries before adding the Google values.
After adding MX records, add the Google Workspace SPF include and the Google-provided DKIM key (generated in the Workspace Admin console) to finish the email setup.
DNS Propagation and Troubleshooting
DNS changes do not take effect instantly. Caching at registrars, resolvers, and ISPs means a nameserver or A record change can take anywhere from a few minutes to 48 hours to be visible everywhere. In practice, most updates are live within one to four hours.
How to Check Propagation
If a change is not working, check these things in order:
- Use
dig +short A yourdomain.com @8.8.8.8in a terminal, or an online tool like DNS Checker, to see the current published value bypassing your local cache. - Verify the nameservers at the registrar match the Bluehost values. A mismatch is the most common cause of "I changed it but nothing happened."
- Flush your local DNS cache. On macOS, run
sudo dscacheutil -flushcache. On Windows, useipconfig /flushdns. - If you use Cloudflare, confirm the record is set to DNS-only (grey cloud) while troubleshooting. Proxied (orange cloud) records return Cloudflare IPs, not your origin.
- If the source DNS shows the correct value and nameservers are right, the rest is patience while caches expire.
Using Specific Record-Type Checks
You can query individual record types to isolate problems. To check MX records specifically:
dig MX yourdomain.com @8.8.8.8To check TXT records (useful for confirming SPF and DKIM are live):
dig TXT yourdomain.com @8.8.8.8
dig TXT default._domainkey.yourdomain.com @8.8.8.8If the record shows the correct value in dig output but email or site behavior is still wrong, the issue is usually at the application layer rather than DNS. For sites, check your SSL certificate. For email, verify the exact syntax of your SPF and DKIM values.
Moving DNS to Cloudflare
If Bluehost DNS feels slow or you want better global resolution times, moving DNS to Cloudflare (free plan) is the most common upgrade Bluehost users make. Nameservers switch to Cloudflare’s values, and all record management moves to the Cloudflare dashboard.
Transferring Your Domain Away from Bluehost
If you are moving to a dedicated registrar like Namecheap or Porkbun, or consolidating everything at a new host, you can transfer a domain out of Bluehost in three steps.
- Unlock the domain: In Bluehost, go to Domains and find the domain. Turn off the Transfer Lock. Bluehost locks domains for 60 days after registration or a previous transfer, so you cannot initiate a transfer on a newly registered domain.
- Get the authorization code (EPP code): Still in Domains, request the Authorization (EPP) code. Bluehost emails it to the registrant contact address. This code expires within a few days, so initiate the transfer promptly.
- Initiate at the new registrar: Start a domain transfer at the new registrar, enter the EPP code, and confirm any verification emails sent to your registrant address. The transfer takes 5-7 days for most TLDs.
Important timing rules: ICANN policy blocks transfers within 60 days of a renewal, and most registrars will not accept a domain with fewer than 15 days remaining before expiry. Transfer with at least 30 days of registration time left.
One thing to be clear on: transferring the domain registrar is separate from changing your hosting. Your site continues to load from Bluehost servers after the domain transfer completes. To actually move hosting, you first migrate your files and database to the new host, verify everything works, then change the nameservers or A record to point at the new host. Changing nameservers is the final step, not the first.
Next Steps
If you are setting up a brand-new Bluehost site, complete domain setup before installing WordPress so links resolve correctly from the first request. If you are migrating from another host, do site files first, the database second, and DNS last so visitors do not hit a half-migrated site. For everything else Bluehost-related, the Bluehost hosting guide is the main reference. For step-by-step DNS record instructions, see adding an A record and CNAME on Bluehost.
