How to Update DNS Records in Amazon Route 53

Amazon Route 53 is the DNS service within AWS (Amazon Web Services), widely used by organizations that host infrastructure on AWS. Route 53 manages DNS through the concept of "hosted zones," and its record management interface differs from typical registrar DNS panels. This guide walks you through adding and editing SPF, DMARC, MTA-STS, and DKIM DNS records in Route 53. Each section includes the exact steps, correct field values, and Route 53-specific details you need to get your email authentication records configured correctly.

Route 53 uses a slightly different naming convention for record fields compared to traditional registrars. Understanding these differences is essential for getting your records right the first time.

Accessing Your DNS Zone

1. Sign in to the AWS Management Console at console.aws.amazon.com.
2. Navigate to Route 53 using the search bar or the Services menu under Networking & Content Delivery.
3. Click Hosted zones in the left sidebar.
4. Select the hosted zone for your domain from the list. The hosted zone name matches your domain (e.g., yourdomain.com).
5. You are now in the Records view for your hosted zone. This is where you create, edit, and delete DNS records.

Route 53 displays records grouped by name and type. To create a new record, click Create record. You can use either the Quick create wizard or the Wizard mode — Quick create is faster for experienced users.

Note: Route 53 hosted zones are not the same as Route 53 registered domains. If you registered your domain through Route 53, a hosted zone was created automatically. If your domain is registered elsewhere, you need to create a hosted zone in Route 53 and update your domain's nameservers at the registrar to point to Route 53's NS records.

TXT Records

SPF Record

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send email for your domain. Your SPF record is published as a TXT record at the root of your domain.

1. In your hosted zone, click Create record.
2. In the Record name field, leave it blank. Route 53 uses the hosted zone name as the root automatically. An empty record name means the record is at yourdomain.com.
3. Select TXT from the Record type dropdown.
4. In the Value field, enter your SPF record wrapped in double quotes: "v=spf1 include:_spf.mxio.io ~all"
5. Set the TTL to 3600 (1 hour).
6. Leave the Routing policy set to Simple routing.
7. Click Create records.

Route 53 requires TXT record values to be enclosed in double quotes. This is a common source of errors — if you omit the quotes, the record will fail validation.

If you already have an SPF record, do not create a second one. Multiple SPF records cause a PermError and break email authentication entirely. Instead, click on the existing TXT record that contains v=spf1, click Edit record, and add include:_spf.mxio.io before the ~all or -all mechanism.

Route 53-specific note: When a TXT record value exceeds 255 characters, Route 53 requires you to split it into multiple quoted strings on separate lines. For example:

"v=spf1 include:_spf.google.com include:_spf.mxio.io "
"include:mail.zendesk.com ~all"

Each string must be separately quoted, and Route 53 will concatenate them automatically during DNS resolution.

DMARC Record

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers how to handle email that fails SPF and DKIM checks. It also enables aggregate reporting so you can see who is sending email as your domain.

1. Click Create record.
2. In the Record name field, enter _dmarc. Route 53 will append your domain, resulting in _dmarc.yourdomain.com.
3. Select TXT from the Record type dropdown.
4. In the Value field, enter your DMARC policy in double quotes: "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
5. Set the TTL to 3600.
6. Click Create records.

Replace dmarc@yourdomain.com with the address where you want to receive DMARC aggregate reports. Start with p=none to collect data before enforcing. See the DMARC Deployment Guide for the full progression from none to quarantine to reject.

Note: mxio will support DMARC policy management in a future release.

CNAME Records

MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending servers that your domain supports TLS encryption for inbound email and that they should refuse to deliver over an unencrypted connection. The MTA-STS policy is published via HTTPS, and a CNAME record points to the policy host.

1. Click Create record.
2. In the Record name field, enter _mta-sts. Route 53 will append your domain automatically.
3. Select CNAME from the Record type dropdown.
4. In the Value field, enter the CNAME target provided by your MTA-STS hosting service (e.g., mta-sts.your-hosting-provider.com). In the console, Route 53 treats the value as a fully qualified domain name (FQDN) automatically. You can include a trailing dot (mta-sts.your-hosting-provider.com.) or omit it — the console handles both.
5. Set the TTL to 3600.
6. Click Create records.

