Moving AWS Certificate Manager Off Email Validation - The Announced Dates, What UpdateCertificateOptions Changes and Keeps, Finding Email-Validated Certificates, and Where the Documentation Has Not Caught Up

First Published: 2026-10-12
Last Updated: 2026-10-12

AWS Certificate Manager (ACM) will phase out email validation, which it uses for the domain validation of public certificates, in stages during 2027. An AWS Security Blog post from August 13, 2026, gives the timeline as follows.

January 1, 2027: ACM will no longer offer email validation in new AWS Regions.

March 31, 2027: ACM will no longer offer email validation for new certificate requests in any Region.

September 30, 2027: ACM will no longer renew existing certificates that use email validation in any Region.

On the same day, ACM announced in a What's New post that users can now switch existing certificates from email validation to DNS validation. According to this announcement, users can call UpdateCertificateOptions and add the CNAME records specified by ACM to their DNS settings. The certificate ARN will remain unchanged. However, as of October 12, 2026, four pages in the ACM user guide state that it is not possible to switch from email validation to DNS validation. The ACM FAQ also answers "No" to the question of whether existing public certificates can be converted from email validation to DNS validation. The user guide's migration page that the announcement points to redirects to the top page of the user guide.

For the end of email validation, this article lays out by source the dates that AWS has set and published, the contract for the switch, where to find email-validated certificates, and the means of keeping email validation from being used again. For each item, it details who is responsible, what users configure, and where to verify the status, accompanied by supporting documentation. It also highlights where the sources disagree and where no statement was found, providing both statements and the verification dates. The sources used include the AWS Security Blog, What's New, the ACM API Reference, the AWS CLI Reference, the ACM user guide, the ACM FAQ, the Service Authorization Reference, and the AWS CloudFormation and AWS CDK references, as verified on October 12, 2026 (Section 1.3). This article does not call the ACM API or issue any certificates. It also does not recommend whether to choose DNS validation or HTTP validation.

Related articles on this site:

1. ACM Email Validation Ends in Stages — Scope and Verification Date
2. How to Read the Tables — Who Handles It, What You Configure, and How You Can Check It
3. How Email-Validated Certificates Are Renewed Today
4. The Dates — Three Set by ACM and One Set by the CA/Browser Forum
5. The Switch Contract — What UpdateCertificateOptions Changes and Keeps
6. Finding Email-Validated Certificates
7. Keeping New Certificates off Email Validation
8. Where HTTP Validation Applies
9. Where the Sources Disagree and Where No Statement Was Found
10. Frequently Asked Questions about Moving ACM Off Email Validation
11. Summary
12. References

1. ACM Email Validation Ends in Stages — Scope and Verification Date

This section will first briefly outline what ends for ACM email validation, and when. Subsequently, it will define the scope of this article, the verification date, the materials reviewed, and the terminology used within this article.

1.1 What Will End

What ACM is discontinuing regarding email validation varies by date. As of January 1, 2027, ACM will no longer offer email validation in new AWS Regions. Among the sources this article read, the only one mentioning this is the Security Blog dated August 13, 2026; this information is not included in the same day's What's New publication. On March 31, 2027, ACM will stop providing email validation for new certificate requests across all Regions. Furthermore, on September 30, 2027, ACM will no longer renew existing certificates that use email validation in any Region. Both of these dates are mentioned in both the Security Blog and What's New. Additionally, the CA/Browser Forum's Baseline Requirements stipulate that, as of March 15, 2028, certificate authorities (CAs) must no longer rely on email-based validation methods. This date was not determined by ACM. What stops on the four dates differs: email validation in new Regions, email validation for new requests, the renewal of existing certificates, and issuance by CAs (see Section 4).

1.2 Scope of This Article, and What It Does Not Cover

This article addresses the following aspects related to the termination of ACM's email validation for public certificates:

ACM's dates and the sources that state them (Section 4).
The contract for switching the validation method from email to DNS with UpdateCertificateOptions, and the statements not found in the sources (Section 5).
Where to find email-validated certificates (Section 6).
Methods to prevent the creation of new email-validated certificates (Section 7).
The scope of HTTP validation (Section 8).
Where the sources disagree, and where no statement was found (Section 9).

This article does not cover:

Industry domain validation methods and the schedule for shortening certificate validity periods: These are covered in the existing publication TLS Certificate Ecosystem History and Timeline. This article covers only the compliance-table entry for the CA/Browser Forum's March 15, 2028 date.
The process of obtaining certificates through DNS validation: This is covered in the existing publication Indie Dev Guide: From Domain Acquisition to Live Site with AWS Route 53, S3, CloudFront, and ACM.
The differences between the three methods for obtaining public certificates from ACM: This is covered by a companion article, How AWS Certificate Manager Issues Public Certificates.
The extended key usage (EKU) of public certificates: A companion article, When Public Certificates Stop Carrying clientAuth, covers this topic.
Details of the end of WHOIS-based email validation (2024). This article mentions it in one sentence in Section 3.
Pricing.

1.3 The Verification Date and the Sources Read

The information presented in this article was verified using the following materials on October 12, 2026.

AWS Security Blog: AWS Certificate Manager will discontinue email validation to prove domain validation for certificates (August 13, 2026, by Adam Aboudi and Poojil Tripathi).
What's New: AWS Certificate Manager supports switching from e-mail to DNS validation (postDateTime is 2026-08-13T15:00:00Z).
ACM API Reference: Details for the following operations: UpdateCertificateOptions, ListCertificateDomainValidations, SearchCertificates, ListCertificates, DescribeCertificate, and RequestCertificate. Also includes details for the following data types: CertificateOptions, DomainValidationSummary, ValidationConfiguration, AcmCertificateMetadataFilter, AcmCertificateMetadata, CertificateDetail, UpdateSummary, DomainValidationMethodUpdateSummary, DomainValidation, and Filters.
AWS CLI Reference: Details for the following commands: update-certificate-options, list-certificate-domain-validations, search-certificates, list-certificates, request-certificate, and describe-certificate (version 2.37.12).
ACM User Guide: Includes pages on domain validation entry points, DNS validation, email validation, HTTP validation, troubleshooting email validation, renewal for email-validated domains, condition keys, certificate searching, EventBridge, and Document history, among other topics.
ACM FAQ
Service Authorization Reference: ACM section.
AWS CloudFormation: Reference for AWS::CertificateManager::Certificate, and AWS CDK: Reference for CertificateProps and CertificateValidation (version v2.273.0).
AWS re:Post Knowledge Center: Article on switching an ACM certificate's validation method (dateModified is 2023-11-30).
CA/Browser Forum: Baseline Requirements, version v2.3.1 (dated October 4, 2026), and the Ballot SC-090 page.

One key point of this article is that the user guide does not yet reflect the announcements. When the user guide is updated, the content in Section 9 of this article will change. At the time you read this article, you will need to review the pages listed in Section 9.3.

1.4 Terms with the Same Spelling Referring to Different Things

This article identifies instances where the same term refers to different concepts. To avoid misinterpretations, this section clarifies these distinctions upfront.

