ACM Email Validation to DNS Migration: The Renewal That Stops in 2027

Email-validated ACM certificates never fail loudly. They serve traffic, they show ISSUED in the console, and then one quarter nobody clicks the link in the renewal email and a load balancer starts handing out an expired chain. AWS has now put a date on that failure mode. From 30 September 2027, ACM stops renewing certificates that use email validation in every Region. An ACM email validation to DNS migration is one API call per certificate, so the work is not the hard part. Finding the certificates is, and most teams cannot list theirs today.

Three dates, and only one of them breaks production

The AWS Security Blog post of 13 August 2026, by ACM product manager Adam Aboudi and solutions architect Poojil Tripathi, sets out a staged phaseout:

| Date | What ACM stops doing | Who feels it | |---|---|---| | 1 January 2027 | Offers email validation in new AWS Regions | Teams expanding into a Region launched after that date | | 31 March 2027 | Offers email validation for new certificate requests in any Region | Any pipeline that still requests EMAIL validation | | 30 September 2027 | Renews existing certificates that use email validation in any Region | Every email-validated certificate still in service |

The first two dates block new issuance, which a failing terraform apply will tell you about. The third one is silent. Nothing changes in the console on 30 September 2027. Certificates stay ISSUED until they reach their own expiry, and then they stop working, one at a time, on whatever schedule your estate happens to have.

This is not an AWS decision in isolation. The CA/Browser Forum passed Ballot SC-090 in November 2025, with 27 Certificate Issuers voting yes and none against, and all three Certificate Consumers that voted (Apple, Google, Mozilla) in favour. It retires 3.2.2.4.4 (Constructed Email to Domain Contact), 3.2.2.4.13 (Email to DNS CAA Contact) and 3.2.2.4.14 (Email to DNS TXT Contact) on 15 March 2028. Every public CA is on the same clock. If you are weighing whether to move off ACM instead, the destination has the same constraint.

Note that SC-090 is a different ballot from the one that shortens certificate lifetimes. SC-081v3 cuts how long a certificate lasts and how long a CA may reuse your validation data, and we covered that work in TLS certificate lifecycle automation. SC-090 removes a validation method outright. Shortening a lifetime makes renewals more frequent; removing a method makes them impossible. Treat them as two separate projects with two separate inventories.

Your inventory is a describe-certificate loop

There is no filter for this. aws acm list-certificates accepts --certificate-statuses, --certificate-key-pair-origins, and an --includes structure whose fields are extendedKeyUsage, keyUsage, keyTypes, exportOption and managedBy. Validation method is not among them, so the list call cannot narrow the set for you. You call DescribeCertificate once per certificate, in every Region where you hold one, and read DomainValidationOptions[].ValidationMethod.

The console path is quicker for a single account: in ACM, set the Validation method filter to Email and the Type filter to Amazon Issued. For anything larger than one account, script it.

#!/usr/bin/env bash
# Illustrative inventory sweep. Run per account; add your own
# role-assumption loop for an organization.
set -euo pipefail

for region in $(aws ec2 describe-regions \
      --query 'Regions[].RegionName' --output text); do
  for arn in $(aws acm list-certificates \
        --region "$region" \
        --certificate-statuses ISSUED PENDING_VALIDATION \
        --query 'CertificateSummaryList[].CertificateArn' \
        --output text); do
    aws acm describe-certificate \
      --region "$region" \
      --certificate-arn "$arn" \
      --query "Certificate.{
                 arn: CertificateArn,
                 type: Type,
                 expires: NotAfter,
                 inUseBy: InUseBy,
                 method: DomainValidationOptions[0].ValidationMethod
               }" \
      --output json
  done
done | jq -s '[.[] | select(.method == "EMAIL" and .type == "AMAZON_ISSUED")]
              | sort_by(.expires)'

Two columns in that output decide your order of work. expires tells you which certificates hit their renewal window first, and inUseBy tells you which ones are attached to a CloudFront distribution or a load balancer and will therefore take an endpoint down. A certificate with an empty inUseBy is not urgent, and it is also not eligible for managed renewal at all, since ACM requires the certificate to be in use or to have been exported.

