Skip to content

ACM certificate DNS validation

How AWS Certificate Manager proves you control a domain before issuing a TLS cert: ACM publishes a `_<hash>.domain` CNAME challenge, you copy it to DNS, and renewal stays automatic forever after.

Updated May 25, 2026

When you request an ACM certificate for example.com, AWS has no idea who you are. Before issuing a public TLS cert it has to prove that whoever’s asking actually controls that name. ACM offers two methods — email and DNS — and DNS is the only one that survives auto-renewal, because email validation requires a human to click a link every 13 months and the cert silently expires the day they’re on vacation.

DNS validation works by ACM publishing a per-domain CNAME challenge that only the domain’s owner can install. Once installed, ACM polls until it sees the record, marks the cert ISSUED, and continues to poll for renewal indefinitely.

What ACM hands you when you request a cert

The CLI/API response carries a DomainValidationOptions array — one entry per name on the cert, including each wildcard. The excerpt below shows two entries already in SUCCESS (a real response carries one entry per SAN, including any still-pending ones):

acm:describe-certificate response (excerpt)
{
  "DomainValidationOptions": [
    {
      "DomainName": "example.com",
      "ValidationDomain": "example.com",
      "ValidationStatus": "SUCCESS",
      "ResourceRecord": {
        "Name": "_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.com.",
        "Type": "CNAME",
        "Value": "_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.xxxxxxxxxx.acm-validations.aws."
      },
      "ValidationMethod": "DNS"
    },
    {
      "DomainName": "*.example.com",
      "ValidationStatus": "SUCCESS",
      "ResourceRecord": {
        "Name": "_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.com.",
        "Type": "CNAME",
        "Value": "_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.xxxxxxxxxx.acm-validations.aws."
      },
      "ValidationMethod": "DNS"
    }
  ]
}

Two things worth noticing in the response:

  • The ResourceRecord.Name is a random hash prefixed with an underscore. Underscored labels are conventionally used for protocol metadata in DNS (_dmarc, _acme-challenge, _domainkey, …); a registry of these prefixes lives in RFC 8552. The convention is what keeps them clear of normal hostnames.
  • The wildcard *.example.com and the apex example.com share the same validation CNAME. ACM intentionally folds them onto one record so you only have to publish once.

The procedure

  1. Request the certificate

    Either via the ACM console or aws acm request-certificate --domain-name example.com --validation-method DNS --subject-alternative-names "*.example.com". The cert enters PENDING_VALIDATION.

  2. Read the validation CNAMEs off the response

    For each unique ResourceRecord in DomainValidationOptions, capture the Name and Value. Duplicates across SANs (apex + wildcard) share a record — publish only once.

  3. Publish each CNAME on the domain's DNS host

    The record name is the hashed underscore label. The value points at *.acm-validations.aws.

    TypeNameValue
    CNAME_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.com._bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.xxxxxxxxxx.acm-validations.aws.

    Most DNS hosts add the parent zone automatically — paste just the first label (_aaaaaaaa...) without the trailing .example.com. portion to avoid double-suffixing.

  4. Wait for ACM to flip status to ISSUED

    ACM polls DNS at its own cadence and flips the status to ISSUED once the CNAME resolves. AWS doesn’t publish an interval; in practice the swap happens within minutes if the record propagated quickly, longer if a stale resolver is in the way. If it lingers, verify the record with nslookup -q=CNAME (see 0022 Verifying AWS DNS records with nslookup · DevOps ).

  5. Leave the CNAME in DNS forever

    Don’t delete it after issuance. ACM-issued public certs are valid for 13 months, and ACM starts attempting renewal roughly 60 days before expiry — at which point it polls the same CNAME again. If the record is gone at renewal time, renewal fails and the cert silently expires when its 13 months are up. The RenewalEligibility: ELIGIBLE field on the cert depends on the record still resolving.

The cert’s lifecycle, one state at a time

The two retry windows are different. Initial validation gives you 72 hours from the request to publish the CNAME — after that the request goes stale and you start over. Renewal gives you the full ~60-day window before NotAfter: ACM polls repeatedly through that window, and only when expiry passes does the cert flip to EXPIRED. Email notifications fire at 45, 30, 7, 3, and 1 day before expiry if renewal hasn’t succeeded.

Why DNS validation, not email

Decision
Chose: DNS validation
2026-05-25

Auto-renewal is the entire point of using ACM instead of buying certs from a CA. Email validation negates that and turns every renewal into a fire drill.

✓ DNS validation
Pros
  • One-time setup
  • Renewal is fully automatic
  • Survives team turnover
  • Works for wildcards
Cons
  • Requires write access to DNS
Email validation
Pros
  • No DNS access needed
Cons
  • Requires a human to click the link every 13 months
  • Cert silently expires if the human is unavailable
  • Five WHOIS-style mailboxes must be reachable (`admin@`, `hostmaster@`, etc.)

Reference