Introduction

The Route 53 error saying an MX record "doesn't have 2 fields" means the value you entered is not in valid MX format. An MX record must contain exactly two pieces of information: a numeric priority and a mail server hostname.

This comes up often when configuring Google Workspace, especially if you are following older G Suite instructions or copying values from a guide written for a different DNS provider. The fix is usually simple once you know what Route 53 expects.

What Route 53 Expects for an MX Record

In Route 53, each MX value is stored as a single string containing:

• a priority number
• a destination mail host

A valid value looks like this:

1 smtp.google.com.

If you omit the priority, add extra tokens, or paste data in the wrong column, Route 53 complains because it cannot split the value into the required two fields.

AWS documents this format directly: an MX record contains a priority and a domain name. Google Workspace currently supports a single MX destination of smtp.google.com, while older Google setups may still use the legacy aspmx hosts.

Google Workspace Values You Can Use

For most current Google Workspace setups, a single MX record is enough:

1 smtp.google.com.

If you are maintaining an older configuration that still uses the legacy Google hosts, the values look like this:

11 aspmx.l.google.com.
25 alt1.aspmx.l.google.com.
35 alt2.aspmx.l.google.com.
410 alt3.aspmx.l.google.com.
510 alt4.aspmx.l.google.com.

Use one approach consistently. Do not leave old MX records from another mail provider in place, and do not mix unrelated providers unless you intentionally understand the delivery order.

Creating the Record in Route 53

In the Route 53 console, the host name is usually the zone apex, often left blank or entered as @ depending on the screen you are using. The important part is the MX record value itself.

If you use the AWS CLI or CloudFormation, the same rule applies: each record value must be one string containing priority plus hostname.

1{
2  "Comment": "Google Workspace MX",
3  "Changes": [
4    {
5      "Action": "UPSERT",
6      "ResourceRecordSet": {
7        "Name": "example.com.",
8        "Type": "MX",
9        "TTL": 300,
10        "ResourceRecords": [
11          { "Value": "1 smtp.google.com." }
12        ]
13      }
14    }
15  ]
16}

That payload is valid because the MX value has exactly two parts. If you changed it to only smtp.google.com. or to something like 1 priority smtp.google.com., Route 53 would reject it.

Verifying the Change

After saving the record, allow time for DNS propagation. You can then confirm the published result with dig:

dig MX example.com +short

Expected output for the current Google Workspace setup looks like this:

1 smtp.google.com.

If you still see the old provider, you may be editing the wrong hosted zone, the domain may not be delegated to the Route 53 name servers yet, or cached results may still be visible.

Common Pitfalls

• Entering only the server name without the priority. Route 53 needs both values in MX format.
• Pasting provider-specific instructions into the wrong fields. Some DNS dashboards separate priority from destination, while Route 53 often expects a combined value string.
• Leaving older MX records from Microsoft 365, Zoho, SES, or a previous host. Mail delivery can become inconsistent if multiple providers remain configured.
• Editing the hosted zone but forgetting to update the domain's authoritative name servers. In that case the record looks correct in AWS but is invisible on the public internet.
• Mixing Google's current smtp.google.com guidance with older aspmx examples without understanding why both exist.

Summary

• The Route 53 error means your MX value is not in priority hostname format.
• For most current Google Workspace setups, use 1 smtp.google.com..
• Older Google aspmx records can still work, but each line still needs exactly two fields.
• Verify the public result with dig MX your-domain +short after DNS changes propagate.
• If the record looks right in Route 53 but mail still fails, check delegation and remove conflicting MX records.