You have paid for Google Workspace, your users are waiting, and Gmail still is not delivering mail. The reason is almost always the same: one or more DNS records are missing, mistyped, or have not finished propagating. Google Workspace relies on at least five distinct DNS record types to handle mail delivery, prove domain ownership, stop spoofing, and enable outbound signing. Get any one of them wrong and you will face bounced messages, spam rejections, or a setup wizard that refuses to move past step one. This guide covers every record you need, the exact values to enter, how to add them at the most common registrars and hosts, and how to confirm the whole configuration is healthy before you hand accounts over to real users.
Why Google Workspace Needs Multiple DNS Records
Email is a surprisingly trust-heavy protocol. Before a remote mail server accepts a message claiming to come from your domain, it checks several signals embedded in DNS. Google Workspace needs each of these records to function:
- MX records tell the internet where to deliver inbound email for your domain.
- TXT ownership verification proves to Google that you actually control the domain before they activate your account.
- SPF record tells other mail servers that Google is authorized to send mail on your behalf.
- DKIM record adds a cryptographic signature so recipients can verify your messages have not been tampered with in transit.
- DMARC record tells receiving servers what to do when SPF or DKIM fails, and sends you reports about abuse.
Skipping any of these does not immediately break everything, but it will cause deliverability problems. Large providers like Microsoft 365 and Yahoo now reject or quarantine mail that lacks a valid DMARC policy entirely.
Step 1: The Domain Verification TXT Record
Before Google activates Gmail for your Workspace account, you must prove domain ownership. Google gives you a unique TXT record value in the Admin Console at admin.google.com. Navigate to Account > Domains > Manage domains, then click Verify next to your domain. You will see a string like this:
Add this record at your DNS host or domain registrar. The exact field label varies: GoDaddy calls it Host, Cloudflare calls it Name, Namecheap calls it Host. Enter @ or leave the field blank to target the root domain. Once you save it, return to the Admin Console and click Verify. Google polls for the record immediately but may take a few minutes if your registrar propagates slowly. Do not move on to MX records until verification succeeds, because some registrars lock MX changes until ownership is confirmed.
Step 2: MX Records for Inbound Mail
MX records route inbound email. Google Workspace requires five MX entries, each pointing to a different Google mail server with a specific priority number. Lower priority numbers are tried first.
A few important notes: the trailing dot at the end of each hostname is correct DNS syntax, though most control panels add it automatically. Delete any existing MX records first before adding the Google ones. Leaving old MX records in place, especially if they point to your web host's mail server or a previous email provider, will split your incoming mail between two destinations and cause random message loss that is extremely difficult to diagnose.
On cPanel hosts (Bluehost, HostGator, SiteGround shared plans), go to Email > MX Entry in cPanel, set routing to Remote Mail Exchanger, then add each Google MX record individually. On Cloudflare, navigate to DNS > Records and make sure the proxy toggle is set to DNS only (grey cloud) for MX records. MX records cannot be proxied.
Step 3: SPF Record
SPF (Sender Policy Framework) is a TXT record on your root domain that lists the mail servers allowed to send email as your domain. For Google Workspace, the record is standardized:
The include:_spf.google.com pulls in Google's own published list of sending IPs, so you never need to maintain individual IP addresses. The ~all at the end is a softfail, meaning mail from unlisted sources is accepted but marked. Many security-conscious administrators prefer -all (hardfail) which outright rejects non-listed senders, but test with ~all first to avoid accidentally blocking legitimate forwarded mail.
Critical constraint: a domain can only have one SPF TXT record. If you already have an SPF record for another service, merge the includes into a single record rather than creating a second one. Two SPF records cause an SPF permanent error (permerror) which is treated as a failure by all major providers.
Example of a merged SPF record if you also send through Mailchimp:
Step 4: DKIM Record
DKIM (DomainKeys Identified Mail) requires generating a key pair inside Google's Admin Console, then publishing the public key as a TXT record in DNS. Navigate to Apps > Google Workspace > Gmail > Authenticate email. Select your domain and click Generate new record. Choose a 2048-bit key (recommended over 1024-bit).
Google will display a TXT record to add in this format:
The Host value google._domainkey is a subdomain, not the root. At registrars that append the domain automatically, enter exactly google._domainkey. At providers where you enter the full FQDN, enter google._domainkey.yourdomain.com. The key string is very long; copy it carefully and check for line breaks if your DNS control panel wraps text.
After saving the DNS record, wait at least 10 minutes, then return to the Admin Console and click Start authentication. Google checks for the record and enables signing. If it fails, use our DNS Lookup tool to query the TXT record for google._domainkey.yourdomain.com and confirm the full key value is visible and intact before troubleshooting further.
Step 5: DMARC Record
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the final layer. Without it, even a perfectly configured SPF and DKIM setup gives you no visibility into abuse and fails the new Google and Yahoo sender requirements introduced in 2024.
Start with a monitoring-only policy so you can collect reports before you start blocking anything:
After reviewing reports for two to four weeks and confirming that all your legitimate sending sources pass SPF or DKIM alignment, tighten the policy:
Eventually move to p=reject for the strongest protection. The rua address receives aggregate XML reports daily. Several free services like Google Postmaster Tools and dmarcian's free tier will parse these for you if raw XML is not your preference.
Complete DNS Record Checklist
Here is a summary of all five record types in one place for easy reference:
- Verification TXT at
@with your unique google-site-verification value. - Five MX records at
@pointing to ASPMX.L.GOOGLE.COM and the four ALT servers. - SPF TXT at
@:v=spf1 include:_spf.google.com ~all - DKIM TXT at
google._domainkeywith the key generated in Admin Console. - DMARC TXT at
_dmarcstarting withp=noneand an rua address.
How to Add These Records at Common Providers
GoDaddy
Log in, go to My Products, click DNS next to your domain. Use Add to create each record type. For MX records, select type MX, enter @ as the host, enter the server name as the value, and set priority as a separate field.
Namecheap
Go to Domain List, click Manage, then Advanced DNS. Use Add New Record. Namecheap automatically appends the domain to any subdomain entry, so enter google._domainkey not the full FQDN.
Cloudflare
Go to DNS > Records. All record types are in the same interface. Ensure all email-related records are set to DNS only (grey cloud icon). Cloudflare proxying email records is a common source of mail failures because the Cloudflare proxy does not handle SMTP traffic.
Google Domains / Squarespace DNS
If your domain is registered through Google Domains (now migrated to Squarespace), log in to domains.squarespace.com, select your domain, go to DNS, and use Add record. Note that Squarespace provides a one-click Google Workspace MX setup button if you purchased Workspace through them.
How to Verify Everything Is Working
Do not assume the records are correct just because you saved them. Check each one explicitly before sending mail to real users.
Check MX records from the command line:
Check SPF:
Check DKIM:
Check DMARC:
On Windows, replace dig with nslookup -type=MX yourdomain.com or nslookup -type=TXT yourdomain.com. You can also use Google's Check MX tool at toolbox.googleapps.com/apps/checkmx to run an official verification directly from Google's infrastructure. After sending a live test email, check the full email headers for Authentication-Results lines. You want to see spf=pass, dkim=pass, and dmarc=pass.
Common Problems and Fixes
Mail still going to the old server
You have not deleted the old MX records. Run dig MX yourdomain.com and look for any entries that do not point to Google. Delete them immediately.
DKIM shows as not authenticated in Admin Console
Either the record has not propagated yet, or there is a line-break in the key value. Some DNS control panels silently truncate long TXT values. If your provider limits TXT records to 255 characters, you may need to split the DKIM key into two quoted strings within the same TXT record.
SPF permerror
You have more than one TXT record that starts with v=spf1. Merge them into one. There is no legitimate reason to have two SPF records on the same hostname.
Verification TXT record not found
If you are on Cloudflare, make sure the TXT record is set to DNS only. If you added the record at a different DNS provider than where the domain is currently resolving, the nameservers may be pointing elsewhere. Run dig NS yourdomain.com to confirm which nameservers are authoritative and add the records there.
Ongoing Maintenance
Google Workspace DNS records are not fully set-and-forget. DKIM keys should be rotated annually as a security best practice. In the Admin Console you can generate a new key while the old one remains active, deploy the new DNS record, wait for propagation, switch authentication to the new key, then remove the old DNS record. DMARC policies should be reviewed quarterly as your sending infrastructure evolves. Whenever you add a new tool that sends email on your behalf, such as a CRM, helpdesk, or marketing platform, update your SPF record and, ideally, configure DKIM for that service as well so DMARC alignment is maintained across all outbound streams.