How to Connect a Domain to Microsoft 365, Google Workspace, and Web Hosting Using DNS Records

Overview

If you want a website at your domain and email at that same domain, DNS is the bridge between the name you registered and the services you use. Your registrar may be where you bought the domain, but DNS might be managed there or at a separate DNS provider such as Cloudflare. That distinction matters because the records must be edited wherever your domain’s DNS is actually hosted.

For most setups, you will work with a small set of record types:

• A record points a name to an IPv4 address, often used for the root domain.
• AAAA record does the same for IPv6 when your host supports it.
• CNAME points one name to another hostname, often used for www.
• MX tells the internet where to deliver mail for your domain.
• TXT is used for domain verification, SPF, and other text-based checks.
• CNAME or TXT for DKIM helps sign outgoing mail.
• Additional records may be needed for provider-specific services, autodiscovery, or collaboration tools.

If you need a primer before editing live DNS, see DNS Records Cheat Sheet: A, AAAA, CNAME, MX, TXT, SRV, and NS.

One evergreen rule is worth keeping in mind from the start: adding email DNS records should not break your website, and changing website DNS should not break your email, as long as you edit only the records that belong to the service you are changing. Problems usually happen when someone replaces the full zone file, deletes records they do not recognize, or changes nameservers without recreating existing records first.

Before you begin any scenario below, use this pre-flight checklist:

1. Confirm where DNS is hosted by checking your nameservers in your registrar account.
2. Open your existing DNS zone and export it if your provider allows exports.
3. Take screenshots or copy current records into a temporary document.
4. Lower TTL in advance if you expect to change records soon, when your provider permits it.
5. Know whether the service offers automatic setup through Domain Connect or a similar guided flow.
6. List what must keep working during the change: website, existing email, subdomains, or third-party tools.

Microsoft notes that some registrars support Domain Connect, which can automatically verify domain ownership and add the required records for Microsoft 365. If that option is available, it is usually the safest first attempt because it reduces manual entry errors. If not, manual DNS setup remains standard and works reliably when done carefully.

For a broader launch sequence that includes domain registration, hosting, SSL, and email, see How to Start a Website: Domain, Hosting, DNS, SSL, and Email Setup Checklist.

Checklist by scenario

This section breaks the job into three common cases. Use the one that matches what you are changing, and avoid touching unrelated records unless you have a reason.

Scenario 1: Connect a domain to Microsoft 365

If your goal is to use your custom domain for Microsoft 365 email and related services, the process is usually: add the domain in Microsoft 365, verify ownership, then add the service records Microsoft provides.

1. Add the domain in the Microsoft 365 admin area. Start the setup so Microsoft can generate the records you need.
2. Check for Domain Connect support. Microsoft documents that some registrars can complete verification and record setup automatically through Domain Connect.
3. If automatic setup is unavailable, verify ownership manually. This usually means adding a TXT record at your DNS host and waiting for Microsoft to confirm it.
4. Add the MX record for mail delivery. This is the key record that routes inbound email to Microsoft 365.
5. Add the TXT record used for SPF, if instructed. SPF helps declare which servers are allowed to send email for your domain.
6. Add DKIM-related records if Microsoft provides them in your tenant setup. These are often CNAME-based and help outgoing mail pass authentication.
7. Add any autodiscover or service records Microsoft requests. The exact list can vary by service and admin flow.
8. Wait for propagation, then test sending and receiving. Test from an outside email address, not just within your own domain.
9. Only after verification, assign the domain to user addresses. Microsoft advises adding the custom domain before creating users where possible, so you do not have to redo account addresses later.

Important boundary: your domain remains registered with your registrar even after you connect it to Microsoft 365. Microsoft 365 uses the domain for its services, but registration ownership does not move unless you separately transfer the domain.

If you need a fuller business email walkthrough, see How to Set Up Custom Domain Email for Your Business.

Scenario 2: Connect a domain to Google Workspace

Google Workspace setup follows the same overall pattern even though the record values differ: add the domain in Google Admin, verify ownership, set MX records for Google mail, and then add authentication records.

1. Add your domain in Google Workspace. Start from the admin setup so you receive the right record values for your account.
2. Verify ownership. This is commonly done with a TXT record at your DNS host.
3. Replace or add MX records for Google mail. Use the exact priorities and server values shown in your admin instructions.
4. Add SPF as a TXT record. If you already have an SPF TXT record, edit the existing SPF entry rather than creating a second one.
5. Enable DKIM in Google Workspace and publish the supplied DNS record. The record type and value will be generated in your admin panel.
6. Consider DMARC after mail is working. It is not always required for initial setup, but it is a good follow-up for visibility and policy control.
7. Test inbound and outbound mail. Confirm that messages arrive, replies work, and headers show authentication passing once propagation is complete.

The same caution applies here as with Microsoft 365: only change the email-related records unless you also intend to move the website. Your A, AAAA, and website CNAME records are separate from MX and most mail TXT records.

Scenario 3: Point a domain to web hosting

If your website is moving to a host, a managed WordPress platform, or a website builder, you usually need to point the domain either by changing specific records or by changing nameservers. Record-level changes are more controlled; nameserver changes are broader and should be treated with more care.