72 Hours (five that this article distinguishes): (1) The 72-hour switch window. The time the user has, after switching to DNS with UpdateCertificateOptions, to add the CNAME records; even after it passes, the certificate remains valid on email validation (Security Blog). (2) The 72-hour period for new DNS validation. If validation cannot be completed within 72 hours of ACM generating the CNAME, ACM changes the certificate status to Validation timed out (DNS validation page in the user guide). (3) The 72-hour period before the token included in the validation email expires (email validation page in the user guide). (4) The 72-hour period for HTTP validation (HTTP validation page in the user guide). (5) The 72-hour period mentioned in the description of the VALIDATION_TIMED_OUT value of Status in the API (e.g., CertificateDetail in the API reference). Throughout this article, whenever "72 hours" is mentioned, this article specifies which 72-hour period is being referenced.
Validation (three that this article distinguishes): Refers to the validation process itself, the switching of validation methods, and the values of the ValidationStatus field.
Stops (four that this article distinguishes): Refers to the discontinuation of email validation in new Regions, the discontinuation of email validation for new requests, the end of renewals of email-validated certificates, and the end of issuance by a CA using an email-based method. This article will not combine these into a single statement suggesting that email validation is entirely unavailable.
DNS, EMAIL, HTTP: In the text, these refer to DNS validation, email validation, and HTTP validation, respectively. When written in code, these represent the values of the ValidationMethod field.

2. How to Read the Tables — Who Handles It, What You Configure, and How You Can Check It

The tables in Sections 4 through 7 borrow the columns and terms defined in Section 2 of How AWS Certificate Manager Issues Public Certificates. This section will briefly outline the borrowed elements and define the additions made in this article.

2.1 Common Columns

The tables in Sections 4 through 7 share the following five columns:

Aspect: The item of the contract. This article sets the values section by section.
Handled By: Who is responsible for that item (see Section 2.2).
What You Configure: The settings the user configures, or the operations the user calls. If no setting by the user is found in the sources, write Nothing.
How You Can Check It: The type of location where the user can verify this, along with the specific name (see Section 2.3).
Where the Source Says So: The source document that supports this entry. Indicate this with either the title of the page, the name of an API operation, or the name of a data type.

2.2 `Handled By` Values

A companion article defined the following five values for the Handled By column. This article uses these five values as well.

ACM: Handled by ACM.
You: Handled by the user.
Your ACME client: Handled by the user's ACME client. This value will not be used in this article.
The certificate authority: Handled by the certificate authority (CA).
The source does not say.: The source material does not specify who is responsible.

This article will add one additional value, without altering the meaning of the existing five.

The CA/Browser Forum: Handled by the CA/Browser Forum. The CA/Browser Forum is an organization that defines the Baseline Requirements that public CAs must adhere to. In this article, on the row dated March 15, 2028, it will be written as The CA/Browser Forum (sets the rule), The certificate authority (complies).

When multiple values are listed in a single cell, use parentheses to indicate the role of each value. For example, ACM (provides the records), You (adds them) indicates that ACM provides the records and the user adds them.

2.3 `How You Can Check It` Types

The How You Can Check It column begins with one of the following types, followed by a specific name.

API field: Can be verified by examining a field in the API response.
API operation: Can be verified by examining the result of an API operation.
Console: Can be verified in the AWS Management Console.
CloudTrail management event: Can be verified by examining CloudTrail management events. Management events are recorded by default.
CloudTrail data event: Can be verified by examining CloudTrail data events. Data events are not recorded by default.
CloudWatch metric: Can be verified by examining CloudWatch metrics.
EventBridge event: Can be verified by examining events in Amazon EventBridge.
Documentation only: There is a description in the documentation, but no location was found to verify it.
Not found: No location or description was found in the documents reviewed.

Documentation only and Not found do not mean that there is no way to verify the information. The documents and search terms used are described in Section 9.2.

2.4 The Column This Article Adds — `Source Date`

This article only adds the Source Date column to the schedule table (Section 4.7) and the table of disagreements (Section 9.1). The Source Date column will contain the name of the material that provides the information for that row, along with the date from that material. For What's New, the date will be the postDateTime from the announcement. For blog posts, the date will follow the blog name, indicating the publication date of the page. For the Baseline Requirements, the version number will be included. For user guides, API references, and FAQs, as these do not have dates on the pages themselves, the date will reflect the day the information was verified.

In the schedule table, the Aspect value states what stops. The Source Date column indicates which material provides the date listed. For the row dated January 1, 2027, only one material is the source.

2.5 When the Source Does Not Say, and When Sources Disagree

In each table cell, include only the information provided in the source material, or a summary of that information. If the source does not address a point, write The source does not say. Before writing this, this article searches the full text of the source document, as well as links from that source, and other pages from the same provider. These other pages may include the user guide, API reference, CLI reference, FAQ, What's New, Document history, Security Blog, and Service Authorization Reference. The searches use the subject of the row, along with the terms email, validation, migrat, switch, 72, and HTTP.

When the sources disagree, list both descriptions, each with its corresponding source, without favoring either one. The disagreements in this article are summarized in Section 9.1. Any typos in the original text, as well as any original symbols (including the curly right quotation mark and the sequence of two periods), are kept as published in the quotations. Typos are not marked inside the quotations.

3. How Email-Validated Certificates Are Renewed Today

This section describes, as background for the 2027 timeline, how email-validated certificates are currently issued and renewed, as outlined in the user guide. This article does not cover the process of starting to use email validation.

3.1 Five Common Addresses

According to the user guide's email validation page, ACM sends validation emails to the following five common system addresses for each domain:

administrator@your_domain_name
hostmaster@your_domain_name
postmaster@your_domain_name
webmaster@your_domain_name
admin@your_domain_name

Users can also specify a superdomain as the validation domain. To prove ownership of the domain, the domain owner must select the validation link included in the email. The same page states that the token included in the validation email expires after 72 hours. This 72-hour period refers to the 72-hour validity of the email token. The Document history section of the user guide contains two entries on deprecations within email validation. An entry dated February 5, 2024, announced the discontinuation of email validation based on WHOIS data, effective June 2024. An entry dated July 11, 2024, states that the console no longer supports MX (Mail Exchange) records.

3.2 Renewal Requires Action by the Domain Owner

The user guide's page on renewal for email-validated domains describes the renewal of email-validated certificates as follows:

ACM certificates are valid for 198 days. Renewing a certificate requires action by the domain owner. ACM begins sending renewal notices to the email addresses associated with the domain 45 days before expiration.

According to the same page, when the domain owner selects the notification link and all listed domains are validated, ACM will issue a renewed certificate with the same ARN. If ACM is unable to automatically validate the domains, it will send AWS Health events and EventBridge events 30, 15, 7, 3, and 1 days prior to the certificate's expiration. The user guide's entry page for domain validation also gives, as a reason to recommend DNS validation, that renewing an email-validated certificate requires action by the domain owner.

In other words, renewing an email-validated certificate depends on the domain owner's action whenever ACM cannot validate the domains automatically. ACM will discontinue this renewal process on September 30, 2027 (see Section 4.3).

3.3 When Using AWS CloudFormation and AWS CDK

The CloudFormation reference for AWS::CertificateManager::Certificate describes the behavior when an email-validated certificate is created in a stack as follows:

However, if the certificate uses email validation, or if the domain is not hosted in Route 53, then the stack will remain in the CREATE_IN_PROGRESS state.

