How to Add SPF and DMARC Records in Amazon Route 53

Adding SPF and DMARC records in Amazon Route 53 is a short job, but Route 53 has two habits that trip people up. It wants TXT values wrapped in double quotation marks that you type yourself, and it splits any string longer than 255 characters differently from most DNS hosts. This guide is written for whoever owns the hosted zone as infrastructure, not for a marketing admin.

SPF and DMARC are both published as TXT records. SPF lists which servers may send mail for your domain. DMARC tells receiving servers what to do when SPF or DKIM fails, and where to send reports. The values come from whoever sends your mail — Google Workspace, Microsoft 365, Amazon SES — and the job here is getting those values into Route 53 exactly. DKIM is separate, and with Amazon SES it is three CNAME records rather than a TXT key.

The short answer#

Open the Route 53 console, go to Hosted zones, and click the hosted zone for your domain. Choose Create record, keep the default Simple routing, and add each record. For SPF, leave Record name empty so it sits on the root, and set Record type to TXT. For DMARC, set Record name to _dmarc and Record type to TXT. In the Value box, type the string inside double quotes — for example "v=spf1 include:amazonses.com ~all" for SPF and "v=DMARC1; p=none; rua=mailto:[email protected]" for DMARC — then save.

Two Route 53 specifics cause most of the trouble. Route 53 does not add the quotation marks for you the way some hosts do, so you type them once around each string. And the Record name field is relative: type _dmarc, not _dmarc.example.com, because Route 53 appends the zone name and a full name becomes _dmarc.example.com.example.com. Route 53 publishes changes to its own name servers within about a minute, but receivers cache the old answer until the record's TTL expires.

Before you start: gather the values from your mail provider#

Route 53 only holds the records. The values are defined by whoever sends your mail, so collect them first from that provider's admin console. Copy them exactly — one wrong character in a DKIM key, or a stray space in an SPF string, makes verification fail.

• Your SPF value — a single v=spf1 string with an include: mechanism for every service that sends as your domain, ending in a qualifier such as ~all (soft fail) or -all (hard fail). For Amazon SES the include is include:amazonses.com.
• Your DMARC policy — a v=DMARC1 string with a policy tag (start with p=none) and a rua address that will receive aggregate reports.
• Your DKIM records — with Amazon SES Easy DKIM this is three CNAME records that SES generates for you; with some providers it is instead a public key published as a TXT record at a selector name.
• Access to the AWS account whose Route 53 hosted zone serves this domain. The registrar must point the domain at that hosted zone's name servers, or nothing you add here is served.

Add the records in Route 53, step by step#

Work through these in order in the Route 53 console. Save each record before starting the next, and keep your provider's values open in another tab to paste from.

1. 1

   Open the hosted zone

   Sign in to the Route 53 console, choose Hosted zones, and click the hosted zone whose name matches your domain. SPF, DMARC, DKIM, MX and your web records all live here. If there is no hosted zone for the domain yet, create one first and point the registrar at its four name servers, or none of these records will resolve.

2. 2

   Add the SPF record (TXT)

   Choose Create record. Leave Record name empty so the record sits on the root domain. Set Record type to TXT. In Value, type your SPF string inside double quotes, for example "v=spf1 include:amazonses.com ~all". Publish only one SPF record per domain: if several services send as your domain, merge their include: mechanisms into one quoted string with a single qualifier at the end.

3. 3

   Add the DMARC record (TXT)

   Choose Create record. Set Record name to exactly _dmarc. Set Record type to TXT. In Value, type your policy in double quotes, for example "v=DMARC1; p=none; rua=mailto:[email protected]". Starting at p=none collects reports without affecting delivery while you confirm SPF and DKIM pass for your legitimate mail.

4. 4

   Add DKIM (CNAME with Amazon SES)

   For SES Easy DKIM, add the three CNAME records SES shows on the identity's Publish DNS records tab. Use Record type CNAME, a Record name like token._domainkey (exactly as SES shows it, with no extra leading underscore), and a Value like token.dkim.amazonses.com. If SES and Route 53 are in the same AWS account, SES can publish these for you — see the section below.

5. 5

   Set the TTL and verify

   Route 53 suggests a default TTL of 300 seconds for a new record, which is fine. Save each record, then verify with a public DNS lookup: query TXT for your domain (SPF), TXT for _dmarc.yourdomain.com (DMARC), and each DKIM CNAME. Each lookup should return exactly what you entered, with no doubled domain and no stray extra quotes.

Route 53 vs other DNS hosts: what's different#

Most guides are written for a generic DNS panel, and Route 53 diverges on a few points that matter for email records. The table below is the short version; the quoting rule and the relative name are the two that cause the most failed lookups.

Values over 255 characters: how Route 53 splits a long TXT string#

A single TXT string in Route 53 can hold up to 255 characters. A 2048-bit DKIM public key published as a TXT record is longer than that, and so are some long verification strings. Route 53 does not fold the overflow for you — it rejects a single string over 255 characters.

The fix is to break the value into pieces of 255 characters or fewer, wrap each piece in its own double quotes, and put them on the same line separated by spaces: "part one" "part two" "part three". DNS concatenates the quoted strings back into one value, so the receiver reads the whole key. A TXT value can reach 4,000 characters this way. This only applies when you publish a key as a TXT record — Amazon SES Easy DKIM uses CNAME records, so it never meets the 255-character limit at all.

What to do when it doesn't work#

Most Route 53 email-record failures come from a handful of causes, and each has a clean fix. Query the record with a public DNS lookup, compare what returns to what you entered, and the mismatch usually points straight at the cause.

Where AI Emaily fits — and where it doesn't#

These records live in your Route 53 hosted zone, and publishing them is a DNS job. AI Emaily is not a DNS host, a DMARC monitoring service, or a deliverability tester. It will not create these records for you, and for reading the aggregate reports your rua address collects you want a dedicated DMARC platform. If that is the task in front of you, use those. On the DKIM half, Amazon SES can publish the three CNAMEs to a same-account Route 53 zone automatically, which is the closest thing to a one-click path.

The adjacent thing we do is on the receiving side. SPF, DKIM and DMARC are how a receiving server decides whether a message truly came from the domain it claims, and AI Emaily reads those same authentication results on the mail arriving in your inbox — so its spam and phishing checks can flag a spoofed sender that failed alignment. Connecting a Gmail, Outlook or IMAP mailbox needs no new DNS records, since your outbound still flows through your provider's authenticated servers. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.