How do you add email DNS records in Amazon Route 53?

Amazon Route 53 is AWS's DNS service. It handles email records well, but it works differently from registrar DNS editors such as GoDaddy or Namecheap: you leave the name blank for the root domain, TXT values need double quotes, and every value for one name lives in a single record set.

This guide covers adding MX, SPF, DKIM and DMARC records in Route 53, in the console and with the AWS CLI, using AWS's own documentation for every step. Menu names are correct at the time of writing (October 2026). If you need a refresher on what each record does, read SPF vs DKIM vs DMARC first.

Does Route 53 actually answer for your domain?

Route 53 serves a domain's records only when the domain's registrar points to the four name servers of a public hosted zone. A public hosted zone is the container for a domain's internet-facing records. AWS also has private hosted zones, which answer only inside an Amazon VPC, so email records added there are invisible to the outside world (AWS).

Route 53 creates an NS record in every hosted zone that "lists the four name servers that are the authoritative name servers for your hosted zone" (AWS). They look like ns-2048.awsdns-64.com, with one each ending in .com, .net, .org and .co.uk. To check:

1. In the Route 53 console, open Hosted zones and choose your domain.
2. Open Hosted zone details and note the four Name servers.
3. Compare them with the live name servers for your domain, shown by our MX Lookup or your registrar.

If they don't match, the zone you're editing isn't live. Make the changes at whichever DNS host the domain really uses. If that's Cloudflare, see our Cloudflare guide. If you registered the domain with Route 53, AWS sets Route 53 as its DNS service automatically.

Where do you add DNS records in Route 53?

Every record type uses the same steps (AWS):

1. Sign in to the AWS Management Console and open Route 53.
2. In the navigation pane, choose Hosted zones, then choose your domain's name.
3. Choose Create record.
4. Choose Simple routing if the console asks for a routing policy. Email records don't need weighted, latency or failover routing.
5. Fill in the fields below, then choose Create records.

To change a record later, select its row, make your changes in the Edit record pane and choose Save changes.

The most common Route 53 mistake comes from habits formed elsewhere. In Route 53 you leave the name blank for the root, not @, and you never type the full domain in the console. The API is different: there, Name takes the fully qualified name, such as _dmarc.example.com.

How do you add an SPF record in Route 53?

SPF is a TXT record on the bare domain. Route 53 adds two rules you won't see at most registrars.

Use the TXT type, not SPF. Route 53 still offers an SPF record type, but AWS says "we no longer recommend that you create records for which the record type is SPF" and recommends "a TXT record that contains the applicable value" instead (AWS).

Keep every root TXT value in one record set. AWS says to "include all values for a domain (example.com) or subdomain (www.example.com) in the same TXT record" and to enter "one value per row." If your zone already has a root TXT record, for example a Microsoft or Google verification string, edit it and add SPF as another line. Don't try to create a second TXT record at the same name.

1. In your hosted zone, look for a TXT record whose name is your bare domain.
2. If it exists, select it, and in Edit record add your SPF value on a new line, in double quotes. If an SPF line is already there, edit that line instead.
3. If none exists, choose Create record, leave Record name blank, choose TXT, and enter the value in quotes.
4. Save.

Example of a root TXT record set with two values (example values):

"MS=ms12345678"
"v=spf1 include:spf.protection.outlook.com -all"

Only one of those lines may start with v=spf1. RFC 7208, section 3.2 says a domain "MUST NOT have multiple records" that an SPF check would select; see multiple SPF records if you've inherited two. Get each include from our SPF provider pages, or build a merged record with the SPF Record Generator.

How do you add a DKIM record in Route 53?

Your email provider generates the DKIM key. You publish it either as a TXT record or as CNAME records that point to a key the provider hosts.

DKIM as a CNAME record

Microsoft 365 and most sending platforms use CNAMEs.

1. Choose Create record.
2. Enter the selector prefix as Record name, for example selector1._domainkey.
3. Choose CNAME and paste the provider's target as Value. AWS says the trailing dot is optional because Route 53 treats the name as fully qualified.
4. Choose Create records, then repeat for any second selector.

If you send through Amazon SES and the hosted zone is in the same AWS account, you may not need to do this by hand. SES's Easy DKIM uses three CNAME records (AWS) and, if you use Route 53 as your DNS provider, "Amazon SES can automatically create the appropriate records for you" (AWS). Our Amazon SES DKIM page lists the record format.

DKIM as a TXT record (and 255-character strings)