Similarly, the documentation for AWS CDK's CertificateValidation.fromEmail() states that when a certificate is created within a stack, the stack creation will not complete until the email instructions have been followed. Section 7 will discuss how both CloudFormation and CDK default to email validation.

4. The Dates — Three Set by ACM and One Set by the CA/Browser Forum

This section will outline the four dates, indicating what stops on each date and the sources that state it. Figure 1 displays these four dates, along with the start of the switch on August 13, 2026, on a timeline.

Email Validation Cutoff Dates and Their Sources

4.1 January 1, 2027 — Not Offered in New Regions

The Security Blog's schedule entry states that, as of January 1, 2027, ACM will no longer offer email validation in new AWS Regions. The body of the What's New post lists two of ACM's dates – March 31, 2027, and September 30, 2027 – but does not mention January 1, 2027. The user guide and the FAQ do not state the schedule for the end of email validation at all (Section 9).

The Security Blog does not specify which new Regions are affected. This entry also does not say what changes in Regions where ACM became available before January 1, 2027. This entry only states that, as of January 1, 2027, ACM will no longer provide email validation in new AWS Regions.

4.2 March 31, 2027 — Not Offered for New Requests

The Security Blog's schedule entry states that as of March 31, 2027, ACM will no longer offer email validation for new certificate requests across all Regions. The What's New post states the same date as follows. The missing comma after the date is as published.

ACM will no longer issue email-validated certificates starting March 31 2027, and stop renewing email-validated certificates on September 30 2027.

Users requesting new certificates on or after this date will need to specify a validation method other than email in the ValidationMethod field of the RequestCertificate call. The RequestCertificate API reference lists three valid values for ValidationMethod: EMAIL, DNS, and HTTP, and marks it Required: No. The default method used when no value is specified is not documented in this API reference (see Sections 7 and 9.2).

4.3 September 30, 2027 — Existing Certificates Are No Longer Renewed

The schedule entry in the Security Blog gives only one sentence for September 30, 2027.

September 30, 2027: ACM will no longer renew existing certificates that use email validation in any Region.

This entry describes the point at which ACM will stop renewing email-validated certificates. It does not state that email-validated certificates will become unusable on that date. Furthermore, this entry does not specify what will happen after that date to email-validated certificates that have already been issued.

In contrast, the introductory paragraph of the same Security Blog mentions the same date as follows:

Today, we’re announcing that AWS Certificate Manager (ACM) will discontinue support for email-validated public certificates by September 30, 2027.

The introductory paragraph states that support will end, while the schedule entry states that renewals will cease. This article will treat September 30, 2027, as the date ACM stops renewing certificates, following the wording of the schedule entry. According to the user guide, the current validity period for certificates is 198 days. The FAQ states that as of March 15, 2027, the maximum lifetime for a public TLS certificate issued will be less than 100 days. No source was found that states the exact validity period of a certificate renewed just before September 30, 2027. This article will not calculate the expiry date.

4.4 March 15, 2028 — The CA/Browser Forum Date

The CA/Browser Forum's Baseline Requirements, version 2.3.1 (dated October 4, 2026), includes an entry for March 15, 2028, in its compliance date table. This entry, pertaining to Sections 3.2.2.4 and 3.2.2.5, states:

CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates.

This entry specifies that CAs must not issue certificates relying on the specified validation methods. This rule applies to CAs, and not to users of ACM. The history of Ballot SC-090, which established this rule, is covered in the existing article TLS Certificate Ecosystem History and Timeline.

No AWS source was found that states which Baseline Requirements method ACM email validation corresponds to. This article does not address that correspondence.

4.5 Two Sentences: Not Trusted by Browsers, and Valid until Expiry

The Security Blog writes two sentences about March 15, 2028, in different paragraphs. The Background paragraph says:

After that date, certificates validated through email won’t be trusted by browsers, regardless of which certificate authority issued them.

The March 15, 2028 entry of the schedule ends with the following sentence:

Certificates issued before this date remain valid until they expire.

The first sentence states that after March 15, 2028, browsers will no longer trust certificates validated through email. The second sentence states that certificates issued before this date remain valid until their expiration date. Both sentences refer to March 15, 2028, and not to September 30, 2027. This article presents both sentences side by side without favoring either (see Section 9.1).

4.6 Two Sentences That Give a One-Year Migration Period

The Security Blog gives a one-year migration period in two places. The introductory paragraph contains the phrase gives you a full year to migrate ahead of the Forum’s March 2028 deadline, while the Background paragraph states:

The ACM timeline gives customers one year to migrate before the CA/B Forum’s hard deadline.

Both sentences fail to specify the start date for this one-year period. Calculated from the dates, the period from September 30, 2027, to March 15, 2028, is 167 days; from August 13, 2026, to September 30, 2027, is 413 days; and from August 13, 2026, to March 15, 2028, is 580 days. These three day counts are this article's own calculation. The Security Blog does not specify which period its stated one year refers to. This article does not claim that either statement is incorrect.

4.7 Schedule Table

The following table lists the four dates by what stops.

Aspect	Source Date	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`Email validation in new Regions` (2027-01-01)	Security Blog 2026-08-13 only (of the sources read). Not mentioned in the body of What's New 2026-08-13.	`ACM`	`Nothing`	`Documentation only`: The schedule entries of the AWS Security Blog	AWS Security Blog
`Email validation for new certificate requests` (2027-03-31)	Security Blog 2026-08-13, What's New 2026-08-13	`ACM`	When making a new request, specify anything other than `EMAIL` for the `ValidationMethod`.	`Documentation only`: The AWS Security Blog and What's New	AWS Security Blog, What's New
`Renewal of email-validated certificates` (2027-09-30)	Security Blog 2026-08-13, What's New 2026-08-13	`ACM (stops renewing), You (switches to DNS)`	Use `UpdateCertificateOptions` to change the `ValidationMethod` to `DNS` and add the CNAME records.	`API field`: `ActiveValidationConfiguration` of `ListCertificateDomainValidations`	AWS Security Blog, What's New
`CA reliance on email-based methods` (2028-03-15)	Baseline Requirements v2.3.1, Security Blog 2026-08-13, What's New 2026-08-13	`The CA/Browser Forum (sets the rule), The certificate authority (complies)`	`Nothing`	`Documentation only`: The compliance date table of the Baseline Requirements	Baseline Requirements v2.3.1

5. The Switch Contract — What UpdateCertificateOptions Changes and Keeps

This section outlines which operations users call, what ACM provides, and what remains unchanged when switching an existing email-validated certificate to DNS validation, based on the Security Blog, What's New, and the API reference. Figure 2 illustrates the switch process and the responsibilities at each stage.

Switching an Email-Validated Certificate to DNS

5.1 The User Invokes UpdateCertificateOptions

The user starts the switch. The user invokes UpdateCertificateOptions, specifying DNS for the ValidationMethod in Options. The API reference page for UpdateCertificateOptions describes this operation as follows:

Updates certificate options. You can use this operation to change the domain validation method or specify whether to export your certificate.

The type of Options is a data type called CertificateOptions. The API reference for CertificateOptions lists ValidationMethod with three possible values: EMAIL, DNS, and HTTP, and marks it Required: No.

The domain validation method for the certificate. To migrate from email to DNS validation, specify DNS.

This description appears on the CertificateOptions page, and also in the AWS CLI reference, rather than on the UpdateCertificateOptions page itself. The example on the UpdateCertificateOptions page demonstrates the following request. The account ID and ARN values are those provided in the API reference example.

