How do I set up Google Workspace MX records?

To route email for your domain to Google Workspace, add five MX records at your DNS host pointing to Google's mail servers, then delete any pre-existing MX records from your old provider. Propagation typically takes minutes to a couple of hours. Once the records are live, every message sent to @yourdomain.com lands in Gmail — no changes to your web hosting or any other DNS records are required.

The five MX records Google Workspace requires

Add all five records. Google's inbound mail infrastructure is distributed and uses all five hostnames for redundancy and load balancing. Omitting the lower-priority entries leaves you exposed during failover events.

• ASPMX.L.GOOGLE.COM — Priority 1
• ALT1.ASPMX.L.GOOGLE.COM — Priority 5
• ALT2.ASPMX.L.GOOGLE.COM — Priority 5
• ALT3.ASPMX.L.GOOGLE.COM — Priority 10
• ALT4.ASPMX.L.GOOGLE.COM — Priority 10

The Host or Name field for every record is @ (or your bare domain, e.g., example.com, depending on the registrar interface). Set TTL to 3600 seconds. MX records must point to fully qualified hostnames — never IP addresses. An IP in the value field silently breaks delivery because remote SMTP servers expect a hostname they can resolve further to an A or AAAA record.

Step-by-step by registrar and DNS host

The fields and menu labels differ across platforms, but the five hostnames and priorities you enter are identical everywhere. Match your host below.

GoDaddy

1. Sign in at godaddy.com, open My Products, and click DNS next to your domain.
2. Scroll to the MX section and click Add.
3. Set Host to @, paste the first hostname into Points to, and enter the priority.
4. Click Save. Repeat for all five entries — GoDaddy saves each record individually.
5. After adding all five, delete any MX records pointing to your previous mail host.

Namecheap

1. Log in, go to Domain List, and click Manage next to your domain.
2. Open the Advanced DNS tab.
3. Under Mail Settings, switch the mail provider dropdown to Custom MX. If you leave it on Namecheap's private email option, your manually entered records will be silently ignored.
4. Click Add New Record, choose type MX, set Host to @, enter the hostname and priority, then save.
5. Repeat five times. Delete any MX rows that pointed to the previous provider.

Cloudflare

1. Open the Cloudflare dashboard, select your domain, and click DNS → Records.
2. Click Add record. Set type to MX, Name to @, enter the mail server hostname, and set Priority.
3. Leave the proxy toggle off (grey cloud) — MX records cannot be proxied through Cloudflare.
4. Repeat for all five. Delete old MX records.

Cloudflare propagates DNS changes globally within seconds for zones it serves, so you can run a dig verification almost immediately after saving.

cPanel (SiteGround, Hostinger hPanel, and other shared hosts)

Many shared hosts use cPanel or a derivative. Hostinger uses hPanel with a similar layout. The exact menu path varies by host and firmware version — look for a DNS Zone Editor or MX Entry section.

1. In cPanel, search for Zone Editor or navigate to Domains → Zone Editor.
2. Click Manage next to your domain.
3. Click + Add Record and choose type MX.
4. Name: your domain with a trailing dot (e.g., example.com.), Priority: 1, Destination: ASPMX.L.GOOGLE.COM.
5. Save, then repeat for the remaining four records.
6. Delete the default MX records cPanel pre-populated — these usually point to your hosting server's own hostname.

On Hostinger hPanel: go to Hosting → Manage → DNS Zone. The Add Record button sits at the top of the zone table. Select MX, enter the Google hostname and priority. The same deletion step applies.

Delete your old MX records

This is the step most commonly skipped and the most common cause of split delivery. If you leave your previous provider's MX records in place alongside Google's, sending mail servers pick whichever record wins on priority — and that might still route messages to your old mailbox instead of Gmail.

Delete every MX record pointing to a hostname that is not *.google.com. Common legacy entries include:

• mail.yourdomain.com or a bare-domain entry pointing to your web hosting server
• mx1.registrar-email.com or mx2.registrar-email.com from a bundled registrar mailbox
• Entries ending in .mailgun.org, .sendgrid.net, or similar from a transactional mail service

It is safe to delete them once you have confirmed the five Google records are saved and showing in the zone.

Verify with dig, nslookup, and resolvectl

Run CLI verification before sending a test message. These commands bypass browser DNS caches and your OS resolver cache so you see what the global internet actually returns right now.

Linux and macOS — dig

Expected output (record order may vary by resolver):

To query Google's public resolver directly and skip any local cache:

Linux — resolvectl

On systemd-resolved systems (Ubuntu 20.04+, Debian 11+):

This uses the system stub resolver. If DNS-over-TLS is configured, the query goes out encrypted — the result should still match a direct dig query against the same upstream resolver.

Windows — nslookup

Run this in Command Prompt or PowerShell. Specifying 8.8.8.8 directly sidesteps the Windows DNS client cache and returns current data rather than a stale cached answer from your ISP's resolver.

Flushing local DNS cache

If dig against 8.8.8.8 returns the correct Google records but your machine's system resolver still returns old data, flush the local cache:

• Windows: ipconfig /flushdns in an elevated Command Prompt
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): sudo resolvectl flush-caches
• Android / iOS: toggle airplane mode off and on, or reconnect to Wi-Fi to force a resolver reset

Add the SPF record

