Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DMARC › AWS Route 53

Set up DMARC on AWS Route 53

Route 53 expects you to type the double quotes around a TXT (Text) value yourself. Most consoles add them; this one does not, and leaving them off is the most common Route 53 mistake on this record.

"v=DMARC1; p=none; rua=mailto:you@yourdomain.com"

Three tags carry the meaning. v=DMARC1 names the version and must come first. p=none is the policy, instructing receivers to change nothing. rua=mailto: is where aggregate reports are sent.

This record carries p=none, which changes nothing about how any mail is treated. It asks receivers to send reports. Only quarantine or reject changes an outcome, and getting there safely is what the reports are for.

Check that Route 53 answers DNS for the domain

Open Hosted zones in the Route 53 console, select the domain, and note the four NS values shown there. Those four values must match the nameservers set at the registrar. If the domain was registered through Route 53 they usually already match; if it is registered elsewhere, or there is more than one hosted zone for the domain, check carefully. If the live nameservers point elsewhere, add the DMARC (Domain-based Message Authentication, Reporting and Conformance) record at whichever provider runs DNS (Domain Name System) instead.

Route 53 is the DNS host for the domain. It stores the hosted zone and answers queries for the records held there, but the mail itself is sent from somewhere else. It publishes the TXT record exactly as entered once Create records is clicked, and it does not generate the DMARC value or advise on the policy: you supply the full string and the reporting address.

Add the record in the Route 53 console

  1. Sign in to the AWS console and open Route 53.
  2. In the left menu, choose Hosted zones, then click the name of the domain.
  3. Click Create record.
  4. If a wizard with routing options appears, switch to the simple form by looking for Quick create record.
  5. In the Record name field, enter exactly _dmarc and do not type the domain name after it.
  6. Set the Record type field to TXT.
  7. In the Value field, enter the record text wrapped in double quotes that you type yourself.
  8. Leave the TTL (Time to Live) field at its default setting.
  9. Click Create records to save the entry.

The Record name field takes _dmarc only, since Route 53 appends the domain itself and shows it beside the field. The Value field takes the full string wrapped in double quotes that you type yourself, since Route 53 does not add them.

Traps in the Route 53 form

Sending reports somewhere other than your own inbox

More on the fourth trap above.

If rua= names an address on your own domain, nothing else is needed. If it names an address on a domain you do not control, which is the case for every hosted DMARC reporting service, that domain has to publish a record authorising reports about you. The form is a TXT record at yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1. Reporting services publish a wildcard version of this and document it, so in practice you do nothing, but if reports never arrive at a third-party address this is the first thing to check.

You can list several addresses separated by commas, which is how people keep a copy while a service does the parsing. There is also ruf=, for forensic reports on individual failing messages: few receivers send them and those that do redact most of the content, so it is rarely worth adding.

A note for AWS users specifically. If the domain sends through Amazon SES, DMARC alignment depends on SES using a custom MAIL FROM domain or on SES signing with a DKIM (DomainKeys Identified Mail) key published on your domain. A default SES configuration passes SPF (Sender Policy Framework) on Amazon’s own envelope domain, which does not align with your From address, so the reports will show SES failing DMARC until one of those two is configured. The DKIM route is the more robust of the two.

Alignment, which decides more than the checks themselves

A report row can show SPF passing and DMARC failing at the same time.

DMARC asks whether SPF or DKIM passed and whether the domain it passed for matches the domain in the visible From address. That second half is alignment. A platform sending on your behalf commonly passes SPF on its own envelope domain while your domain sits in the From line, so the two do not match and DMARC fails despite the pass.

This is exactly the Amazon SES case described above, and it is the general case too. The durable fix is a DKIM signature made with a key published on your domain, which aligns by construction and survives forwarding as an SPF pass does not.

When you do move the policy up, use pct= to apply it in stages. "v=DMARC1; p=quarantine; pct=20; rua=mailto:you@yourdomain.com" applies the policy to a fifth of failing mail, so a sender you overlooked costs you a fifth of the consequence while the reports keep telling you what happened. Raise the figure as the picture stays clean, then drop the tag and move to p=reject.

Note the quotes in that example. Route 53 wants them on every TXT value, including the ones you edit later.

Wait, then read the result

A change in Route 53 takes a few minutes up to a couple of hours to take effect. The saved record appears under the domain’s entry in Hosted zones alongside the other records in the zone.

How the scan grades this record: the DMARC policy check, with its pass and fail rules and how many domains pass it.

For context: 249,025,625 domains (74.9%) in the October 2026 census publish no DMARC record at all, and among those at p=none, 35,049,364, or 80.17%, have no rua= address either.

When the reports show every legitimate sender aligning, move to p=quarantine and then p=reject. Receivers act on the record only at p=quarantine or p=reject.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.