Connecting Google Workspace to Your Custom Domain via DNS

Connecting Google Workspace to your custom domain requires configuring specific Domain Name System (DNS) records to prove ownership and route your email securely. Without these settings, Google's servers cannot verify that you own the domain, nor can they safely send or receive messages on your behalf. Whether you are migrating from another email provider or launching a brand-new domain, getting these DNS entries right is critical for avoiding delivery failures and spam folder flags.

Before you start making changes at your DNS host, you should check your domain's current registrar status and name server delegation using the WHOIS Lookup tool to ensure you are editing the correct DNS zone file. This guide walks you through the exact process of proving ownership, updating mail exchangers, and securing your mail flow with modern authentication protocols.

Step 1: Initiating Google Workspace Domain Verification

When you first sign up for Google Workspace, the setup wizard asks you to verify that you own your domain name. Google offers multiple methods for this, but adding a TXT record or CNAME record to your DNS manager is the industry standard and works for almost every domain registrar.

Log in to your Google Workspace Admin Console, navigate to the domain setup wizard, and select the option to add a TXT record. Google will generate a unique verification string that looks similar to this:

google-site-verification=rX9_AbCdEfGhIjKlMnOpQrStUvWxYz1234567890

Log into your DNS hosting provider—such as Cloudflare, GoDaddy, Namecheap, or Route 53 (note that specific menu names may differ slightly depending on your provider)—and locate your DNS management or zone editor dashboard. Create a new record with the following specifications:

• Type: TXT
• Host / Name: @ (or leave blank for your root domain, e.g., example.com)
• Value / Answer: Paste the exact google-site-verification string provided by Google
• TTL: 3600 seconds (or automatic)

Save the record, return to the Google Admin Console, and click Verify. DNS changes can occasionally take time to propagate globally. If verification fails immediately, wait 10 to 15 minutes and try again. You can check if your TXT record is visible globally by running a quick query via terminal:

dig TXT example.com +short

Step 2: Configuring Google Workspace MX Records

To receive emails sent to you@example.com through Gmail, you must update your Mail Exchanger (MX) records. MX records tell sending mail servers where to deliver your incoming messages.

Delete any existing MX records pointing to your old email provider to prevent delivery conflicts. Then, create the five standard Google Workspace MX records in your DNS zone file. Note that priorities must match exactly:

Here is an example of how these entries should look in a standard zone file format:

example.com.   3600   IN   MX   1   ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   5   ALT1.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   5   ALT2.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   10  ALT3.ASPMX.L.GOOGLE.COM.
example.com.   3600   IN   MX   10  ALT4.ASPMX.L.GOOGLE.COM.

Make sure to include the trailing dot (.) at the end of the mail server hostnames if your DNS provider requires fully qualified domain names (FQDN).

Step 3: Setting Up Email Authentication (SPF, DKIM, DMARC)

Configuring verification and MX records gets your email flowing, but security protocols are what keep your messages out of the spam folder. Modern email providers require Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).

1. Sender Policy Framework (SPF)

An SPF record authorizes Google to send emails on behalf of your domain. You can only have one active SPF record per domain.

Add a TXT record with these parameters:

• Host / Name: @
• Value: v=spf1 include:_spf.google.com ~all

2. DomainKeys Identified Mail (DKIM)

DKIM adds a cryptographic signature to every outgoing email, proving it was not altered in transit.

1. Go to your Google Workspace Admin Console.
2. Navigate to Apps > Google Workspace > Gmail > Authenticate email.
3. Select your domain and click Generate new record.
4. Copy the generated host name (often google._domainkey) and the long TXT record value.
5. Create a TXT record in your DNS manager using those exact values.
6. Return to the Google Admin Console and click Start authentication.

3. DMARC Policy

DMARC tells receiving servers what to do if an email fails SPF or DKIM checks. Start with a monitoring policy to ensure your mail flow is correct before enforcing strict rejection.

Add a TXT record with these parameters:

• Host / Name: _dmarc (resulting in _dmarc.example.com)
• Value: v=DMARC1; p=none; rua=mailto:admin@example.com; pct=100

DNS Setup Checklist

• Check domain ownership and registrar status using a lookup tool
• Add the Google Workspace TXT verification record
• Delete old MX records from previous providers
• Add all five Google MX records with correct priorities
• Publish the Google SPF include record
• Generate and publish your custom DKIM TXT record
• Implement a baseline DMARC monitoring policy
• Verify mail delivery by sending a test message

Common Mistakes and How to Fix Them

Even experienced engineers occasionally trip over subtle DNS syntax errors. Avoiding these common pitfalls saves hours of troubleshooting.

• Multiple SPF Records: If you have multiple services sending mail, do not create separate SPF records. Merge them into a single record like v=spf1 include:_spf.google.com include:mail.example.com ~all.
• Missing Trailing Dots: Some DNS panels automatically append your root domain to host entries. If you type aspmx.l.google.com. with a dot in a managed panel that auto-appends, it might resolve to aspmx.l.google.com.example.com. Check your provider's documentation regarding FQDN entries.
• Incorrect MX Priorities: Forgetting to set priorities or setting them all to 0 causes mail delivery loops or random routing failures. Always match Google's specified priorities (1, 5, 5, 10, 10).
• Forgetting Propagation Delays: DNS changes rely on TTL (Time to Live) values. If you recently changed your nameservers, old cached records might prevent verification for up to 24 hours.