1. Get the exact connection method from your host. Hosts usually ask for one of these: an A record, an A record plus a www CNAME, or a nameserver change.
2. Prefer record-level changes when you want to preserve existing email and custom DNS. This avoids rebuilding every record at a new provider.
3. Update the root domain. This is often the @ host pointing to your server IP via A record.
4. Update the www subdomain. This is commonly a CNAME pointing to the root domain or to a hostname provided by your platform.
5. Do not delete MX, SPF, DKIM, or verification records. Website pointing and email routing are separate functions.
6. If your host requires nameserver changes, copy all existing DNS records first. This is the step many site owners skip, and it is how email unexpectedly stops working after a hosting move.
7. Wait for propagation and test both versions of the domain. Confirm that example.com and www.example.com resolve correctly.
8. Install or enable SSL at the host. DNS pointing alone does not complete the launch if HTTPS is not configured.

If you are still comparing hosting approaches, these may help: Best Cheap Web Hosting 2026: What You Actually Get at Entry-Level Prices and Website Builder vs WordPress vs Hand-Coded Site: Which Is Best for Your Goals?.

Scenario 4: Use email on one provider and hosting on another

This is the most common small business setup and the one that causes the most confusion. It is also completely normal.

• Your website may use A, AAAA, and CNAME records from your web host.
• Your email may use MX, TXT, and DKIM records from Microsoft 365 or Google Workspace.
• Your domain registration may remain at a registrar that does neither hosting nor email.

There is no conflict in this arrangement as long as each record serves its own purpose and no required records are removed during changes. This is why many site owners keep registration, DNS, email, and hosting as separate decisions.

What to double-check

Before you call the setup finished, review these details. Most support tickets come from one of these small but consequential issues.

• Are you editing the right DNS provider? Updating records at your registrar does nothing if the domain actually uses external nameservers.
• Did you verify the host field? Some DNS panels use @ for the root, some leave it blank, and some expect the full name.
• Did you copy provider values exactly? A trailing dot, missing priority, or pasted quote can break a record.
• Did you create duplicate SPF records? There should generally be one effective SPF TXT record for a given hostname.
• Did you preserve existing MX records until the cutover is intentional? Replacing MX too early can divert mail before accounts are ready.
• Did you wait long enough for propagation? Some changes appear quickly, while others take longer depending on TTL and caching.
• Did SSL finish provisioning after the domain began resolving? A site can load over HTTP or show certificate warnings for a short time even after DNS is correct.
• Did you test from outside your own network? Local caches can make a change look incomplete or complete when it is not.

If privacy and account safety are part of your launch checklist, review WHOIS Privacy Explained: What It Hides, What It Doesn't, and When You Need It.

Common mistakes

The most useful DNS advice is often about what not to do. These are the errors that repeatedly delay launches.

Changing nameservers when only one record needed updating

If your host says to add an A record and a www CNAME, do that. A full nameserver change is broader and can wipe out working email or verification records if you do not recreate them.

Replacing an existing SPF record instead of merging it carefully

Mail providers often ask you to add an SPF include. If you already send mail through another service, adding a second SPF TXT record can cause authentication problems. The safer approach is to maintain a single SPF record that reflects all legitimate senders.

Deleting records that look unfamiliar

Old verification TXT records, DKIM selectors, or service-specific CNAMEs can look messy, but deleting them casually can break mail or third-party tools. Remove records only when you know what they do and confirm they are no longer needed.

Assuming the registrar, DNS host, email provider, and web host are the same company

Sometimes they are. Often they are not. Treat each role separately: who registered the name, who hosts DNS, who handles email, and who serves the website.

Testing too early and troubleshooting the wrong problem

DNS changes are not always instant. Before changing values again, check whether the original update has had time to propagate. Repeated edits made in frustration often create more confusion than the initial mistake.

Launching the site without checking HTTPS and redirects

After DNS resolves, confirm that the site loads securely, that www and non-www versions behave as intended, and that the primary domain redirects consistently.

If you are still deciding where to keep the domain itself, compare management quality and renewal terms here: Best Domain Registrars Compared: Pricing, Renewal Costs, WHOIS Privacy, and Transfer Rules and Best Domain Registrars for Privacy, Security, and Easy DNS Management 2026.

When to revisit

DNS setup is not a one-time task you should forget forever. Revisit it when the underlying tools or workflows change, especially before busy planning cycles or any migration window.

Use this practical review list whenever one of these events happens:

• You move web hosts. Reconfirm A, AAAA, and CNAME records, then test SSL and redirects.
• You switch email providers. Replace MX records intentionally and review SPF, DKIM, and any DMARC policy.
• You change nameservers. Compare the old and new DNS zones line by line before the switch.
• You add a new sending tool. Update SPF carefully and publish any required DKIM or verification records.
• You add a staging site, shop, or subdomain. Keep records organized so production and staging are clearly separated.
• You transfer the domain to a new registrar. Confirm whether DNS will stay where it is or move with the transfer.
• You bring a previously unused domain into active use. Review old placeholder records, email settings, and ownership verification from earlier tools.

A simple maintenance habit works well: keep a plain-language DNS inventory with each record’s purpose, the provider that requested it, and the date it was last changed. That turns future updates from guesswork into a short checklist.

Before your next launch or migration, do three things in order: identify where DNS is hosted, list the records that must survive the change, and update only the records tied to the service you are changing. That approach is less dramatic than a full reset, but it is usually the reason everything keeps working.

If you are still in the planning stage, these related guides are useful next steps: How to Buy a Domain Name Safely: Availability Checks, Ownership, and Checkout Red Flags and Best Domain and Hosting Bundles 2026: Compare Convenience, Control, and Total Cost.