Apple Keeps Hide My Email on icloud.com—but Sign in with Apple Is Moving

A domain name can look like plumbing until it blocks a login. A customer taps Sign in with Apple, your backend—the server-side code behind the app—receives a valid address, and a hard-coded rule rejects it because the text after the @ is new. Nothing feels broken from the customer’s side; the code has mistaken a changing delivery route for a permanent identity.

On August 24, 2026, Apple revised a plan first announced on June 15. New addresses created through Sign in with Apple will be issued on @private.icloud.com later this year instead of @privaterelay.appleid.com. Existing addresses on @privaterelay.appleid.com will keep working and forwarding mail. iCloud+ Hide My Email addresses, however, will remain on @icloud.com, so Apple is no longer moving both features to one shared domain. As of August 25, 2026, the announcement gives no more precise switchover date than later this year. (developer.apple.com)

The planned merger became a split

The practical map now looks like this:

An email alias is an alternate address that points mail toward the same personal inbox. A relay is a forwarding service that receives mail at that alias and passes it along without revealing the destination address to the sender.

Sign in with Apple is an authentication service: it lets someone use an Apple Account to enter an app or website without creating another password. When the person chooses to hide their email, Apple supplies a private relay address. iCloud+ Hide My Email is a separate feature in Apple’s paid cloud subscription, designed for creating aliases while signing up for newsletters, shops, and other services.

The two features share a privacy goal, but they do not represent one universal address system. Apple’s private relay addresses are also scoped to a development team, meaning the same person can receive one address for apps owned by one team and a different address for apps owned by another.

Why one suffix can break a working integration

A domain is the portion of an email address after the @, such as private.icloud.com. Many systems quietly treat that portion as a fixed constant. They may use a regular expression, often called a regex, to check the address; a database field that accepts only a fixed list; or an email service provider rule that filters incoming relay domains.

That creates several failure points:

• A login form may accept @privaterelay.appleid.com but reject @private.icloud.com.
• Account recovery may classify the new address as invalid and refuse to send a reset message.
• A marketing or notification provider may place the new domain outside its approved routing rules.
• Duplicate-account checks may rely on email text instead of the Apple account identifier.

The last problem is the most serious. An email address is a contact route, not a durable identity. Apple’s Sign in with Apple response includes a stable user identifier called sub, which remains unique for a user within your developer team. Store that value as the account key, verify Apple’s identity token on your server, and keep the email address as a separate contact field.

That design also prevents a common mistake: taking an old address and replacing privaterelay.appleid.com with private.icloud.com in the hope of creating its successor. Relay addresses are generated by Apple. Changing the suffix yourself does not create a valid alias, and existing users should not be rewritten merely because a new domain is coming.

A safer domain check

For a system that handles Apple-generated addresses, use exact domain matching rather than a loose suffix check:

const acceptedAppleEmailDomains = new Set([
 'privaterelay.appleid.com',
 'private.icloud.com',
 'icloud.com'
]);

function hasAcceptedAppleDomain(email) {
 if (typeof email!== 'string') return false;

 const value = email.trim;
 const at = value.lastIndexOf('@');

 if (at <= 0 || at === value.length - 1) return false;

 const domain = value.slice(at + 1).toLowerCase;
 return acceptedAppleEmailDomains.has(domain);
}

This snippet demonstrates domain matching, not complete email validation. Production code should use a standards-aware email parser for the full address syntax. Exact matching also avoids accepting a malicious address such as [email protected], which may fool a naive endsWith check.

The icloud.com entry needs some context. A normal Apple mailbox can also use that domain, so the domain alone does not prove that an address came from Hide My Email. In a Sign in with Apple or Hide My Email workflow, combine the domain check with the trusted data supplied by Apple and the correct account flow.

Email delivery is a different problem

Accepting a new address is only half of the integration. You must also make sure your messages can pass through Apple’s private email relay.

Apple requires developers to register the outbound domains, subdomains, or individual sender addresses used for relay mail. Those sources must use SPF, or Sender Policy Framework, which authorizes mail servers through DNS records, and/or DKIM, or DomainKeys Identified Mail, which adds a verifiable signature to messages. Apple recommends using both where possible. The new private.icloud.com domain is the recipient side of the conversation; it is not a sender domain that belongs in your own DNS configuration. (developer.apple.com)

Review the rules at your email service provider—the company that sends messages on your behalf—as well. Update domain-based filters, routing rules, and suppression lists, which are provider-maintained lists of addresses that should not receive mail. Apple’s relay documentation also lists a daily limit of 100 messages per private relay address, including replies, so these addresses are better treated as targeted account communication than as a bulk-mail destination.

A rollout checklist for developers

1. Add private.icloud.com to every Sign in with Apple allowlist, validator, schema, and automated test. Add icloud.com in shared systems that also process iCloud+ Hide My Email addresses.
2. Preserve existing privaterelay.appleid.com addresses. Do not rewrite them or manufacture new aliases by swapping domain names.
3. Use Apple’s stable sub identifier as the account key. Verify identity tokens on the server instead of trusting an email string from the browser.
4. Register all sender domains and addresses with Apple’s private relay service, then check SPF and DKIM from the actual production email provider.
5. Test welcome messages, password resets, security alerts, receipts, and replies with both legacy and new-style addresses. Watch for rejected logins, bounces, and unexpected duplicate accounts.

Apple’s revision is quiet for users but revealing for developers. Existing Sign in with Apple aliases keep forwarding, iCloud+ Hide My Email stays on @icloud.com, and new Sign in with Apple addresses add @private.icloud.com to the mix. Treat email as a route, Apple’s stable identifier as identity, and the relay as an integration that deserves testing.