How to Configure MX Records in AWS Route53 for GoDaddy Domains: A Step-by-Step Guide with DNS Examples


2 views

When managing DNS through AWS Route53 while using GoDaddy's email services, the MX record setup requires specific attention. Many developers face confusion because:

  • Route53's interface differs from traditional DNS providers
  • GoDaddy's email servers require precise weighting in MX records
  • The NS delegation must be properly configured at GoDaddy

Verify these essential elements first:

// Check current nameservers using dig (Linux/Mac)
dig NS yourdomain.com +short

// Expected output should match your Route53 nameservers:
ns-AAA.awsdns-47.com
ns-BBB.awsdns-55.net
ns-CCCC.awsdns-24.org
ns-DDDD.awsdns-11.co.uk

In your Route53 Hosted Zone:

  1. Navigate to the record creation page
  2. Leave the Name field empty for apex record
  3. Select MX as record type
  4. Set TTL (300 seconds recommended)
  5. Enter values with priority:
10 pop.secureserver.net
20 smtpout.secureserver.net

For enterprise setups requiring redundancy:

// Multiple MX records with different priorities
0  mailserver1.yourdomain.com
5  mailserver2.yourdomain.com
10 backup.provider.com

After DNS propagation (typically 5-60 minutes):

// Check MX records using command line
dig MX yourdomain.com +short

// Expected output:
10 pop.secureserver.net.
20 smtpout.secureserver.net.

For SMTP testing:

telnet smtpout.secureserver.net 25
EHLO yourdomain.com

If email delivery fails:

  • Verify NS records at GoDaddy point to Route53
  • Check for trailing dots in MX values
  • Confirm TTL hasn't cached old records
  • Test with MXToolbox

When migrating DNS management from GoDaddy to AWS Route53 while maintaining GoDaddy email services, MX record configuration becomes critical. Many developers stumble at this junction because:

  • Route53's interface handles MX records differently than traditional DNS panels
  • GoDaddy's email servers require specific priority values
  • The NS delegation must be properly configured

Before making changes, confirm your domain's nameservers point to AWS:

dig NS yourdomain.com +short
ns-xxx.awsdns-xx.com
ns-yyy.awsdns-xx.net

If you don't see Route53 nameservers, you'll need to update them at GoDaddy first.

In your Route53 hosted zone, create a new record with these exact values:

Record name: @ (for apex domain) or leave blank
Record type: MX
Value: 
10 mailstore1.secureserver.net
20 smtp.secureserver.net
TTL: 3600 (or your preferred value)

For subdomains, specify the subdomain name instead of '@'. The priority values (10, 20) are crucial - they determine mail server failover order.

After DNS propagation (typically 1-60 minutes), verify with:

dig MX yourdomain.com +short
10 mailstore1.secureserver.net.
20 smtp.secureserver.net.

If emails aren't flowing:

# Check SPF record (should include secureserver.net)
dig TXT yourdomain.com +short
"v=spf1 include:secureserver.net ~all"

# Verify DKIM (if using GoDaddy's premium email)
dig default._domainkey.yourdomain.com +short

For those managing multiple domains, here's a CLI command to create MX records:

aws route53 change-resource-record-sets \
--hosted-zone-id /hostedzone/YOURZONEID \
--change-batch '{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "yourdomain.com",
      "Type": "MX",
      "TTL": 3600,
      "ResourceRecords": [
        {"Value": "10 mailstore1.secureserver.net"},
        {"Value": "20 smtp.secureserver.net"}
      ]
    }
  }]
}'
  • Never delete old MX records before new ones propagate
  • GoDaddy's free email requires their MX records
  • For Office 365 or G Suite, use different MX values
  • Consider setting up DMARC for deliverability