How to Set Up DMARC in AWS Route 53: Step-by-Step DNS Configuration

AWS Route 53 is Amazon's scalable DNS service, and if you run infrastructure on AWS, there is a good chance your domain's DNS lives there too. Adding a DMARC record in Route 53 is a straightforward TXT record creation, but there are a few Route 53 quirks around record naming and value quoting that trip people up. This guide covers the full process from start to finish.

If you are using Amazon SES as your email sending service, you will also need to configure SPF and DKIM on the SES side. This guide focuses on the DNS record in Route 53. For the SES-specific authentication setup, see our DMARC for Amazon SES guide.

Prerequisites

Before you add a DMARC record in Route 53, make sure the following are in place.

You need an AWS account with Route 53 access. Specifically, you need IAM permissions for route53:ChangeResourceRecordSets and route53:ListHostedZones, or broader Route 53 access. If you are using an IAM role with restricted permissions, verify you can create DNS records before proceeding.

Your domain must have a hosted zone in Route 53. A hosted zone is the container for all DNS records belonging to a domain. If your domain is registered through Route 53, a public hosted zone was created automatically. If your domain is registered elsewhere but you use Route 53 for DNS, confirm your registrar's nameservers point to the Route 53 name servers listed in your hosted zone's NS record.

SPF and DKIM should already be configured. DMARC depends on both protocols. SPF defines which servers are authorized to send email for your domain. DKIM adds a cryptographic signature to outgoing messages. Without them, DMARC has nothing to evaluate. Use spfcreator.com to generate your SPF record and dkimcreator.com for DKIM.

You need your DMARC record value ready. A basic monitoring-only record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

Start with p=none to collect aggregate reports without impacting email delivery. Move to enforcement only after you have reviewed your data. For guidance on policy levels, see our DMARC policy levels guide.

Step-by-Step: Adding a DMARC Record in Route 53

Route 53-Specific Details

TXT Record Quoting

This is the most common source of errors in Route 53. Unlike Cloudflare or GoDaddy, Route 53 expects TXT record values to be explicitly wrapped in double quotes in the value field. The correct format is:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"

If you paste the value without quotes, Route 53 may return a validation error. When editing records via the AWS CLI or Terraform, the quoting rules get even more specific — you need to escape the quotes within your JSON payload.

Record Name Behavior

Route 53 shows the full domain name in its record list. When you type _dmarc in the name field, the console displays _dmarc.yourdomain.com. (with a trailing dot). The trailing dot is standard DNS notation and is expected. Do not add a second trailing dot manually.

Routing Policies

For a DMARC record, always use Simple routing. Do not use weighted, latency, failover, or geolocation routing. DMARC records must return a single, consistent value regardless of where the DNS query originates. Using any other routing policy can cause intermittent authentication failures.

Managing Records with Infrastructure as Code

If you manage Route 53 with Terraform, CloudFormation, or the AWS CDK, define your DMARC record in code rather than clicking through the console. This keeps your DNS configuration version-controlled and reproducible. In Terraform, the resource looks like this:

resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "_dmarc.yourdomain.com"
  type    = "TXT"
  ttl     = 300
  records = ["v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"]
}

Note that Terraform handles the outer quoting for you — you do not need to add extra double quotes inside the records list.

Verifying Your DMARC Record

After creating the record, allow a few minutes for propagation. Route 53 changes typically take effect within 60 seconds for existing hosted zones, but external DNS caches may take longer depending on previous TTL values.

Check your record using dmarcrecordchecker.com. Verify that:

• The record starts with v=DMARC1
• Your chosen policy (p=none, p=quarantine, or p=reject) is present
• Your rua reporting address is correct if you included one
• There is only one DMARC record for the domain

You can also verify from the command line using dig:

dig TXT _dmarc.yourdomain.com +short

This should return your DMARC string wrapped in quotes.

Common Mistakes

Wrong Hosted Zone

If you have multiple hosted zones for the same domain (for example, a public zone and a private zone for VPC resolution), make sure you add the DMARC record to the public hosted zone. Private hosted zones are only resolvable within your VPC and will not be visible to external mail servers performing DMARC lookups.

Forgetting the Quotes

As mentioned above, Route 53 requires double quotes around TXT record values. If your record is not resolving or returns an empty value, check whether the quotes were stripped or duplicated.

Duplicate DMARC Records

If you previously had DNS managed by another provider and migrated to Route 53, ensure the old DMARC record was removed at the previous provider. Having two authoritative sources for the same record causes unpredictable behavior. Also check that you do not have two TXT records at _dmarc within the same hosted zone.

Propagation Delays

While Route 53 itself propagates changes quickly, external resolvers may cache the absence of a record (negative caching). If you recently queried the domain and got an NXDOMAIN response, that negative result may be cached for up to the SOA minimum TTL. Wait a few minutes and try again, or test from a different network. For more detail on DNS propagation timing, see our DMARC propagation time guide.

After Setup: What to Expect

Once your DMARC record is live, receiving mail servers will begin evaluating it immediately. If you included a rua tag, aggregate reports will arrive within 24 to 48 hours. These XML reports show which IP addresses sent email using your domain and whether those messages passed SPF and DKIM checks.

Review these reports carefully during the first few weeks. They will reveal whether any legitimate services — SES, third-party marketing tools, transactional email providers — are failing authentication. Fix alignment issues before moving from p=none to enforcement. A gradual rollout using p=quarantine; pct=10; lets you enforce on a small percentage of traffic first, reducing the risk of blocking legitimate email.

Monitor Your DMARC Record

You have created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.