DNS Setup for Google Workspace: MX, SPF, DKIM, and DMARC

Getting email right for Google Workspace comes down to four DNS record groups: MX records so mail reaches Gmail, SPF so receivers know Google is allowed to send for you, DKIM so your messages are cryptographically signed, and DMARC so you can monitor and enforce the first two. Set them in that order, verify each one, and your domain will send and receive reliably. Here is the complete record set with the exact values and verification steps.

Before you start

You need access to your domain's DNS zone at your registrar or DNS host, and an active Google Workspace account where your domain is added. Make one change at a time and verify it before moving on. Remember that every change is subject to TTL, so a record can take anywhere from minutes to a few hours to be visible everywhere.

Step 1: MX records

MX records tell the rest of the internet which servers accept mail for your domain. Since April 2023, Google uses a single simplified MX record for new setups. The older five-record set still works and remains valid for existing domains.

The modern single record:

The legacy five-record set, still supported:

Use one approach or the other, never both, and delete any MX records from a previous mail provider. The lower the priority number, the higher the preference, so mail tries smtp.google.com (priority 1) first. Verify with a query:

$ dig MX example.com +short
1 smtp.google.com.

Step 2: SPF record

SPF (Sender Policy Framework) is a single TXT record at your root domain that lists who is allowed to send mail as your domain. For Google Workspace, the include does the work:

Two rules keep SPF valid. First, a domain may have only one SPF record; if you send through other services too, merge them into a single record rather than publishing several. Second, SPF is limited to 10 DNS lookups total, so chaining many includes will cause a permanent error. The ~all at the end is a softfail, the recommended setting while you confirm everything works. Verify:

$ dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"

Step 3: DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message so receivers can confirm it was not altered and really came from your domain. Unlike MX and SPF, you must first generate the key inside Google Workspace, because the value is unique to your domain.

1. In the Google Admin console, go to Apps > Google Workspace > Gmail > Authenticate email.
2. Select your domain and choose a 2048-bit key, then click Generate new record.
3. Google shows a selector (by default google) and a long TXT value beginning with v=DKIM1.
4. Create a TXT record at your DNS host using that selector.

After the record is live, return to the Admin console and click Start authentication. The DKIM value is long and often exceeds the 255-character limit for a single DNS string, so your DNS host may split it into multiple quoted chunks automatically. That is correct; just be sure nothing was truncated. Verify the selector:

$ dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ..."

Step 4: DMARC

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both, while sending you reports. It is a TXT record at the _dmarc subdomain. Start in monitoring mode so you can watch results before enforcing anything.

The p=none policy takes no action; it only collects data. The rua address receives daily aggregate reports showing which sources sent mail as your domain and whether they passed authentication. Once reports confirm your legitimate mail is aligned and passing, tighten the policy in stages: move to p=quarantine, then eventually p=reject. Verify:

$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

Recommended rollout order

1. Publish MX and confirm mail flows into Gmail.
2. Publish SPF and send a test message to a Gmail address, then check the headers for spf=pass.
3. Generate and publish DKIM, start authentication in the console, and confirm dkim=pass in a test message's headers.
4. Publish DMARC at p=none, collect reports for a week or two, then ramp the policy up.

Confirming authentication on a real message

DNS records are only half the picture; what matters is whether Gmail marks your mail as authenticated. The fastest check is to send a message from your Workspace account to a personal Gmail address, open it, and view the original.

1. In Gmail, open the test message, click the three-dot menu, and choose Show original.
2. Look at the summary box at the top. You want to see PASS next to SPF, DKIM, and DMARC.
3. If DKIM shows neutral or is absent, authentication was never started in the Admin console, or the selector record has not gone live yet.
4. If SPF fails, confirm you are sending through Google and that the include is spelled exactly include:_spf.google.com.

This single test catches the vast majority of setup errors, because it shows the receiver's own verdict rather than just the record you published. A record can look perfect in a lookup and still fail if, for example, the DKIM key was truncated when pasted.

Common mistakes to avoid

• Leaving old MX records in place. Mail from a previous host competes with Google and causes lost messages. Remove them.
• Publishing two SPF records. This is invalid; merge all senders into one.
• Enforcing DMARC too soon. Jumping straight to p=reject can bounce legitimate mail from services you forgot about. Always start at none.
• A truncated DKIM key. If authentication fails, the usual cause is a key that was cut off during paste or not split correctly across strings.

Verify every record before you trust it

Each of these records fails silently if a value is off by a character, and a local dig only shows one resolver's view. After publishing, run your domain through the Valla DNS propagation checker to confirm the MX, SPF, DKIM, and DMARC records have gone live across regions, not just on your machine. For the enforcement phase, our guides on reading a DMARC aggregate report and on SPF lookup limits will help you tighten policy without breaking delivery. Set the records carefully, verify each one, and Google Workspace email becomes something you never have to think about again.