Across the client estates we have audited this year, the email-validated certificates were almost never the ones anybody remembered. They were wildcards issued by hand in 2019 for a Region nobody deploys to any more, still attached to a live listener.

The cutoff is 14 November 2027, not 30 September

ACM public certificates are valid for 198 days, and managed renewal starts 45 days before expiry for both validation methods. Those two numbers move the real deadline earlier than the announced one.

Take the last day ACM will renew an email-validated certificate, 30 September 2027, and add the 45-day renewal window. A certificate expiring after 14 November 2027 has its renewal window open after ACM has stopped renewing, so it never gets an attempt. Now take the other end. A certificate that does renew on 30 September 2027 gets a fresh 198 days and expires on 15 April 2028, a month after the CA/Browser Forum sunset, because SC-090 governs issuance rather than certificates already in the wild.

| Certificate expires | Gets a final email renewal? | Effectively dead on | |---|---|---| | Before 14 November 2027 | Yes, one more cycle | Its own expiry, 198 days later | | 14 November 2027 | The last one that does | 15 April 2028 | | After 14 November 2027 | No attempt is ever made | Its own expiry date |

Run the same arithmetic against the expires column from your inventory and you get a dated work queue rather than a vague 2027 deadline. For most estates the honest reading is that you have two renewal cycles left, and the second one is the last.

Switch in place, and ignore the page that tells you to reissue

Here is the trap. The ACM user guide pages people actually land on still say the migration is impossible. Both email validation and DNS validation carry the note: "After you create a certificate with email validation, you cannot switch to validating it with DNS. To use DNS validation, delete the certificate and then create a new one that uses DNS validation."

That was true until 13 August 2026. It is not true now, and following it costs you a new certificate ARN, which means touching every listener, distribution, API Gateway domain and Terraform reference that points at the old one. The UpdateCertificateOptions API reference is the page that reflects reality: "You can use this operation to change the domain validation method."

# Illustrative. Flip one certificate from email to DNS validation
# in place. The ARN does not change.
CERT_ARN="arn:aws:acm:us-east-1:111122223333:certificate/example-cert-id"

aws acm update-certificate-options \
  --certificate-arn "$CERT_ARN" \
  --options ValidationMethod=DNS

# RequestedValidationConfiguration holds the new challenge.
# ActiveValidationConfiguration still reads EMAIL until it succeeds.
aws acm list-certificate-domain-validations \
  --certificate-arn "$CERT_ARN" \
  --query 'DomainValidationSummaryList[].{
             domain: DomainName,
             active: ActiveValidationConfiguration.ValidationMethod,
             requested: RequestedValidationConfiguration.ValidationMethod
           }'

You then have 72 hours to publish those CNAME records. If the window lapses, the certificate stays on email validation and you run update-certificate-options again, so a missed window costs you a retry rather than an outage. The CNAME itself sits at RequestedValidationConfiguration.ValidationChallenge.DnsValidationChallenge.ResourceRecord in that same response, which ListCertificateDomainValidations is built to page through. DescribeCertificate carries a second progress view in UpdateSummary.DomainValidationMethodUpdateSummary, with From and To fields. Watch one of them rather than waiting for an email that is not coming.

A detail worth knowing before you plan the window: ACM already dropped WHOIS-based email validation, and the user guide now states that "ACM no longer supports WHOIS email validation for new certificates or renewals." What remains are five constructed addresses per domain, admin@, administrator@, hostmaster@, postmaster@ and webmaster@, and the validation token in those messages expires after 72 hours. If nobody at your company owns that mailbox, your email-validated certificates are already renewing on luck.

Terraform destroys the certificate if you just flip the argument

Do not change validation_method in your Terraform config and run apply. In the AWS provider, validation_method is declared ForceNew: true in internal/service/acm/certificate.go, so the plan is a destroy and create, with a new ARN and an outage on every resource referencing it. The provider's update path does call UpdateCertificateOptions, but only when the options block changes, and the documented arguments in that block are certificate_transparency_logging_preference and export. There is no validation_method there. The API supports an in-place switch; the provider resource does not expose it yet.

