I’ve watched this scenario play out more times than I can count: you’re trying to create a new AWS account using Control Tower Account Factory, you submit the request with an email address, and you get the error: “The email address supplied for account email is already associated with an AWS account. Please use a different email address.” Now you’re stuck because you know that email was used before but the account is gone or you don’t have access to it. In this post, I’ll show you how to work around this constraint and establish a naming convention that prevents this problem entirely.

The Problem

AWS treats email addresses as globally unique identifiers for root account access. When you create an account, the email you provide becomes the unique root user email for that account. Even after you close or delete an account, AWS reserves that email for 90 days before it can be reused. If you try to create an account with an email that’s in this reserved period, Account Factory rejects the request.

Error Scenario Description
Recently closed account Email was used in an account closed < 90 days ago
Typo in previous attempt Attempted to create account with typo; email still reserved
Service Catalog orphan Failed provisioned product holds onto the email
Account status unknown Email belongs to existing account you’re not aware of
Catch-all email issue Email service uses catch-all; multiple variations map to same inbox

Why Does This Happen?

  • The email was previously used to create a standalone account (even a deleted/closed account — emails are reserved for 90 days) — AWS has a global email registry. When you create an account with an email, that email is permanently associated with that account ID. Even if you delete the account, the email remains reserved for 90 days. You cannot reuse it during this period.
  • The email is already used in a Service Catalog provisioned product that failed but still holds the email — When Account Factory (which uses Service Catalog) attempts to create an account, it reserves the email. If the provisioned product stays in a failed state, the email remains reserved. You need to terminate the failed provisioned product to release the email.
  • Typo in a previous attempt created an account that’s hard to find — If you typo’d an email in a previous account creation attempt and it succeeded (e.g., account@companyy.com instead of account@company.com), that account now exists and the email is reserved indefinitely.
  • Email service uses catch-all (all variations map to same inbox but AWS treats them as unique) — If your domain has a catch-all rule (any email to @company.com goes to the same mailbox), AWS still treats account@company.com and account+test@company.com as separate emails. However, both will work for password resets and email notifications.

The Fix

Work around the email constraint by using email aliases and establishing a company-wide naming convention.

Solution 1: Use Email Aliases

Most email providers (Gmail, Office 365, AWS SES, etc.) support email aliases or plus addressing:

Gmail and similar providers (+ syntax):

  • Primary: platform@company.com
  • Alias 1: platform+prod@company.com
  • Alias 2: platform+staging@company.com
  • Alias 3: platform+dev@company.com

All three emails go to the same inbox, but AWS treats them as unique. When you create accounts, use the alias format.

Office 365 and Microsoft Exchange (dynamic alias):

  • Primary: platform@company.com
  • Alias 1: platform-prod@company.com
  • Alias 2: platform-staging@company.com

You can configure Dynamic Distribution Groups to route these to the same mailbox.

AWS SES (verified email aliases): If using a custom email service, verify multiple variations:

aws ses verify-email-identity \
  --email-address aws-accounts+prod@company.com

Solution 2: Find Orphaned Accounts

If you think an email is reserved but you can’t find the account, search AWS Organizations:

aws organizations list-accounts \
  --output text | grep -i email-pattern

Or search through Service Catalog for failed provisioned products:

aws servicecatalog list-provisioned-products \
  --access-level Account \
  --filter "Key=SearchQuery,Value=Status:ERROR" \
  --output table

If you find a failed provisioned product, terminate it to release the email:

aws servicecatalog terminate-provisioned-product \
  --provisioned-product-id pprod-xxxxx

Solution 3: Establish a Naming Convention

The most reliable solution is to establish a company-wide naming convention that’s consistent and scalable:

Format: aws-{account-purpose}-{environment}@company.com

Examples:

  • aws-billing-management@company.com (management account)
  • aws-audit-logging@company.com (audit/logging account)
  • aws-prod-platform@company.com (production platform account)
  • aws-staging-platform@company.com (staging platform account)
  • aws-dev-team-a@company.com (development account for team A)

Implementation:

  1. Use the email alias approach so all notifications go to a central mailbox (e.g., aws-accounts@company.com).
  2. Document the naming convention in your AWS governance wiki.
  3. Use Account Factory’s naming conventions feature if available (or enforce manually).
  4. When creating accounts via Account Factory, use the standardized format.

Solution 4: Wait 90 Days

If you must reuse an email and it’s within the 90-day reservation period, you have two options:

  1. Wait 90 days for AWS to release the email reservation, then retry.
  2. Use a different email immediately (recommended — use the alias approach above).

How to Run This

  1. If getting the “email already exists” error:
    • First: Check if the email is in use in your AWS Organizations: run aws organizations list-accounts and search.
    • Second: If it’s a Service Catalog orphan, run aws servicecatalog list-provisioned-products and terminate any failed products.
  2. To implement email aliases:
    • Contact your email administrator and request aliases for your account creation emails.
    • Examples: aws-accounts+prod@company.com, aws-accounts+staging@company.com, etc.
  3. To establish a naming convention:
    • Document the format: aws-{purpose}-{environment}@company.com
    • Set up email routing so all variations go to a central AWS governance mailbox.
    • Communicate the convention to all teams creating accounts.
  4. When creating the next account via Account Factory:
    • Use an alias email: aws-accounts+prod@company.com
    • Use the standardized naming format
    • The account creation should succeed.

Is This Safe?

Yes. Using email aliases is safe and recommended by AWS. All email goes to the same mailbox, so you won’t miss any notifications or security alerts. The naming convention is just a best practice — there’s no technical enforcement, so it’s flexible.

Key Takeaway

AWS reserves email addresses even after accounts are deleted. Work around this by using email aliases (like email+alias@company.com), which go to the same inbox but are treated as unique by AWS. Establish a consistent naming convention for all account creation emails to prevent future conflicts.

Have questions or ran into a different Control Tower issue? Connect with me on LinkedIn or X.