Connecting Google Workspace to your own domain involves three independent sets of DNS records: MX handles routing incoming mail, SPF and DKIM keep messages from your domain from being rejected as forged, and DMARC sets the policy for messages that fail the first two checks. A mistake in any one of the three only breaks its own part: a wrong MX stops mail delivery, while a wrong SPF/DKIM usually doesn't stop you from receiving mail, but messages sent from the domain start landing in spam or getting rejected by recipients.
MX records for Google Workspace
| Priority | Server |
|---|---|
| 1 | ASPMX.L.GOOGLE.COM |
| 5 | ALT1.ASPMX.L.GOOGLE.COM |
| 5 | ALT2.ASPMX.L.GOOGLE.COM |
| 10 | ALT3.ASPMX.L.GOOGLE.COM |
| 10 | ALT4.ASPMX.L.GOOGLE.COM |
All five records need to be added at once, with no duplicates and no leftover MX records from a previous mail service — Google accepts mail through any of the five in priority order, and there's no need to remove the "extra" records that share a priority of 5 or 10; that's the normal load-balancing setup.
SPF for Google Workspace
# TXT record for @
v=spf1 include:_spf.google.com ~allActivating DKIM in Google Admin
Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record
Copy the DKIM record and add it as a TXT record in DNS:
# Record name:
google._domainkey.yourdomain.com
# Value:
v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEYVerification
# Check MX
dig yourdomain.com MX
# Via Google Admin Toolbox
# toolbox.googleapps.com/apps/checkmx/Common Errors Connecting Google Workspace
| Message | Cause | Fix |
|---|---|---|
| 550-5.7.1 The IP you're using to send mail is not authorized to send email directly to our servers | The sender's SPF record doesn't include the needed service or IP | Check dig TXT yourdomain.com and add the missing include mechanism |
| DKIM record not found. Public key not available for this selector | The google._domainkey TXT record hasn't propagated yet, or its name has a typo | Check dig TXT google._domainkey.yourdomain.com, wait out the TTL |
| Mail loops back to sender / too many hops | Old MX records from a previous mail provider are still mixed in with Google's records | Delete every MX record except Google's five official entries |
| SPF Permanent Error: too many DNS lookups | The SPF record has more than 10 include mechanisms — the RFC 7208 limit | Shorten the include chain, merge services into one flat list |
An independent tool worth using for quick diagnostics is mail-tester.com: it gives you an address to send a test message to, and within seconds it returns a breakdown of SPF, DKIM, and DMARC with the exact reason for any failure — faster than manually parsing message headers.
TTL for Google Workspace Records
| Record | TTL | Comment |
|---|---|---|
| MX | 3600 seconds | Google doesn't change its server addresses, the standard TTL is fine |
| TXT SPF | 3600 seconds | no need to lower it, the record rarely changes |
| TXT DKIM | 3600 seconds | can be temporarily lowered to 300 during initial activation |
When migrating from another mail provider, lower the TTL in advance, 24–48 hours before switching MX records, not at the moment of the switch itself — otherwise some incoming mail will keep going to the old server for another day, which will no longer accept it by the time it arrives.
DMARC on Top of SPF and DKIM
SPF and DKIM by themselves don't tell the recipient what to do with a message that fails them — that's DMARC's job. The record is created on the _dmarc subdomain:
# TXT record for _dmarc.yourdomain.com
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100A detailed plan for moving from monitoring to a strict policy is covered in the article DKIM + SPF + DMARC on a VPS — the principle of gradual tightening is the same regardless of where mail is hosted.
rua reports arrive once a day as XML archives from the major mail systems — Gmail, Outlook, Yahoo. Reading them by hand isn't practical, so in practice people use free parsers like dmarcian or Postmark DMARC Digests, which turn the archives into a readable table of sending sources.
When the Standard Setup Doesn't Fit
- The domain already uses a third-party mailing service for something else — a zone only allows one SPF-type TXT record, so the two sources need to be merged through a single include rather than creating a second record
- You need an alias domain within the same Workspace organization — MX and SPF are configured once on the primary domain, and the alias domain shouldn't have its own MX records
- A third-party relay is used for bulk mailings — then a separate include is added to the shared SPF record rather than a second SPF record, which DNS will technically let you create but which SPF validators handle unpredictably
- A zero-downtime migration from another mail provider requires lowering MX and TXT TTLs 24–48 hours in advance, see checking DNS propagation
Frequently asked questions
Should a DMARC policy start with strict rejection right away, or build up gradually?
A DMARC policy is usually rolled out in stages: starting with monitor mode, which doesn't affect delivery and just collects reports, then softer handling of suspicious messages, and only once things look stable does strict rejection follow. Jumping straight to rejection risks blocking a company's own legitimate mailings if some sending service isn't yet covered by SPF or DKIM.
What happens to messages that were already sitting in the old mailbox after switching to Google Workspace?
Old messages stay exactly where they were stored before the switch — changing MX only affects routing of new incoming mail, not the archive already received. To avoid losing anything, don't delete the previous mailbox right after the move; export the archive or keep access to it until every important message is confirmed transferred.
How long does it usually take for new DNS records to propagate across the internet?
How fast a record spreads across servers depends on the TTL set for it before the change: until that old lifetime expires, some resolvers worldwide keep returning the previous value. That's why major changes get planned ahead of time, lowering the TTL beforehand, and the result afterward gets checked through external services rather than just one computer.
Is it necessary to delete the old mail provider's MX records right away?
Removing the old MX records right away isn't technically required, but keeping them alongside Google's is not a good idea: mail can get routed unpredictably between the two services, and some messages can get lost in between. The right order is adding the five Google records, confirming mail reliably arrives there, and only then removing the previous provider's records.