The order we use, per certificate:

1. Run aws acm update-certificate-options --options ValidationMethod=DNS outside Terraform.
2. Publish the CNAMEs, through aws_route53_record resources if Route 53 holds the zone, within the 72-hour window.
3. Poll list-certificate-domain-validations until ActiveValidationConfiguration.ValidationMethod reads DNS.
4. Only then edit the config to validation_method = "DNS" and run plan. The provider reads the method back from DomainValidationOptions[0].ValidationMethod, so state already says DNS and the plan comes back empty.

Reversing steps 1 and 4 is the mistake, and it is a quiet one, because terraform plan will show the replacement in a wall of output that a reviewer approving twelve certificates at once will skim. Gate it. If you do not already have a policy check that fails a plan containing an aws_acm_certificate replacement, that rule is cheap to add, and it belongs with the other guardrails in Terraform security best practices for AWS.

The CNAME becomes a production dependency

DNS validation trades a recurring human task for a standing infrastructure dependency, and that trade is worth making. It is not free. ACM's renewal criteria for DNS-validated certificates are checked at 45 days before expiry, and both must hold: the certificate is in use by an AWS service, and every ACM-provided CNAME, one per unique subject alternative name, is present and resolvable over public DNS.

Three ways we have watched that break after a clean migration:

• A zone migration between providers copies the A and MX records and drops the underscore-prefixed CNAMEs, because they look like leftovers. Nothing fails for five months.
• A tidy-up removes records nobody could attribute to a service. The _x.acm-validations.aws. targets are exactly the sort of record that gets deleted in a cleanup sprint.
• Too many hops. The DNS validation guide is explicit that "CNAME resolution will fail if more than five CNAMEs are chained together in your DNS configuration." If you front validation records with a CNAME-flattening layer, count the chain.

So wire the alarm while you are in there. ACM publishes an ACM Certificate Renewal Action Required EventBridge event from source: aws.acm when automatic renewal fails, at 30 days before expiry for public certificates and again at 15, 3 and 1 day. Its detail includes DomainValidationMethod and a RenewalStatusReason that will read PENDING_DOMAIN_VALIDATION when the CNAME is missing and NO_AVAILABLE_CONTACTS when an email-validated certificate has nowhere to send its notice. Route both to the on-call channel, not to a mailbox. That one rule is the difference between a 30-day warning and a 3 a.m. page.

The five weeks we would spend on this now

1. Run the inventory sweep across every account and Region in week one, and join expires against inUseBy. The deliverable is a dated queue, not a count.
2. In week two, move the certificates expiring soonest, inside their existing change windows. Exportable certificates cost $7.00 per standard domain name and $79.00 per wildcard, on issuance and again on renewal, so flag those for finance first. Standard public certificates are free, which is why nobody tracks them.
3. Week three is for the pipelines. Anything that still requests EMAIL breaks on 31 March 2027 however clean your existing estate is by then.
4. Add the EventBridge rule and the Terraform policy check in week four, so the next person cannot quietly undo the work.
5. Re-run the sweep at the end. Expect it to turn up a certificate in a Region you forgot and an account outside your main organization.

Five weeks of calendar time, a few days of actual effort, finished eleven months before the deadline instead of during it. The alternative is doing the same work in September 2027 while renewals are already failing.

When to Get Help

This is a well-scoped migration with a published deadline, and most platform teams can run it from the inventory script above. Bring help in when the estate spans more AWS accounts than you can enumerate by hand, when the validation mailboxes belong to a domain you do not control, or when the certificates are referenced by Terraform state you inherited and cannot safely replace.

We run certificate inventories and migrations like this as fixed-scope engagements, and we would rather be the people who found the forgotten wildcard in eu-west-3 than the people on the incident call. If you want a second pair of eyes on your ACM estate before the 2027 dates, get in touch.