An SPF TXT record declares that Google's servers are authorized to send mail on behalf of your domain. Without it, outbound mail from Workspace frequently lands in spam at recipient servers. Add this as a TXT record with Host set to @:

If you already have an SPF record for another service — your web host, a CRM, or a transactional mail platform — merge the includes on a single TXT record rather than creating a second one. Two SPF records cause a PermError at receiving servers:

Confirm the record is publishing:

Set up DKIM signing

DKIM adds a cryptographic signature to outbound messages so receiving servers can verify the message was not altered in transit. The key is generated inside the Google Workspace admin console; you then add the resulting TXT record to your DNS zone.

1. Go to admin.google.com, then Apps → Google Workspace → Gmail → Authenticate email.
2. Select your domain and click Generate new record. Leave the key length at 2048-bit.
3. Copy the DNS Host name (e.g., google._domainkey) and the full TXT record value — a long string beginning with v=DKIM1; k=rsa; p=.
4. Add a TXT record at your DNS host: Name = google._domainkey (registrars that append the domain automatically) or google._domainkey.yourdomain.com (registrars that require the full hostname). Value = the complete string from the admin console.
5. Return to the admin console and click Start authentication. Workspace polls for the TXT record and updates the status once it resolves — allow a few minutes after DNS propagates.

If authentication fails, check that the full key value was saved without truncation. Some registrar interfaces impose a 255-character limit per string chunk in TXT records. Paste the value in one shot without manually adding quotes or line breaks unless your registrar's documentation explicitly instructs otherwise.

Add a DMARC record

DMARC tells receiving servers what to do when a message fails both SPF and DKIM checks, and can deliver forensic reports to your inbox. Add this as a TXT record at _dmarc.yourdomain.com to start in monitor-only mode:

The p=none policy collects data without blocking or quarantining mail. Once you have verified that all legitimate outbound mail is authenticating correctly through SPF and DKIM, tighten the policy to p=quarantine or p=reject. The full specification is RFC 7489.

Confirm mail is flowing

1. Send a test message from an external account (personal Gmail, Outlook, or ProtonMail) to your Workspace address.
2. Check your inbox at mail.google.com. If the message arrives, inbound routing is working.
3. Open the message and select Show original from the three-dot menu. The first Received: header line should reference a Google mail server, not your old hosting server.
4. For granular debug, go to admin.google.com → Apps → Google Workspace → Gmail → Email Log Search and search by recipient address. This shows every delivery event and any rejection reasons.

If mail still routes to your old mailbox, run dig MX yourdomain.com @8.8.8.8 again. If the old provider's records still appear, either propagation is still in progress or the new records were not saved correctly at your DNS host.

Common misdiagnoses

Pointing MX at an IP address

MX records require hostnames, not IP addresses. Per RFC 1035, remote SMTP servers resolve an MX value to an A or AAAA record as a second lookup step. A bare IP address in an MX record value causes delivery failures because that second lookup cannot succeed against a numeric address.

Trailing dot confusion

Some DNS interfaces require a trailing dot on fully qualified hostnames (e.g., ASPMX.L.GOOGLE.COM.) while others append it automatically. If you include a trailing dot where the interface also adds one, you end up with a double-dot that creates a broken record. Save a record and reload the zone view to verify what was actually stored before proceeding.

cPanel local mail exchanger left enabled

cPanel's MX Entry tool includes a routing mode setting. When set to Local Mail Exchanger, cPanel intercepts all inbound mail at the hosting server before it can reach Google's servers — regardless of what your MX records say. Switch this to Remote Mail Exchanger whenever routing email to an external provider.

Mixing Google MX records with another provider's

Running MX records for Google and a previous provider simultaneously splits delivery unpredictably. Sending servers select records randomly within the same priority tier. All non-Google MX records must be fully deleted — lowering their priority is not sufficient.

Forgetting the final Save

Some registrar interfaces have a per-record Save button and a separate global page-level Save. After adding all five records, reload the DNS management page and confirm all five rows appear. If any are missing, they were never persisted and the page reload discarded them.

Propagation timing

MX changes propagate based on the TTL of the records being replaced, not the TTL of the new records you just added. If your old MX records had a TTL of 86400 (24 hours), resolvers that cached them before your change can serve the old answer for up to 24 hours. To cut this window, lower the TTL on your existing MX records to 300 seconds at least 24 hours before the planned switchover. Once that shorter TTL has propagated worldwide, make the change — resolvers will pick up the new records within 5 minutes.

2026 notes: DNSSEC, DNS-over-HTTPS, and IPv6

If your domain has DNSSEC enabled — increasingly common via one-click setup at Cloudflare, Namecheap, and GoDaddy — your DNS host signs new records automatically when you add them. Verify signing with:

An RRSIG record in the output confirms the MX record set is signed. A missing RRSIG when DNSSEC is enabled causes resolution failures at security-strict resolvers, which will refuse to return an unsigned answer for a signed zone.

DNS-over-HTTPS and DNS-over-TLS encrypt queries in transit but resolve to the same records — they have no effect on MX record content or propagation timing. If your browser's built-in DoH resolver returns different results from dig, temporarily disable it (Chrome: Settings → Privacy and security → Security → Use secure DNS, toggle off) to compare results and rule out a stale DoH cache.

IPv6 has no direct impact on MX records themselves. Google's Workspace mail servers accept connections over both IPv4 and IPv6, and the five Google MX hostnames resolve correctly on IPv6-only networks.