Google Workspace DNS setup: MX, SPF, DKIM and DMARC

Gmail on your own domain needs one MX record, one SPF record, a DKIM key that you generate in the Admin console, and a DMARC record.

Provider names identify the service a guide is written for. Apart from Zarfio, which is our own e-mail service, they do not imply partnership or endorsement. Values that a provider generates per domain are never printed here: copy those from the provider’s panel.

Steps

  1. Verify the domain. Add your domain in the Google Admin console and publish the verification TXT record it shows. The value is unique to your account.
  2. Create the users. Create every mailbox and alias before moving MX, so no address bounces after the switch.
  3. Publish the MX record. Remove the old provider’s MX records and add a single MX record with priority 1 that points to smtp.google.com.
  4. Publish SPF. Add one TXT record at the apex: v=spf1 include:_spf.google.com ~all. If other services send for the domain, add their include: to the same record.
  5. Turn on DKIM. In the Admin console generate a 2048-bit key, publish the TXT record it shows at google._domainkey, then return and press "Start authentication". Until you do, Google signs with its own domain and DKIM does not align with yours.
  6. Add DMARC and check. Publish a DMARC record with p=none, then run the checks on this page.

DNS records for Google Workspace

Host "@" means the domain itself (example.com). Some DNS hosts want the field left empty, others want the full name: follow your DNS host’s convention.

PurposeTypeHostPriorityValue
Domain verificationTXT@—Generated for your domain. Copy it from the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email for DKIM; Account → Domains for verification).
Receive mail (MX)MX@1smtp.google.com.
SPFTXT@—v=spf1 include:_spf.google.com ~all
DKIMTXTgoogle._domainkey—Generated for your domain. Copy it from the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email for DKIM; Account → Domains for verification).
Domain verification
Type
TXT
Host
@
Value
Generated for your domain. Copy it from the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email for DKIM; Account → Domains for verification).
Receive mail (MX)
Type
MX
Host
@
Priority
1
Value
smtp.google.com.
SPF
Type
TXT
Host
@
Value
v=spf1 include:_spf.google.com ~all
DKIM
Type
TXT
Host
google._domainkey
Value
Generated for your domain. Copy it from the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email for DKIM; Account → Domains for verification).
  • Accounts set up before 2023 use five records instead: ASPMX.L.GOOGLE.COM (priority 1), ALT1 and ALT2.ASPMX.L.GOOGLE.COM (5), ALT3 and ALT4.ASPMX.L.GOOGLE.COM (10). Both forms work; do not mix them.
  • The DKIM selector is "google" unless you chose another prefix when generating the key.

DMARC

DMARC is the same for every provider: one TXT record at _dmarc.example.com. Start with p=none and a reporting address, so you receive reports without affecting delivery.

Read the reports for a few weeks. When every legitimate sender passes SPF or DKIM with an aligned domain, move to p=quarantine and then p=reject. Moving to reject before DKIM is on for all senders is the usual way legitimate mail gets lost.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Optional: MTA-STS, TLS-RPT and BIMI

MTA-STS tells sending servers to require TLS when delivering to you. It needs a TXT record and a policy file served over HTTPS at mta-sts.example.com; the policy must list the MX hosts of your provider exactly.

TLS-RPT asks senders to report TLS delivery failures to an address you choose. One TXT record, no effect on delivery.

BIMI lets some mailbox providers show your logo. It requires DMARC at quarantine or reject, and most providers also require a verified mark certificate.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

TTL advice

Before changing MX records on a domain that already receives mail, lower their TTL to 300 seconds and wait for the old TTL to run out. Resolvers then pick up the new records within minutes.

When the new setup has worked for a few days, raise the TTL again: 3600 seconds is a common value. SPF, DKIM and DMARC records change rarely and are fine at 3600.

How long do the changes take?

Your authoritative nameservers answer with the new record as soon as your DNS host has published it. A resolver that cached the old answer keeps it until the old TTL runs out; a name that did not exist before may be remembered as missing for the negative-caching time in your SOA record.

There is no moment at which a change is everywhere at once. The propagation tool shows what a fixed set of public resolvers answer at the time of the check, reported as a count such as "9 of 12 resolvers", and nothing more than that.

Providers re-check your records on their own schedule, so a verification button in the panel can stay red for a while after DNS is already correct.

Check your setup

Enter your domain and choose a check. Each one is a live lookup from our server; a lookup that fails is reported as "could not be checked", not as a missing record.

Common mistakes

  • Publishing the DKIM record but never pressing "Start authentication" in the Admin console.
  • Keeping ~all forever is acceptable with Google; changing to -all before every sender is listed is what breaks forwarding services and mailing tools.
  • Two SPF records. A domain may have only one TXT record that starts with v=spf1; a second one makes SPF fail with a permanent error. Merge the include: mechanisms into one record.
  • Leaving the old provider’s MX records next to the new ones. Mail is then delivered to either, depending on priority and chance.
  • Typing the full name into a host field that appends the domain, which produces google._domainkey.example.com.example.com. Look the record up after saving it.
  • A DKIM key cut in half. Long TXT values must be split into quoted strings of at most 255 characters; most DNS hosts do this for you, some do not.
  • More than ten DNS lookups in SPF after adding several include: mechanisms. The SPF checker counts them.
  • An MX record that points to a CNAME or to an IP address. It must point to a hostname that has A or AAAA records.

FAQ

Which MX record does Google Workspace use?

A single record, smtp.google.com with priority 1, for accounts set up from 2023 on. Older accounts use the five ASPMX.L.GOOGLE.COM records. Google accepts mail on both.

What is the SPF record for Google Workspace?

v=spf1 include:_spf.google.com ~all, as one TXT record at the apex of the domain. Other senders are added to the same record, not to a second one.

Where is the Google Workspace DKIM key?

In the Admin console under Apps → Google Workspace → Gmail → Authenticate email. The key is generated per domain, so it cannot be copied from a guide.

How can I check that it works?

Run the MX, SPF, DKIM (selector google) and DMARC checks on this page, then send a message to an outside mailbox and read the Authentication-Results header with the email header analyzer.