How to Connect Your Domain: Master DNS & Email Setup Templates for WordPress, Shopify, Google Workspace and Cloudflare

Overview

Connecting a domain usually involves two separate jobs: directing web traffic to the service that hosts your site and directing email to the provider that handles your mailboxes. DNS records control both. The domain registrar may be different from the DNS provider, and the DNS provider may be different from the website host or email host.

Before changing anything, record the current DNS zone. Export it if your provider supports that option, or save a screenshot and copy the existing records into a secure document. Pay particular attention to MX, TXT, and CNAME records because replacing them without checking can interrupt email verification, sending, or other connected services.

Use these conventions throughout this guide:

• @ means the root domain, such as example.com.
• www means www.example.com.
• TTL is the time that resolvers may cache a record. A shorter TTL can make planned changes easier to test; a longer TTL can reduce repeated DNS lookups.
• Provider destination means the exact hostname, IP address, or verification value displayed by the service you are connecting. Do not substitute a value from another account or an old tutorial.

A useful baseline is to use a TTL around 300 seconds while testing a planned change, where your DNS provider permits it, and then use the provider's normal or recommended TTL after the configuration is stable. A lower TTL does not make DNS changes immediate: cached records and provider-specific behavior can still affect the timing.

Checklist by scenario

Master DNS and email configuration table

WordPress hosting: point the domain to your site

1. In your WordPress host's dashboard, add the domain and copy the required A, AAAA, or CNAME records. Some hosts provide a dedicated IP; others provide a hostname.
2. At the authoritative DNS provider, create or update the root record. Use an A record for an IPv4 address, an AAAA record for an IPv6 address, or an ALIAS/ANAME record if the host gives you a target hostname and your provider supports that record type at the root.
3. For www, use a CNAME pointing to the hostname supplied by the host, or follow the host's instructions for a second A record.
4. Remove duplicate or obsolete web records for the same name. Two different A records may be intentional, but do not leave an old host mixed with a new host by accident.
5. In WordPress and the hosting panel, confirm the preferred URL, usually either the root domain or www. Test both HTTP and HTTPS after the SSL certificate is issued.

Do not guess a WordPress host's IP address. Shared hosting, managed WordPress hosting, and cloud hosting can use different connection methods, and a provider may change the value during migration.

Shopify: point the domain without moving email

1. In Shopify's domain settings, choose the option to connect an existing domain and copy the current required records.
2. At your DNS provider, update the root A record and the www CNAME to the values Shopify displays. If Shopify offers an automatic connection method through your registrar, review the proposed changes before approving them.
3. Keep your existing MX records and mail-related TXT records. Website DNS changes do not require changing email routing.
4. Return to Shopify and complete domain verification. Wait for verification before removing any old web record.
5. Test the root domain, www, checkout pages, redirects, and email delivery separately.

If the root domain uses an ALIAS or ANAME record instead of an A record, follow the DNS provider's instructions and Shopify's current connection guidance. The exact destination can change, so the values in the service dashboard take priority over copied examples.

Google Workspace: set up MX, SPF, DKIM, and DMARC

1. Verify domain ownership using the TXT record provided in the Google Workspace setup flow. Add it at the root name, usually represented as @.
2. Add the complete set of MX records shown in the Workspace admin console. Remove obsolete MX records from a previous mail provider only after confirming that the new mailboxes and aliases are ready.
3. Create one SPF TXT record at the root. Include every legitimate sender, such as Google Workspace, your website form provider, and a transaction platform. Merge senders into one SPF policy rather than creating multiple SPF records.
4. Generate a DKIM key in the Workspace admin console. Publish the TXT record using the selector and value it provides, then return to the console to start DKIM signing.
5. Add a DMARC TXT record at _dmarc. Start with a monitoring policy such as p=none while collecting reports, then tighten the policy after reviewing legitimate senders and alignment. Use a reporting address you control and follow current provider guidance.

Google's required MX values, DKIM selector, and recommended setup flow can change. Copy the current values from the administrator console rather than relying on a static list. If another service also sends mail for your domain, include it in SPF and configure its DKIM before enforcing a restrictive DMARC policy.

