Route 53 DNS Validation for ACM SSL Certificates (2026)

Route 53 DNS validation for ACM certificates is surprisingly the bottleneck for most certificate provisioning, not the certificate issuance itself.

Let’s watch this in action. Imagine we’ve requested a certificate for *.example.com via the AWS Console. ACM, after a brief internal check, presents us with this:

Domain: *.example.com
Validation status: Pending validation
Validation method: DNS

CNAME name: _XYZABC123.example.com.
CNAME value: _DEF456789.XYZABC123.acm-validations.aws.

This is the core of the process. ACM has generated a unique CNAME record that proves you control the domain. Your job is to create this record in your DNS provider. If you’re using Route 53, this is usually a simple copy-paste.

Here’s how you’d create that CNAME in Route 53:

1. Navigate to the Route 53 console.
2. Go to "Hosted zones" and select your domain (example.com).
3. Click "Create record."
4. For "Record name," enter _XYZABC123. (Route 53 automatically appends the domain name).
5. For "Record type," select "CNAME."
6. For "Value," paste _DEF456789.XYZABC123.acm-validations.aws..
7. Leave "TTL" at its default (e.g., 300 seconds).
8. Click "Create records."

Once this record is created, Route 53 will start advertising it. ACM, running its own DNS queries against the public internet, will eventually see this record. When it does, the validation status will change from "Pending validation" to "Issued."

The mental model is this: ACM doesn’t directly talk to your DNS provider. It relies on the public DNS resolution system. It says, "Hey, is there a CNAME record for _XYZABC123.example.com that points to _DEF456789.XYZABC123.acm-validations.aws.?" If the answer comes back "yes," the certificate is issued. This indirection is what makes it robust but also a potential point of failure if not configured correctly. The TTL (Time To Live) on your DNS record determines how long DNS resolvers cache the record. A lower TTL means changes propagate faster, but it can also lead to more DNS lookups.

The key levers you control are:

• Correct CNAME Entry: The most common mistake is a typo in either the "CNAME name" or "CNAME value." A single missing character, an extra dot, or incorrect case will prevent validation.
• DNS Propagation Time: DNS changes aren’t instantaneous. They need to propagate across the global DNS infrastructure. While Route 53 is fast, there’s still a delay, especially if you have other DNS providers involved or if your client machines are hitting old cached records.
• Wildcard Domain Considerations: For wildcard certificates (*.example.com), ACM often requires validation for both the wildcard and the apex domain (example.com) separately if you’re using DNS validation. You’ll get two sets of CNAME records.
• Subdomain Delegation: If example.com is delegated to Route 53, but the specific subdomain you’re trying to validate is managed by a different DNS provider, ACM will query the wrong place. You need the CNAME in the zone that actually answers queries for that subdomain.

The one thing that often trips people up, especially with wildcard certificates, is when they try to create the CNAME record directly on the wildcard itself (e.g., _XYZABC123.*.example.com). ACM generates the CNAME for the specific wildcard name, which usually looks like _XYZABC123.example.com. You then add that specific record to your DNS zone. ACM handles the wildcard resolution implicitly by asking the DNS system to resolve the generated name.

The next hurdle you’ll likely encounter is dealing with certificates that have been pending for hours, leading you to question if ACM is even checking.