How to set up DNS records for Google Workspace email?

Sajjad
DNS
10 Oct, 2026

To set up DNS records for Google Workspace email, add five records at your domain's DNS provider: a TXT verification record that proves you own the domain, an MX record pointing to smtp.google.com with priority 1 so mail is delivered to Gmail, an SPF TXT record containing include:_spf.google.com, a DKIM TXT record that you generate in the Google Admin console, and a DMARC TXT record at _dmarc. Verification and MX are what make email work. SPF, DKIM and DMARC are what make it trusted and keep it out of spam.

Google's setup wizard walks you through some of this, but it doesn't always explain what each record does or what to do with records you already have. This guide covers every record in the order that avoids lost mail, with exact values, how to handle an existing email provider, how to check everything with dig, and the problems that most often stop Google Workspace mail from working.

The Records at a Glance

Here's the full set for a domain called example.com:

Purpose	Type	Name	Value
Domain verification	`TXT`	`@`	`google-site-verification=<your token>`
Mail delivery	`MX`	`@`	`smtp.google.com` (priority 1)
SPF	`TXT`	`@`	`v=spf1 include:_spf.google.com ~all`
DKIM	`TXT`	`google._domainkey`	`v=DKIM1; k=rsa; p=<your public key>`
DMARC	`TXT`	`_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`

In zone file form, that looks like this:

$ORIGIN example.com.

@                  3600  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
@                  3600  IN  MX   1 smtp.google.com.
@                  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
                                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )
_dmarc             3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The verification token and DKIM key above are examples. Yours come from the Admin console and are unique to your account.

Before You Start

You'll need:

Super admin access to the Google Admin console at admin.google.com.
Access to your DNS provider, which may be your registrar, your web host, or a service like Cloudflare.
A list of your current email records, especially if you're moving from another provider.

Find out where your DNS is managed:

dig +short example.com NS

And check what MX records exist today:

dig +short example.com MX

If this returns records for another provider, mail is currently being delivered there. Keep that in mind for Step 2.

Step 1: Verify Your Domain

Google needs proof that you control the domain before it will accept mail for it. In the Admin console, the setup wizard shows a verification record. It's normally a TXT record at the root of your domain:

Type:  TXT
Name:  @
Value: google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ
TTL:   3600

Add it at your DNS provider. If you already have other TXT records at @, such as an SPF record or another service's verification, that's fine. A name can have many TXT records. Just add a new one rather than editing an existing one.

Check that it's published:

dig +short example.com TXT | grep google-site-verification

"google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

Then return to the Admin console and click Verify. If it fails straight away, wait a few minutes and try again. Leave this record in place after verification. Google may check it again later.

Step 2: Add the MX Record

MX records tell other mail servers where to deliver email for your domain. Since 2023, Google has recommended a single MX record for new setups:

Type:     MX
Name:     @
Value:    smtp.google.com
Priority: 1
TTL:      3600

What About the Old Five MX Records?

You may have seen this older set in guides or in existing setups:

@  3600  IN  MX  1   aspmx.l.google.com.
@  3600  IN  MX  5   alt1.aspmx.l.google.com.
@  3600  IN  MX  5   alt2.aspmx.l.google.com.
@  3600  IN  MX  10  alt3.aspmx.l.google.com.
@  3600  IN  MX  10  alt4.aspmx.l.google.com.

These still work, and there's no need to change them if you already have them. For a new setup, use smtp.google.com. Don't mix the two sets.

Removing the Old Provider's MX Records

This is the step that most often causes lost or split mail. If your domain has MX records for another provider, delete them when you add Google's. If both are present, senders will deliver to whichever has the lowest priority number, and some mail may go to each.

If you're migrating from another provider:

Create users in Google Workspace first, with the same addresses as before.
Lower the TTL on your existing MX records to 300 seconds a day in advance.
Switch the MX records to Google at a quiet time.
Keep the old mailboxes active for a few days, because some mail may still arrive there while caches expire.
Migrate old mail using Google's data migration tools once delivery has moved.

Check the MX Record

dig example.com MX +noall +answer

example.com.        3600    IN  MX  1 smtp.google.com.

Send a test email from an external account, such as a personal address at another provider, to a Workspace user. Once it arrives, mail delivery is working.

Step 3: Add SPF

SPF lists the servers allowed to send mail as your domain. For a domain that sends only through Google Workspace:

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com ~all

Google's own documentation uses ~all (soft fail). Once DMARC is enforcing, receivers act on the DMARC result anyway, so many administrators move to -all (hard fail) once they're confident every sender is listed.

There can only be one SPF record. If you already have one, add Google's include to it rather than creating a second:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.25 ~all

Two separate v=spf1 records cause SPF to fail with a permanent error. Check for duplicates:

dig +short example.com TXT | grep -c "v=spf1"

The result should be 1.

Step 4: Set Up DKIM

DKIM signs every message with a private key held by Google. You publish the public key in DNS so receivers can verify the signature. Google doesn't sign with your domain's key until you generate it and turn it on.

In the Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
Select your domain and click Generate new record.
Choose a 2048-bit key, unless your DNS provider can't handle long TXT records, in which case use 1024-bit.
Leave the selector (Google calls it the prefix) as google, unless you already use that selector for something else.
Copy the DNS Host name and TXT record value.

Add the record at your DNS provider:

Type:  TXT
Name:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

A 2048-bit key is longer than the 255-character limit for a single TXT string. Most DNS dashboards split it into multiple strings automatically, which is correct and valid. If yours asks you to do it manually, split the value into chunks under 255 characters, each in its own set of quotes, as shown in the zone file at the top of this article.