Trailing dot convention: Route 53 follows RFC 1035 FQDN notation. In the console, the trailing dot is optional. In CloudFormation, Terraform, or the Route 53 API, always include the trailing dot on CNAME targets and NS values (e.g., ns1.example.com.) to prevent the zone name from being appended. This is the most common source of delegation and CNAME errors in infrastructure-as-code deployments.

You also need a TXT record at _smtp._tls to publish the MTA-STS policy version identifier. Follow the same TXT record process described above, using _smtp._tls as the Record name and the policy string (in double quotes) as the Value.

Note: mxio will support MTA-STS hosting in a future release.

NS Delegation

DKIM Key Hosting

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email was sent by an authorized server and that the message body was not altered in transit. DKIM keys are published as DNS records under the _domainkey subdomain.

For centralized DKIM key management, you can delegate the _domainkey subdomain to a dedicated DNS host via NS records.

1. Click Create record.
2. In the Record name field, enter _domainkey. Route 53 will append your domain, resulting in _domainkey.yourdomain.com.
3. Select NS from the Record type dropdown.
4. In the Value field, enter each nameserver on a separate line. In the console, the trailing dot is optional. In CloudFormation or the API, include the trailing dot:

   ns1.example-dkim-host.com.
   ns2.example-dkim-host.com.

5. Set the TTL to 3600.
6. Click Create records.

Route 53 accepts multiple NS values in a single record set. Enter each nameserver on its own line in the Value field. If using infrastructure-as-code, always use the trailing-dot FQDN format to avoid accidental zone name appending.

Note: mxio will support DKIM key hosting via NS delegation in a future release.

Verifying Your Changes

After adding or editing DNS records in Route 53, verify that your changes are live and correct.

1. Use the mxio SPF Checker to validate your SPF record. Enter your domain and confirm that the record resolves correctly, the lookup count is within the 10-lookup limit, and all your sending services are included.
2. Use the mxio DMARC Checker to verify your DMARC record is published and syntactically correct.
3. Use the mxio Domain Health tool for a full overview of your domain's email authentication status, including SPF, DKIM, DMARC, and MX configuration.
4. If you created NS delegation records for DKIM, use the Delegation Health tool to verify that the NS records are resolving correctly and the delegated zone is responding.

Route 53 DNS changes typically propagate within 60 seconds. Route 53 uses a global Anycast network, so propagation is fast. However, if upstream resolvers have cached the old record, it may take up to the old TTL value for the change to be visible everywhere.

Route 53 also provides a Test record feature in the console. Click on a record and use Test record to simulate a DNS query directly against Route 53's authoritative servers, bypassing resolver caches.

Troubleshooting

Missing double quotes on TXT records

Route 53 requires TXT record values to be enclosed in double quotes. If you enter v=spf1 include:_spf.mxio.io ~all without quotes, Route 53 will either reject the record or interpret it incorrectly. Always wrap the entire value in double quotes: "v=spf1 include:_spf.mxio.io ~all".

Duplicate SPF records

Your domain must have exactly one SPF TXT record at the root. Route 53 allows multiple values within a single TXT record set, which can cause confusion. Make sure there is only one value starting with v=spf1 in your root TXT record set. Use the SPF Checker to confirm you have only one SPF record.

Hosted zone not resolving

If records you create in Route 53 are not resolving at all, verify that your domain's nameservers point to the Route 53 NS records listed in your hosted zone. Go to your domain registrar and confirm the nameservers match the four NS records shown at the top of your Route 53 hosted zone.

ALIAS vs. CNAME at the root

Route 53 supports ALIAS records (called "A record with alias" in the console) at the zone apex, but this feature is for A/AAAA records pointing to AWS resources, not for email authentication. SPF and DMARC are TXT records and do not need ALIAS records.

CloudFormation and Terraform conflicts

If your Route 53 hosted zone is managed by CloudFormation or Terraform, manual changes in the console may be overwritten on the next deployment. Coordinate with your infrastructure team to ensure DNS record changes are reflected in your infrastructure-as-code templates.