Route 53 DMARC: how to add a DMARC record
One TXT record at _dmarc, created in the hosted zone that is actually delegated, or handed to the AI assistant you already use. Route 53 wants the value in double quotes, and a hosted zone nothing is delegated to will accept the record and never serve it.
How to add a DMARC record in Route 53
The record is one TXT entry at _dmarc. Confirm the authoritative DNS zone first, then publish one approved policy record.
01
Open the hosted zone that is actually delegated
A domain can have more than one hosted zone in an account, and only the one whose nameservers match the domain's delegation is served. Records created in the other zone resolve for nobody.
02
Create the record
Choose Create record, set the record name to _dmarc, choose TXT as the type, and leave the routing policy simple unless you have a reason not to.
03
Wrap the value in double quotes
Route 53 stores TXT values as quoted strings. A single string holds up to 255 characters, and a longer value is split into several quoted strings listed on the same line.
04
Create records, then check what resolves
AWS documents that changes generally reach every Route 53 nameserver within 60 seconds, which makes a verification pass straight afterwards worth running.
The record, field by field
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comA monitoring record: nothing is blocked, and receivers start reporting who sends as your domain. Replace the reporting address with a mailbox you control, and do not publish this value unchanged.
| Record type | TXT |
|---|---|
| Record name | _dmarc, prepended to the hosted zone name. |
| Value | The policy string wrapped in double quotes. Route 53 stores TXT values as quoted strings and each one is capped at 255 characters. |
| TTL | 300 seconds is a reasonable default. |
Route 53 console, Hosted zones, the zone, Create record is the path as Route 53 labels it today. Provider dashboards get renamed, so the current official reference is AWS: creating records with the Route 53 console.
The same setup, without the dashboard
Connect Palisade's MCP server to Claude, ChatGPT, Copilot, or any MCP client, and the record values stop being something you transcribe.
01
Add the domain
Your assistant calls create_domain and the domain starts being monitored. Adding a domain is free and never gated, so a whole portfolio can go in before anything is set up.
02
Get the exact records
get_dns_records returns each record to publish with its host, type, value, recommended TTL and whether it needs creating, replacing or deleting. It also reports the DNS host resolved from the domain's live nameservers, so your assistant is told this zone is on Amazon Route 53 rather than guessing from the registrar.
03
Publish them where the zone lives
The Palisade MCP server has no tool that writes a record at Route 53. It hands your assistant the values, and your assistant publishes them with the DNS tooling it already has. In the Palisade app, Smart DNS Deployment is the other route: you authorise the connection in the provider's own window and approve each record, and Palisade writes it into your own zone.
04
Verify against live DNS
verify_domain re-checks from outside your account, so a record saved into the wrong zone or still inside its TTL shows as unverified rather than done. Setup is finished when every required record verifies.
Connecting takes one step and no API key to create first. The setup for each client is on the Palisade MCP server page.
What Palisade knows about your Route 53 zone
The question worth asking before you connect anything, answered first.
| Route 53 credentials | Never requested, never stored, never seen. Palisade has no field for a Route 53 API token or password. |
|---|---|
| How the provider is identified | From the domain's live NS records. Amazon Route 53 is recognised by nameservers matching the awsdns pattern, and that lookup is public information about your domain rather than access to your account. Route 53 hands a domain four nameservers across different top-level domains. All four belong to the same delegation set, and detection expects all of them to be present. |
| What the MCP server can change | Nothing in your zone. No tool in the server writes a record at an external provider; it returns the values and your own tooling publishes them. |
| If you want Palisade to publish instead | Smart DNS Deployment, in the Palisade app, covers 64 providers. You authorise the connection in the provider's own window, the access covers email-authentication records only, you approve each record, and you can disconnect at any time. |
| Your registrar and nameservers | Unchanged. Nothing is transferred and Palisade never takes over the zone. |
What publishing to Route 53 looks like
You approve the exact record. The connection is authorised in the provider's own window, and nothing else in the zone is touched.
- Setting up acme-corp.com: its email-authentication records are unconfigured, and instead of setting them up by hand you choose Configure.
- Palisade recognises Route 53 as the provider answering for the domain, and you authorise the connection in Route 53’s own window. No password is shared with Palisade, and access is scoped to email-authentication records only.
- The exact records are shown as a before-and-after diff: the SPF value gaining a sender, plus new DKIM and DMARC records. Nothing is published until you press Approve and publish.
- Every record is live and verified in your own zone, monitoring stays on, and nothing else in the zone was touched.
Publishing DMARC is the start, not the finish
A published record proves the policy exists. Whether your mail actually authenticates is a question the record UI never answers.
Drift, including the record you just published
A record that is edited, overwritten by another tool, or dropped during a Route 53 change stops matching what Palisade generated. Monitoring keeps checking live DNS after the write, so a change that silently did not take becomes a task instead of something you learn from a bounce weeks later.
Senders that are failing authentication
Aggregate reports name the services sending as your domain and show which of them pass SPF and DKIM with alignment. A new marketing platform someone signed up for without telling you shows up here first.
Remediation as tasks, with the fix already drafted
Palisade opens a task for each failing source and record issue, ordered by priority, and a task can carry provider-specific instructions for the sender involved. The agent investigates every sender, drafts every fix, and proposes each policy step. You approve before anything ships.
Readiness to tighten the policy
Moving from p=none toward quarantine and then reject is safe only once the legitimate senders are accounted for. Palisade tracks when that is true for the domain and proposes the step rather than taking it.
Amazon Route 53 DMARC: FAQ
Does Palisade need an AWS access key or an IAM role?
No. Palisade never asks for, stores, or sees an AWS credential. Through MCP, your assistant publishes with the AWS tooling it already has and the keys stay on your side. In the Palisade app, Smart DNS Deployment has you authorise the connection in the provider's own window instead, scoped to email-authentication records and revocable at any time.
Why does my Route 53 TXT record need quotation marks?
AWS stores a TXT record as one or more strings enclosed in double quotation marks, and a single string can hold up to 255 characters. A DMARC policy fits comfortably inside one string, but a long SPF or DKIM value does not, and the fix is to split it into several quoted strings on the same line rather than trimming it. Palisade returns the record value itself, so quoting it the way the console expects is the one piece of formatting that belongs to Route 53.
Should I use the SPF record type in Route 53?
No. AWS says so directly: the SPF record type is no longer appropriate, and RFC 7208 retired it after the interoperability problems it caused. Publish SPF as a TXT record instead. Route 53 still lists SPF as a supported type, which is what makes this worth stating rather than assuming.
I created the record but nothing resolves. What is usually wrong?
Most often the record went into a hosted zone the domain is not delegated to. AWS reports its own changes as propagated within about 60 seconds, so a record still missing after a few minutes is rarely a timing problem. Comparing the zone's nameservers against the domain's live delegation settles it, and verify_domain checks the same thing from outside your account.
What happens if my nameservers are split while I move to Route 53?
Palisade reports no provider rather than the wrong one. Detection reads the domain's live NS records and only names a host when every nameserver belongs to it, so a zone half-delegated to Route 53 and half somewhere else comes back with the provider unresolved. Your assistant is told to check the nameserver list and ask you, instead of picking a DNS tool that would write into the zone that is on its way out.
Publishing the record on Route 53 is the easy half
1 domain free up to 1,000 emails/month