{
  "CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234-123456789012",
  "Options": {
    "ValidationMethod": "DNS"
  }
}

According to the API reference, upon successful execution of this operation, ACM returns an HTTP 200 status code along with an empty body. The response does not include the CNAME records or the state of the switch. Where to see the CNAME records and the state is covered in Section 5.5.

According to the Security Blog, in the console, the user opens the certificate page and selects Update validation method located at the top of the page. The "Quotas" page in the user guide specifies a limit of five requests per Region and account per second for UpdateCertificateOptions. Users who switch a large number of certificates using scripts may receive a ThrottlingException if they exceed this limit.

5.2 ACM Provides the CNAME Records, and the User Adds Them to DNS

According to What's New, when the user requests the switch, ACM provides one CNAME record for each domain covered by the certificate. What's New describes this as the same mechanism used when issuing new certificates through DNS validation. It is the user who adds the CNAME records to their DNS configuration.

According to the Security Blog, when initiating a switch, the console displays a View DNS records notification at the top of the certificate page. From there, users can download a CSV file containing the CNAME records and provide it to another DNS provider. For Route 53 users, there is a Create records in Route 53 option. Through the API, the ListCertificateDomainValidations response includes a RequestedValidationConfiguration that contains the CNAME records (specifically, the ResourceRecord details including Name, Type, and Value) for each domain. The example CNAME record in the API reference directs to a value ending in acm-validations.aws., using a name that combines the domain with a random string that begins with an underscore (_).

According to the DNS validation page in the user guide, the CNAME records for wildcard domains (such as *.example.com) and their base domains (such as example.com) are the same. Adding CNAME records to DNS is covered in Section 5 of the existing article Indie Dev Guide. The design of the hosted zones where these CNAME records are placed is covered in the existing article Amazon Route 53 DNS Architecture Guide.

5.3 The 72-Hour Switch Window

The Security Blog describes the 72-hour switch window as follows:

When you update a certificate to DNS validation, ACM provides a CNAME record to add to your DNS configuration, and you have 72 hours to add that record. During this window, the certificate continues to function normally on email validation. If the 72 hours elapse without a DNS update, the certificate stays active on email validation and you can retry when ready.

What's New states the same period as up to 72 hours. According to the Security Blog quoted above, during this 72-hour period, the certificate continues to function with email validation. Even after the 72-hour period, the certificate remains valid with email validation, and the user can retry when ready.

This 72-hour period behaves differently from the 72-hour period for new DNS validation. The user guide's DNS validation page states the following regarding new certificates:

If ACM is not able to validate the domain name within 72 hours from the time it generates a CNAME value for you, ACM changes the certificate status to Validation timed out.

For new certificates, after the 72-hour period, ACM changes the certificate status to Validation timed out. In contrast, for a switch, the certificate remains valid with email validation even after the 72-hour period. While both involve a 72-hour timeframe, the outcome after that period differs significantly.

The Security Blog does not say what the user calls to retry. No statement on retrying a switch was found in the API reference either (Section 9.2).

5.4 The ARN and the Attachments Do Not Change

The Security Blog notes that the ARN does not change during the switch. The missing space in Name(ARN) is as published.

This means the certificate Amazon Resource Name(ARN) will remain the same and no changes will be needed to your AWS resources that reference the certificate.

What's New also states that the switch does not require reissuing certificates and that the existing ARN remains unchanged. It further explains that CI/CD pipelines, load balancer configurations, and other integrations with AWS services that reference the ARN will continue to function without modification. In other words, users do not need to reattach the switched certificate to integrated services.

5.5 Where to See the State of the Switch

The response from UpdateCertificateOptions is empty. The API reference gives two places to see the state of the switch.

The first is ListCertificateDomainValidations. The API reference describes this operation as follows:

Returns per-domain validation summaries for an ACM certificate. Each summary includes the domain name, the active validation configuration, and the requested validation configuration when a validation method migration is in progress.

For each domain, the DomainValidationSummary includes both ActiveValidationConfiguration and RequestedValidationConfiguration. ActiveValidationConfiguration is the validation configuration that ACM currently uses for that domain. RequestedValidationConfiguration only appears when a switch is in progress, and it contains information about the target method, the validation status, and the CNAME record. The ValidationStatus field can have one of three values: PENDING_VALIDATION, SUCCESS, or FAILED. In the example response provided in the API reference, both domains show an ActiveValidationConfiguration with a ValidationMethod of EMAIL and a RequestedValidationConfiguration whose ValidationMethod is DNS and whose ValidationStatus is PENDING_VALIDATION.

The second is the UpdateSummary in the CertificateDetail of the response from DescribeCertificate. The API reference uses "update" to refer to changes in the certificate's configuration. This article calls it a change, to distinguish it from certificate renewal in Section 3. The API reference describes UpdateSummary as containing information about the certificate's most recent change. This field only exists when the certificate type is AMAZON_ISSUED and a change to the certificate has been requested. UpdateSummary includes the following fields.

Type: The type of change. The value is limited to DOMAIN_VALIDATION_METHOD.
Status: The status of the change. The value can be PENDING_DOMAIN_VALIDATION, SUCCESS, or FAILED.
DomainValidationMethodUpdateSummary: Details of the change, including the previous method (From) and the new method (To).
RequestedAt and UpdatedAt: The time the change was requested and the time the status was last updated.

Regarding the DomainValidationOptions of CertificateDetail, the API reference states:

Contains information about the initial validation of each domain name that occurs as a result of the RequestCertificate request.

DomainValidationOptions contains the initial validation information provided when the certificate was requested. The API reference does not specify whether the value of DomainValidationOptions changes after a change is made (see Section 9.2).

5.6 Renewal After the Switch

The Security Blog states that after DNS validation is complete, ACM is designed to automatically renew certificates before their expiration date. The user guide's DNS validation page outlines the conditions for automatic certificate renewal as follows:

ACM automatically renews your certificate as long as the certificate is in use and your CNAME record remains in place.

This condition has two requirements: the certificate must be in use, and a CNAME record must still be present. Users are responsible for maintaining the CNAME record. The same page also states that deleting the CNAME record will stop the automatic renewal. The Managed certificate renewal page in the user guide lists the conditions under which a certificate is eligible for automatic renewal, including being associated with other AWS services such as Elastic Load Balancing and CloudFront, and having been exported after issuance or the last renewal.

5.7 Statements Not Found in the Sources

Regarding the switch, the following statements were not found in the sources read on October 12, 2026. The specific pages and terms searched for are detailed in Section 9.2.

The behavior when calling UpdateCertificateOptions with HTTP specified for the ValidationMethod. While HTTP is listed as a valid value for CertificateOptions, no statement describes a switch to HTTP validation.
The conditions under which UpdateCertificateOptions returns an InvalidStateException. The API reference only states, Processing has reached an invalid state.
How a renewal is handled if it falls due during the 72-hour switch window.
After the 72-hour switch window has passed, what the RequestedValidationConfiguration in ListCertificateDomainValidations and the Status in UpdateSummary indicate.
The value of DomainValidationOptions after the switch.
The operation to call when retrying after the 72 hours have passed.

5.8 Switch Contract Table

The following table lists the switch contract by aspect.