Cloudflare: use it as the authoritative DNS provider

1. Add the domain to Cloudflare and review the imported records. Imported data may be incomplete or may include records you no longer use.
2. At the registrar, replace the domain's nameservers with the pair Cloudflare assigns. Nameserver changes affect the whole DNS zone, not only the website.
3. Recreate required A, AAAA, CNAME, MX, TXT, verification, and subdomain records before or during the nameserver change.
4. Use Cloudflare proxying only for compatible web traffic. Keep MX records and mail hostnames DNS-only; proxying a mail hostname can prevent mail clients and sending services from connecting correctly.
5. After the switch, verify DNSSEC settings, SSL mode, redirects, and origin connectivity. If DNSSEC was enabled at the previous provider, coordinate the DS record change to avoid validation failures.

What to double-check

• Authoritative nameservers: Make sure you are editing the DNS provider that the domain currently uses. Changing records at a non-authoritative provider has no effect.
• Record conflicts: A hostname cannot normally have a CNAME alongside an A, AAAA, or other conflicting record. Remove only records that you have identified as obsolete.
• Root versus subdomain: A record for @ does not automatically configure www, mail, or other subdomains.
• Mail continuity: Confirm MX priority and retain all legitimate sending-service records. Website hosting and email hosting can be separate.
• SPF syntax: Publish one SPF TXT policy. If multiple teams add separate SPF records, authentication can fail or produce inconsistent results.
• DKIM value formatting: Copy the complete value, including the selector and any required quotation handling. Do not insert extra spaces or line breaks unless the DNS interface requires them.
• HTTPS: DNS pointing and SSL issuance are separate steps. Test the certificate after the domain resolves to the correct host.
• Propagation: Check the record from more than one network or DNS lookup tool. A local result may be cached and may not represent what other users see.

For a broader explanation of A, AAAA, CNAME, MX, and TXT records, see DNS Records Explained: How to Connect a Domain to Your Website and Email. Email authentication deserves its own audit; use SPF, DKIM, and DMARC Setup when reviewing senders and policies.

Common mistakes

• Changing nameservers without copying the zone: This can remove website verification, email, subdomains, and third-party services at once.
• Deleting MX records during a website migration: Moving web hosting does not move email. Leave mail routing alone unless the mail provider is also changing.
• Using a guessed IP address: Use the destination provided for the specific account. Shared and managed platforms may not use a universal address.
• Adding several SPF records: Combine authorized senders into one policy and keep it within the limits advised by your email provider.
• Testing only the homepage: Check both domain versions, HTTPS, contact forms, inbound mail, outbound mail, and important subdomains.
• Assuming propagation means failure: Compare authoritative DNS results with public resolver results before making another edit. Repeated changes can make troubleshooting harder.
• Enforcing DMARC too early: First identify all legitimate senders and confirm DKIM or SPF alignment. A strict policy can affect valid mail from an unrecorded service.

When to revisit

Return to this checklist before a domain, website, or email migration; before a seasonal campaign or product launch; and whenever a team adds a new sending service, subdomain, SaaS tool, or hosting environment. It is also worth reviewing after a registrar transfer, a Cloudflare nameserver change, a major email-provider update, or an unexpected increase in bounced or rejected mail.

As a practical maintenance routine, keep a dated DNS inventory with the record name, type, destination, purpose, owner, and last review date. Recheck SPF, DKIM, and DMARC after adding any service that sends mail. Review old verification TXT records and unused subdomains periodically, but remove them only after confirming that no active service depends on them.

Before making the next change, follow this short runbook:

1. Write down the intended result and identify the authoritative DNS provider.
2. Export or document the current DNS zone.
3. Copy the exact values from the current provider dashboard.
4. Lower the TTL in advance if a planned test requires faster rollback.
5. Make the smallest necessary change, then verify with DNS lookups.
6. Test website access, HTTPS, inbound email, outbound email, and forms.
7. Record what changed and restore a normal TTL after the configuration is stable.

If a change causes an outage, compare the live records with your saved inventory and roll back only the affected records. For hosting decisions beyond DNS, the hosting comparison for developers can help separate website infrastructure choices from domain configuration.