Google Workspace and many mail servers give you a TXT key. Here Route 53 is strict: "A single string can include up to 255 characters." A 2048-bit DKIM key is longer than that, so AWS says to "break the value into strings of 255 characters or fewer, and enclose each string in double quotation marks," listing them on the same line (AWS). The whole value can be up to 4,000 characters.

Example record for the name google._domainkey (key shortened):

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt3x...first 255 characters" "...remaining characters...IDAQAB"

Receivers join the pieces back together. RFC 6376, section 3.6.2.2 says they're concatenated "with no intervening whitespace," so the space between the quoted strings doesn't become part of the key. Pasting the key as one long string gets a "CharacterStringTooLong" error (AWS). Our 2048-bit DKIM key guide shows how to split one safely.

After publishing, turn on signing in your provider's console. Our DKIM setup guide for Microsoft 365 and Google Workspace shows where.

How do you add a DMARC record in Route 53?

DMARC is a TXT record at the _dmarc prefix.

1. Choose Create record.
2. Enter _dmarc as Record name.
3. Choose TXT and enter your policy in double quotes, for example "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com".
4. Choose Create records.

If a _dmarc TXT record already exists, edit it instead. Start at p=none with a reporting address you actually read, then tighten the policy once reports show every real sender passing. The DMARC Record Generator builds the record, and DMARC record examples explains each tag.

How do you add or change MX records in Route 53?

An MX record tells other servers where to deliver your domain's mail. In Route 53, every MX host for a name goes into one record set, one per line, each written as priority then hostname (AWS). "The server with the lowest value for the priority takes precedence."

1. Note the current MX values so you can roll back.
2. Select the existing MX record for the bare domain, or choose Create record with Record name blank and type MX.
3. Enter each mail server on its own line, for example 1 smtp.google.com for Google Workspace or 10 mx1.example-filter.net and 20 mx2.example-filter.net for a two-host service (example values).
4. Save.

The target must be a hostname with an A or AAAA record, not a CNAME. AWS points to RFC 2181, which "forbids specifying the name of a CNAME record" as an MX target. And because Route 53 won't let you create a CNAME on the bare domain, you can't accidentally override your MX that way, which is a real risk at some other hosts.

Changing MX moves all incoming mail at once. Lower the TTL a day ahead and read how to change MX records without losing email first.

How do you add email records with the AWS CLI?

The CLI equivalent of the console steps is aws route53 change-resource-record-sets with a JSON change batch (AWS CLI reference). Use the UPSERT action: "If a resource set doesn't exist, Route 53 creates it. If a resource set exists Route 53 updates it with the values in the request." Note that UPSERT replaces the whole record set, so include every existing value for that name.

Example dmarc.json (example values):

{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "_dmarc.example.com",
      "Type": "TXT",
      "TTL": 300,
      "ResourceRecords": [{ "Value": "\"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com\"" }]
    }
  }]
}

Then run aws route53 change-resource-record-sets --hosted-zone-id <your zone ID> --change-batch file://dmarc.json. The TXT quotes are part of the value, so they're escaped inside the JSON string.

How long do Route 53 changes take, and how do you check them?

AWS says "Changes generally propagate to all Route 53 name servers within 60 seconds" (AWS). The GetChange API shows PENDING until then and INSYNC once every Route 53 server has the change. Resolvers elsewhere keep a cached answer until its TTL runs out, which is why AWS suggests a short TTL such as 300 seconds while you change records in use (AWS). Our DNS TTL guide explains the timing.

Then send a test message to an outside mailbox and confirm spf=pass, dkim=pass and dmarc=pass in its headers, using our header reading guide.

What are the common Route 53 email record mistakes?

• Typing @ or the full domain in Record name in the console. Leave it blank for the root and type only the prefix for anything else.
• Missing quotes on TXT values, or a 2048-bit DKIM key pasted as one unsplit string.
• Trying to add a second root TXT record for SPF instead of adding a line to the existing set.
• Using the SPF record type instead of TXT.
• Editing a private hosted zone, or a public zone the registrar doesn't point to.
• An UPSERT that drops values, because it replaced the record set with only the new line.

Next steps

1. Run the Email Health Check to see your MX, SPF, DKIM and DMARC in one scan.
2. Build your records with the SPF Record Generator and the DMARC Record Generator, then paste them into Route 53 with quotes.
3. Confirm DKIM with the DKIM Checker after you turn signing on.
4. If you want a weekly alert when your MX, SPF or DMARC records change, Free Domain Watch checks public DNS at no cost.

If you later point MX at a filtering service such as iBlockSpam, you edit the same MX record set with its values. More walk-throughs are in setup guides.