Aspect	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`Starting the switch`	`You`	Set `ValidationMethod` to `DNS` in the `Options` field of `UpdateCertificateOptions`. In the console, select `Update validation method`.	`API field`: `DescribeCertificate`'s `UpdateSummary`.	`UpdateCertificateOptions`, `CertificateOptions`, AWS Security Blog
`Adding the CNAME records`	`ACM (provides the records), You (adds them)`	Add the CNAME records for each domain to your DNS.	`API field`: `ResourceRecord` in the `RequestedValidationConfiguration` of `ListCertificateDomainValidations`. `Console`: `View DNS records`	What's New, AWS Security Blog, `ListCertificateDomainValidations`
`The 72-hour switch window`	`ACM (keeps email validation active), You (adds the records within 72 hours)`	Add the CNAME records within 72 hours.	`API field`: `ValidationStatus`, `UpdateSummary`'s `Status`. The values after the 72 hours: `Not found`	AWS Security Blog, What's New
`Certificate ARN`	`ACM`	`Nothing`	`Documentation only`: The Security Blog and What's New	AWS Security Blog, What's New
`Renewal after the switch`	`ACM (renews), You (keeps the CNAME records)`	Keep the CNAME records. Keep the certificate in use.	`API field`: `DescribeCertificate`'s `RenewalSummary`.	AWS Certificate Manager DNS validation, AWS Security Blog
`Passing HTTP`	`The source does not say.`	The list of values for `CertificateOptions` includes `HTTP`.	`Not found`	`CertificateOptions`
`Conditions that reject a switch`	`The source does not say.`	`Nothing`	`Not found` for a switch. There are six errors, each with only a general description (`ConflictException`, `InvalidArnException`, `InvalidStateException`, `LimitExceededException`, `ResourceNotFoundException`, `ValidationException`).	`UpdateCertificateOptions`

6. Finding Email-Validated Certificates

This section details where users can locate their email-validated certificates, broken down by source. This article does not claim to list every possible location. It lists only the locations verified as of October 12, 2026.

6.1 Console Filters

The Security Blog states that when filtering the ACM console to show only Validation method set to Email and Type set to Amazon Issued, a list of email-validated public certificates will appear. The Security Blog further states that these certificates should be migrated before September 30, 2027.

6.2 Security Blog Script

The Security Blog also provides a script for searching using the AWS CLI. The script takes a single Region as an argument (the default is us-east-1) and sequentially executes the following two commands:

It calls aws acm list-certificates with the argument --query "CertificateSummaryList[?Type=='AMAZON_ISSUED'].CertificateArn" to obtain the ARNs of certificates issued by ACM.
For each ARN, it calls aws acm describe-certificate with the argument --query 'Certificate.[DomainName,Type,DomainValidationOptions[0].ValidationMethod]' and uses awk to retain only the lines where the third column is EMAIL.

This article notes three things about the script. The first two can be read from the sources; the third is this article's inference.

First, the script examines only one Region per execution. As the Security Blog also demonstrates, to check a different Region, you must re-run the script, passing the desired Region as an argument.

Second, the script only reads the ValidationMethod of the first element within DomainValidationOptions. As described in Section 5.5, DomainValidationOptions contains the initial validation information provided when the certificate was requested. The sources do not say whether this value changes after a switch.

The third point is this article's inference. The script does not pass the --includes parameter to the list-certificates command. The API reference page for ListCertificates states, Default filtering returns only RSA_2048 certificates. Furthermore, the data type description for Filters and its keyTypes field states, Default filtering returns only RSA_1024 and RSA_2048 certificates that have at least one domain. Taken together, the two statements suggest that certificates with ECDSA keys may not appear in the list that this script produces. The Security Blog does not specify which key types the script retrieves. This article did not run the script. The default filtering behavior for ListCertificates is discussed in Section 7.1 of How AWS Certificate Manager Issues Public Certificates.

6.3 Filtering by Validation Method with SearchCertificates

The SearchCertificates feature, announced in the April 7, 2026 What's New post, allows you to filter certificates based on ACM attributes. The user guide's certificate search page lists validation method as one of the ACM metadata filters. The API reference for AcmCertificateMetadataFilter accepts the values EMAIL, DNS, and HTTP for the ValidationMethod field. To replicate the console filtering options, and mirroring the example in the API reference, the corresponding FilterStatement would be structured as follows. This article does not send this request.

{
  "FilterStatement": {
    "And": [
      {
        "Filter": {
          "AcmCertificateMetadataFilter": {
            "ValidationMethod": "EMAIL"
          }
        }
      },
      {
        "Filter": {
          "AcmCertificateMetadataFilter": {
            "Type": "AMAZON_ISSUED"
          }
        }
      }
    ]
  }
}

The AcmCertificateMetadata returned in the search results also includes the ValidationMethod field. The sources do not say what value this field shows while a switch is in progress and after it (Section 9.2). Section 7.2 of How AWS Certificate Manager Issues Public Certificates, a companion article, covers where the sources disagree on what SearchCertificates returns by default.

6.4 Seeing the State per Domain — ListCertificateDomainValidations

ListCertificateDomainValidations returns the current validation settings and the settings for the switch, for each domain associated with a certificate (see Section 5.5). The API reference states that this operation allows you to monitor the progress of an email-to-DNS validation migration and retrieve the necessary CNAME records for DNS validation. By default, this operation returns up to 1,000 domains per call. This operation accepts the ARN of a single certificate, so it is an operation for viewing the state of an already-identified certificate, rather than for locating a certificate.

6.5 What to See in DescribeCertificate

In the DescribeCertificate response, the state of the switch is in UpdateSummary (see Section 5.5). DomainValidationOptions provides the initial validation information.

6.6 Counting by Region

The "What is AWS Certificate Manager?" page of the user guide states:

Certificates in ACM are regional resources.

According to the same page, certificates used with CloudFront are requested or imported in the US East (N. Virginia) Region. Users who take stock of email-validated certificates will look at the places in Sections 6.1 through 6.5 in each Region they use. No statement was found in the API reference that SearchCertificates or ListCertificates returns results across multiple Regions. The DNS validation page of the user guide states that the tokens used for CNAME validation are valid in any Region.

6.7 Table for Finding Certificates

The following table lists where to find email-validated certificates and where to see their state.

Aspect	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`Console filter`	`You`	Narrow the results by setting the `Validation method` to `Email` and the `Type` to `Amazon Issued`.	`Console`: List of ACM certificates.	AWS Security Blog
`Script in the Security Blog`	`You`	Execute the script, passing the Region as an argument.	`API field`: The `ValidationMethod` of the first element in `DomainValidationOptions` in the `DescribeCertificate` response.	AWS Security Blog
`SearchCertificates filter`	`You`	Filter using the `AcmCertificateMetadataFilter` and setting the `ValidationMethod` to `EMAIL`.	`API field`: The `ValidationMethod` in the `AcmCertificateMetadata` response.	`SearchCertificates`, `AcmCertificateMetadataFilter`, Search certificates managed by AWS Certificate Manager
`Per-domain validation status`	`You`	Call `ListCertificateDomainValidations` using the certificate's ARN.	`API field`: `ActiveValidationConfiguration` and `RequestedValidationConfiguration`.	`ListCertificateDomainValidations`, `DomainValidationSummary`
`Switch status`	`You`	Call `DescribeCertificate`.	`API field`: The `Status` within `UpdateSummary` and `DomainValidationMethodUpdateSummary`.	`CertificateDetail`, `UpdateSummary`
`Regions`	`You`	Check the appropriate location for each Region.	`Documentation only`: ACM certificates are regional resources.	What is AWS Certificate Manager?