Check that the key is published:

dig +short google._domainkey.example.com TXT

Once it appears, go back to the Admin console and click Start authentication. Google may take a little while to begin signing.

To confirm DKIM is working, send an email to an external Gmail address, open it, choose Show original, and look for:

DKIM:   'PASS' with domain example.com

Step 5: Add DMARC

DMARC ties SPF and DKIM to the address people actually see in the From field, and tells receivers what to do with mail that fails. Start in monitoring mode:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none: Take no action on failures, just report them.
rua=: Where to send aggregate reports. Use a mailbox or a DMARC reporting service.

Google and Yahoo require a DMARC record for bulk senders, and having one helps deliverability for everyone. After a few weeks of reports show that all your legitimate mail passes, move gradually to p=quarantine and then p=reject.

Check it:

dig +short _dmarc.example.com TXT

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Checking Everything at Once

This short script checks each record and reports anything missing:

#!/usr/bin/env bash
DOMAIN="${1:-example.com}"
SELECTOR="${2:-google}"

check() {
  local label="$1" result="$2"
  if [ -n "$result" ]; then
    printf "%-14s OK   %s\n" "$label" "$result"
  else
    printf "%-14s MISSING\n" "$label"
  fi
}

check "Verification" "$(dig +short "$DOMAIN" TXT | grep google-site-verification | head -1)"
check "MX"           "$(dig +short "$DOMAIN" MX | grep -i google | tr '\n' ' ')"
check "SPF"          "$(dig +short "$DOMAIN" TXT | grep 'v=spf1' | grep '_spf.google.com')"
check "DKIM"         "$(dig +short "${SELECTOR}._domainkey.$DOMAIN" TXT | cut -c1-40)"
check "DMARC"        "$(dig +short "_dmarc.$DOMAIN" TXT)"

chmod +x check-workspace-dns.sh
./check-workspace-dns.sh example.com

Verification   OK   "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
MX             OK   1 smtp.google.com.
SPF            OK   "v=spf1 include:_spf.google.com ~all"
DKIM           OK   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w
DMARC          OK   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Google also offers the Check MX tool in its Admin Toolbox at toolbox.googleapps.com, which checks your records and flags common problems.

Optional: MTA-STS and TLS Reporting

Once the basics work, you can require encrypted delivery to your domain with MTA-STS. It needs a TXT record, a policy file served over HTTPS, and optionally a TLS reporting record:

_mta-sts.example.com.   3600  IN  TXT  "v=STSv1; id=20261015"
_smtp._tls.example.com. 3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The policy file is served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: smtp.google.com
max_age: 86400

The mx lines must match your MX records. If you use the older five-record set, list aspmx.l.google.com and *.aspmx.l.google.com instead. Start in testing mode, review the TLS reports, then switch to enforce and increase max_age. Change the id value every time you update the policy.

Common Problems

Mail Still Arrives at the Old Provider

Old MX records are still present, or resolvers are caching them. Check what the world sees:

dig @8.8.8.8 +short example.com MX
dig @1.1.1.1 +short example.com MX

If either shows the old provider, check your DNS dashboard for leftover records and wait for the old TTL to expire.

"MX Records Not Found" in the Admin Console

Make sure the MX record is at the root (@), not at a name like mail or smtp. Some dashboards also want the target with a trailing dot (smtp.google.com.) and others without. If the value ends up as smtp.google.com.example.com, the dashboard added your domain to it.

DKIM Record Not Found

Check the name carefully. It should be google._domainkey, which your provider turns into google._domainkey.example.com. Entering the full name in some dashboards results in google._domainkey.example.com.example.com:

dig +short google._domainkey.example.com.example.com TXT

If that returns your key, you've found the problem.

Outgoing Mail Goes to Spam

Confirm SPF passes, DKIM is turned on in the Admin console (not just published), and DMARC exists. Check Show original on a sent message for the SPF, DKIM and DMARC results.

FAQ: Google Workspace DNS

For new setups, use a single MX record with the value smtp.google.com and priority 1. The older set of five aspmx.l.google.com records still works, so there's no need to change an existing setup that uses them.

Usually within an hour, depending on your DNS provider and the TTL of any MX records you replaced. Google says changes can take up to 72 hours in some cases, but most domains start receiving mail much sooner.

Yes, but merge them into one record. Add include:_spf.google.com to your existing SPF record instead of creating a second, because more than one SPF record makes SPF fail.

It isn't required for mail to flow, but it's strongly recommended. Without your own DKIM key, Google signs with a default key that doesn't align with your domain for DMARC, which makes deliverability worse.

Google recommends keeping it. Removing it can cause the domain to become unverified later, and it does no harm to leave it in place.

Use 2048-bit unless your DNS provider genuinely can't store it. Longer keys are more secure, and almost all modern DNS providers handle the split TXT strings that 2048-bit keys need.

Conclusion

Google Workspace email needs five DNS records: a verification TXT, an MX record for smtp.google.com, an SPF record including _spf.google.com, a DKIM key generated in the Admin console, and a DMARC record. Verification and MX make mail flow. SPF, DKIM and DMARC make sure receivers trust it.

Work through them in order, remove any old provider's MX records when you switch, merge rather than duplicate SPF, and remember to click Start authentication after publishing DKIM. Check each record with dig, send a few test messages in both directions, and then tighten your DMARC policy once the reports show everything passing.