7. Keeping New Certificates off Email Validation

This section outlines methods to prevent the creation of new email-validated certificates within an organization, as described in the sources. It also highlights that the default validation method in CloudFormation and CDK is email.

7.1 IAM Condition Key: acm:ValidationMethod

The condition key page in the user guide lists acm:ValidationMethod as a condition key that can be used with the RequestCertificate operation, with a data type of String (DNS, EMAIL, HTTP) and a description that reads Filter requests based on ACM validation method. Example 1 on the same page is a policy that denies new requests for email validation, except for requests associated with a specific role. The role ARN is the example value provided in the user guide.

{
    "Version":"2012-10-17",
    "Statement":{
        "Effect":"Deny",
        "Action":"acm:RequestCertificate",
        "Resource":"*",
        "Condition":{
            "StringLike" : {
                "acm:ValidationMethod":"EMAIL"
            },
            "ArnNotLike": {
                "aws:PrincipalArn": [ "arn:aws:iam::123456789012:role/AllowedEmailValidation"]
            }
        }
    }
}

The ACM section in the Service Authorization Reference defines acm:ValidationMethod as follows:

Filters access by validationMethod in the request. Default 'EMAIL' if no key is present in the request

According to this definition, if a request does not include a validation method, the condition key's value is treated as EMAIL.

The sources disagree on which operations support this condition key. The user guide's condition key table lists only RequestCertificate as an operation that can use acm:ValidationMethod. The Service Authorization Reference includes acm:ValidationMethod in both the RequestCertificate row and the UpdateCertificateOptions row. Neither source provides an example policy that uses this condition key with UpdateCertificateOptions (see Section 9.1). The order in which policies are evaluated is covered in the existing article IAM Policy Evaluation Logic Step-by-Step.

7.2 The AWS CloudFormation Default Is Email Validation

The CloudFormation reference for AWS::CertificateManager::Certificate describes the ValidationMethod property as follows:

If not specified, this property defaults to email validation.

This means that certificates without a specified ValidationMethod in the template will be created using email validation. The same reference lists the possible values for ValidationMethod as EMAIL, DNS, and HTTP, and states We recommend that you use DNS validation. It gives the update behavior of the property as Update requires: No interruption. As described in Section 3.3, when a certificate is created within a stack using email validation, the stack remains in the CREATE_IN_PROGRESS state until the certificate is approved.

The reference does not specify whether CloudFormation will call UpdateCertificateOptions when the ValidationMethod is subsequently changed from EMAIL to DNS. However, the same reference states that changes to the CertificateTransparencyLoggingPreference property (deprecated in the ACM API) will trigger a call to UpdateCertificateOptions to update the existing resource. There is no similar statement regarding ValidationMethod (see Section 9.2).

7.3 The AWS CDK Default Is Also Email Validation

The AWS CDK CertificateProps reference (v2.273.0) describes the default setting for the validation property as follows:

(optional, default: CertificateValidation.fromEmail())

The CertificateValidation class has three static methods: fromDns(), fromDnsMultiZone(), and fromEmail(). The description for fromEmail() states that when a certificate is created within a stack, the stack's creation will not complete until the user follows the instructions received in the email. Certificates created with no validation specified in CDK will default to using email validation.

7.4 Templates in Existing Articles on This Site

The templates in two existing articles on this site, AWS CloudFormation Templates and AWS Lambda Custom Resources for Associating AWS Certificate Manager, Lambda@Edge, and AWS WAF with a Website on Amazon S3 and Amazon CloudFront Cross-Region and Indie Dev Guide, both specify ValidationMethod: DNS explicitly.

7.5 Table of Means to Keep Email Validation from Being Used

The following table lists the means of keeping email validation from being used for new certificates, and the places where email validation is the default.

Aspect	Handled By	What You Configure	How You Can Check It	Where the Source Says So
`acm:ValidationMethod` on `RequestCertificate`	`You`	Using an IAM policy to deny `acm:RequestCertificate` requests where `acm:ValidationMethod` is `EMAIL`.	`Documentation only`: User guide example 1	Use condition keys with ACM, Service Authorization Reference
`acm:ValidationMethod` on `UpdateCertificateOptions`	`You`	The Service Authorization Reference lists the condition key for this operation. The user guide does not.	`Documentation only`: Service Authorization Reference only	Service Authorization Reference
`CloudFormation default`	`You`	For newly created certificate templates, specify `ValidationMethod: DNS`. The behavior when it is added to the template of an existing certificate: `Not found` beyond `Update requires: No interruption`	`Documentation only`: Email validation is the default	`AWS::CertificateManager::Certificate`
`CDK default`	`You`	For newly created certificates, specify `validation` with `CertificateValidation.fromDns()` or `fromDnsMultiZone()`.	`Documentation only`: The default is `fromEmail()`	`CertificateProps`, `CertificateValidation`

8. Where HTTP Validation Applies

What's New lists HTTP validation alongside DNS validation. This section shows where HTTP validation applies, as each source words it. HTTP validation was announced in the April 28, 2025 What's New post (Automated HTTP validated public certificates with Amazon CloudFront).

8.1 How Each Source Words It

What's New states AWS's recommendation in the following sentence. The two periods at the end are as published.

We recommend DNS validation for new certificates, and HTTP validation for Amazon CloudFront distributions..

Four sources describe the scope of HTTP validation differently.

What's New: In the recommendation above, names HTTP validation for Amazon CloudFront distributions.
Security Blog: In the HTTP validation for CloudFront item, states This method is only available for certificates used with Amazon CloudFront.
User guide, domain validation entry page: States HTTP validation is available for certificates used with CloudFront.
User guide, HTTP validation page: In a note on the procedure, states HTTP validation is available only through the CloudFront Distribution Tenants feature.

The fourth note narrows the scope to use through the CloudFront Distribution Tenants feature. The "Request certificates for your CloudFront distribution tenant" page in the CloudFront Developer Guide also mentions that when requesting managed certificates with Distribution Tenants, you can choose who delivers the HTTP validation token. This article does not side with any of the four wordings (see Section 9.1).

8.2 Wildcard Certificates

The HTTP validation page of the user guide states the following as an Important note:

HTTP validation does not support wildcard domain certificates (such as *.example.com). For wildcard certificates, you must use either DNS validation or email validation instead.

The first sentence clarifies that HTTP validation does not support certificates for wildcard domains. The second sentence indicates that email validation is an available option when using wildcard certificates. After March 31, 2027, ACM will no longer offer email validation for new requests (see Section 4.2). As of October 12, 2026, the second sentence does not reflect that schedule (see Section 9.1).

8.3 Can Existing Certificates Be Switched to HTTP Validation?

The list of values for CertificateOptions' ValidationMethod includes HTTP. However, no statement was found in the sources read on October 12, 2026, that existing email-validated certificates can be switched to HTTP validation. The statements about switching in What's New and the Security Blog all describe switching from email to DNS validation (see Sections 5.7 and 9.2).

9. Where the Sources Disagree and Where No Statement Was Found

This section brings together the disagreements between sources and the statements not found that Sections 4 through 8 touched on. Both sides are AWS sources, and this article does not call either one wrong. The verification date for all of them is October 12, 2026.

9.1 Where the Sources Disagree

The following two tables list where the sources disagree. The first table covers whether the switch is possible and the state of the user guide.

#	Topic	One Source Says	Another Source Says	Source Date	Section
1	Can you switch from email validation to DNS validation?	The Security Blog, What's New, and API/CLI references (specifically `UpdateCertificateOptions`, `CertificateOptions`, and `ListCertificateDomainValidations`) state that the switch is possible.	The user guide, across four pages (email validation, DNS validation, troubleshooting email validation, and the entry point for domain validation), indicates that you cannot switch to DNS validation after creation; you must delete and recreate. The FAQ answers "No" to the same question. An article in the re:Post Knowledge Center states that the validation method cannot be changed after the request is submitted.	Security Blog 2026-08-13, What's New 2026-08-13, user guide and FAQ (checked 2026-10-12), Knowledge Center 2023-11-30	Section 5
2	Migration page	What's New and the API and CLI references point to the "Migrate from email to DNS validation" page in the user guide. The Security Blog points to a different page in the user guide.	Both pages redirect to the top page of the user guide.	What's New 2026-08-13, Security Blog 2026-08-13 (checked 2026-10-12)	Section 9.2
3	Record of changes to the user guide	What's New and the Security Blog announced the switch on August 13, 2026.	The user guide's "Document history" does not include an entry for this switch. The most recent entry is dated September 28, 2026.	What's New 2026-08-13, Document history (checked 2026-10-12)	Section 1.3
4	User guide still points to email validation	The Security Blog and What's New state that, as of March 31, 2027, email validation will no longer be offered for new requests.	The user guide contains four instances of text pointing to email validation across three pages. The entry page for domain validation and the DNS validation page say to use email validation if you cannot edit DNS. The DNS validation page recommends email validation if more than five CNAMEs are chained. The HTTP validation page says to use either DNS or email validation for wildcard certificates.	Security Blog 2026-08-13, What's New 2026-08-13, user guide (checked 2026-10-12)	Section 8.2
5	Operations that can use `acm:ValidationMethod`	The user guide's table of condition keys lists only `RequestCertificate`.	The Service Authorization Reference lists both `RequestCertificate` and `UpdateCertificateOptions`.	Both checked 2026-10-12	Section 7.1
6	Can you change `Export` after creation?	The API reference for `CertificateOptions` states that the `Export` value cannot be changed after creation.	The API reference for `UpdateCertificateOptions` states that this operation allows you to specify whether to export the certificate. The introduction of the `CertificateOptions` page itself also says that the structure can be used to `specify whether to export your certificate`.	Both checked 2026-10-12	Section 5.1

Item 1 also holds for the PDF of the user guide dated October 10, 2026 (390 pages). In this PDF, the statement that the switch is not possible appears in four places, with the term ListCertificateDomainValidations appearing zero times, and the term UpdateCertificateOptions appearing only once in the "Quotas" table.

Item 6 is the same disagreement as item 8 in Section 10.1 of How AWS Certificate Manager Issues Public Certificates, a companion article. The original text of CertificateOptions is You cannot update the value of Export after the the certificate is created., and the the is as published.

The second table covers disagreements in wording in the announcements and in the scope of HTTP validation.

#	Topic	One Source Says	Another Source Says	Source Date	Section
7	Certificates after March 15, 2028	The Security Blog's Background paragraph states that after that date, browsers will not trust email-validated certificates.	The same Security Blog's schedule entry states that certificates issued before that date will remain valid until their expiration date.	Security Blog 2026-08-13	Section 4.5
8	What ends on September 30, 2027	The Security Blog's introductory paragraph states that ACM will end support for email-validated public certificates by that date.	The same Security Blog's schedule entry states that ACM will not renew existing certificates from that date forward.	Security Blog 2026-08-13	Section 4.3
9	Sentences giving a one-year migration period	The Security Blog gives a one-year migration period in both its introductory and Background paragraphs.	By this article's calculation, the period from September 30, 2027, to March 15, 2028, is 167 days, while the period from the announcement to September 30, 2027, is 413 days. The Security Blog does not specify which date the one-year period is calculated from.	Security Blog 2026-08-13	Section 4.6
10	Scope of HTTP validation	What's New recommends HTTP validation for Amazon CloudFront distributions. The Security Blog states that it is only available for certificates used with CloudFront. The user guide's entry page states that it is available for certificates used with CloudFront.	A note on the user guide's HTTP validation page states that it is available only through the CloudFront Distribution Tenants feature.	What's New 2026-08-13, Security Blog 2026-08-13, user guide (checked 2026-10-12)	Section 8.1
11	Documents listing dates	The Security Blog lists four dates: January 1, 2027; March 31, 2027; September 30, 2027; and March 15, 2028.	What's New lists March 31, 2027; September 30, 2027; and March 15, 2028, but does not list January 1, 2027. The user guide and the FAQ do not state the schedule for the end of email validation.	Security Blog 2026-08-13, What's New 2026-08-13, user guide and FAQ (checked 2026-10-12)	Section 4.1

9.2 Where No Statement Was Found

The following table lists statements that could not be found as of October 12, 2026, along with the locations and terms searched for. The inability to find a description does not necessarily mean that the behavior it describes does not exist.

What Was Looked For	Where and How It Was Looked For	Result
Behavior when passing `HTTP` to `UpdateCertificateOptions`	Searched the API reference, CLI reference, user guide, Security Blog, What's New, and FAQ using combinations of `HTTP`, `migrat`, and `switch`.	Not found. Only the list of values of `CertificateOptions` includes `HTTP`.
Conditions under which an `InvalidStateException` is returned	Searched the `UpdateCertificateOptions` API reference and all other retrieved pages for `InvalidStateException`.	Not found. The only description found was `Processing has reached an invalid state.`
Handling of a renewal that falls due during the 72-hour switch window	Searched the Security Blog, What's New, the renewal pages in the user guide, and API reference using combinations of `72` and `renew`.	Not found.
`ValidationStatus` and the `Status` of `UpdateSummary` after the 72-hour switch window	Searched the API references for `ListCertificateDomainValidations`, `DomainValidationSummary`, `ValidationConfiguration`, and `UpdateSummary`, using `FAILED`, `72`, and `elapse`.	Not found. While the value `FAILED` exists, there is no mention of its relationship to the 72-hour timeframe.
`DomainValidationOptions` after switching and the values of the search results' `ValidationMethod`	Searched the API references for `CertificateDetail`, `DomainValidation`, and `AcmCertificateMetadata`, as well as the CLI reference, using `initial`, `migrat`, and `update`.	Not found.
The operation to call when retrying after the 72 hours	Searched the Security Blog, What's New, and API reference using `retry` and `again`.	Not found. The Security Blog only states `you can retry when ready`.
Handling of previously issued email-validated certificates after September 30, 2027	Searched the Security Blog, What's New, user guide, and FAQ using `September 30, 2027` and `2027`.	Not found. The September 30, 2027 entry only states that ACM will no longer renew them.
Which Regions the new AWS Regions in the January 1, 2027 entry refers to	Searched the Security Blog, What's New, and the user guide using `new AWS Regions` and `Region`.	Not found.
EventBridge and AWS Health events specific to the end of email validation	Searched the EventBridge page in the user guide and the page on renewal for email-validated domains.	Not found. Events related to renewal failures are sent starting 30 days before expiration (Section 3.2).
Actions invoked when changing the `ValidationMethod` in CloudFormation	Searched the reference for `AWS::CertificateManager::Certificate` using `UpdateCertificateOptions`.	Not found. Only the description for `CertificateTransparencyLoggingPreference` mentions calling `UpdateCertificateOptions`.
Default method when omitting `ValidationMethod` in `RequestCertificate`	Searched the API and CLI references for `RequestCertificate` using `default` and `email`.	Not found in the API and CLI references. The default `EMAIL` of the condition key in the Service Authorization Reference and the CloudFormation default are documented.
Which Baseline Requirements method ACM email validation corresponds to	Searched all retrieved AWS pages using `3.2.2.4`.	Not found.
Key types detected by the script in the Security Blog	Searched the entire Security Blog using `ECDSA`, `key`, and `RSA`.	Not found (the inference in Section 6.2).
Migration page in the user guide	Retrieved pages linked from What's New, API reference, and the Security Blog, as well as pages with similar names.	All six URLs redirected to the top page of the user guide.

9.3 What Changes When the User Guide Is Updated

Items 1 through 4 in Section 9.1 and the last row of Section 9.2 depend on the state of the user guide. These statements will change when the user guide is updated to reflect the announcements. At the time you read this article, the following pages need to be reread.

Notes on the following four pages in the user guide: AWS Certificate Manager email validation, AWS Certificate Manager DNS validation, Troubleshoot email validation problems, and Validate domain ownership for AWS Certificate Manager public certificates.
The Important note on the AWS Certificate Manager HTTP validation page in the user guide.
The Migrate from email to DNS validation page (email-to-dns-migration.html) in the user guide.
Document history in the user guide.
The question regarding the conversion from email validation to DNS validation in the ACM FAQ.

10. Frequently Asked Questions about Moving ACM Off Email Validation

This section answers, within the scope of this article, questions that come up when taking stock of email-validated certificates or switching them.

Q1. Will email-validated certificates stop working on September 30, 2027?

The Security Blog's schedule entry states that ACM will stop renewing existing email-validated certificates on September 30, 2027. It does not state that the certificates stop working on that date. The introductory paragraph of the same Security Blog words this date as discontinue support for email-validated public certificates by September 30, 2027 (Section 4.3). The entry does not address the handling of previously issued certificates after September 30, 2027. The FAQ gives a maximum lifetime of less than 100 days for public TLS certificates issued as of March 15, 2027, but no source was found that states the exact validity period of a certificate renewed just before September 30, 2027 (Section 4.3).

Q2. When switching to DNS validation, is it necessary to reattach the certificate to load balancers or CloudFront?

According to the Security Blog and What's New, the ARN (Amazon Resource Name) of the certificate will not change, and it will not be necessary to modify any AWS resources that reference the certificate (see Section 5.4).

Q3. What happens if the CNAME records are not added within the 72-hour switch window?

If the CNAME records are not added within the 72-hour switch window, according to the Security Blog, the certificate remains valid on email validation, and the user can retry when ready. For new certificates, ACM changes the status to Validation timed out after 72 hours. For the switch, the Security Blog does not say that the status changes to Validation timed out. The sources do not say what ListCertificateDomainValidations and UpdateSummary show after those 72 hours (Sections 5.3 and 5.7).

Q4. The user guide states that the switch is not possible. Which source should I read?

As of October 12, 2026, four pages of the user guide and the FAQ indicate that the switch is not possible. The Security Blog, What's New, the API reference, and the CLI reference state that the switch is possible using UpdateCertificateOptions. The migration page of the user guide that the announcement points to redirects to the user guide's top page. This article does not state that either set of information is incorrect. Both the announcement (August 13, 2026) and the API reference describe the switch, but the Document history of the user guide does not yet reflect that change (see Section 9.1, items 1 through 3).

Q5. My CloudFormation template does not specify ValidationMethod. Is it email validation?

The CloudFormation reference states that when a ValidationMethod is not specified, the default is email validation. Similarly, the AWS CDK's CertificateProps also defaults the validation property to CertificateValidation.fromEmail() (see Sections 7.2 and 7.3). Certificates that rely on this default in a template are created with email validation.

Q6. Can a certificate be switched from email validation to HTTP validation?

The list of values for the ValidationMethod of CertificateOptions includes HTTP. However, no statement was found that a switch to HTTP validation is possible. The sources word the scope of HTTP validation differently. The user guide's page on HTTP validation states that it is available only through the CloudFront Distribution Tenants feature and does not support wildcard certificates (Section 8).

Q7. How do I find email-validated certificates in all Regions?

ACM certificates are regional resources. Use the console filtering, the Security Blog script, and the ValidationMethod filtering within SearchCertificates to find them for each Region. The Security Blog script examines one Region per execution (see Section 6).

Q8. How can an organization keep new certificates off email validation?

Example 1 in the user guide denies acm:RequestCertificate when acm:ValidationMethod is EMAIL, except for requests from a specific role. The Service Authorization Reference gives EMAIL as the value of the condition key when the request has no validation method. In addition, the CloudFormation and CDK defaults are email validation, and a template avoids them by specifying the method explicitly (see Section 7).

Q9. When was this information verified?

The date is October 12, 2026. When the user guide reflects the announcements, items 1 through 4 in Section 9.1 and the last row of Section 9.2 will change (Section 9.3).

11. Summary

The four dates stop different things: ACM stops offering email validation in new Regions on January 1, 2027, stops offering it for new requests on March 31, 2027, and stops renewing email-validated certificates on September 30, 2027. March 15, 2028 is the date that the CA/Browser Forum set for CAs. Among the sources read, only the Security Blog mentions the January 1, 2027 date.
September 30, 2027 is the date the schedule entry gives for ACM to stop renewing: The schedule entry of the Security Blog states that ACM will no longer renew existing email-validated certificates, and does not address how certificates already issued are handled. The introductory paragraph of the same blog words this date as the end of support (Section 4.3).
The user starts the switch: The user sets ValidationMethod to DNS with UpdateCertificateOptions and adds the CNAME records that ACM provides to DNS. The ARN remains unchanged. According to the Security Blog, even after the 72-hour switch window passes, the certificate remains valid on email validation.
Two locations to check status: You can view status information by domain using ListCertificateDomainValidations, and in the UpdateSummary of DescribeCertificate. DomainValidationOptions contains information about the initial validation.
Certificates are regional: You can find them by filtering in the console, using the script from the Security Blog, or filtering by ValidationMethod within SearchCertificates.
CloudFormation and CDK default to email validation: In CloudFormation, the ValidationMethod and in CDK, the validation parameter default to email validation unless otherwise specified. New requests that use email validation can be rejected using the IAM condition key acm:ValidationMethod.
The sources disagree: As of October 12, 2026, four pages of the user guide and the FAQ state that the switch is not possible, and the migration page that the announcements point to redirects to the top page of the user guide. This article lists 11 disagreements and 14 statements not found. When the user guide is updated, the pages in Section 9.3 need to be reread.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi