Accept Apple’s New Relay Email Domain
A small email-domain assumption can block account creation. Check the places where your product interprets an Apple relay address.
- Apple’s August 24 notice says new Sign in with Apple relay addresses will use private.icloud.com later in 2026.
- Existing privaterelay.appleid.com addresses will continue to forward mail. iCloud+ Hide My Email addresses remain on icloud.com.
- Apple asks developers to accept the new domain in account systems, email validation and allowlists alongside the old domain.
The announcement is an email-compatibility update. It does not claim a performance improvement. The original notice gives no exact migration date.
Our product inference: a domain-specific check could reject a legitimate account before the person reaches your product. Look beyond the sign-in button to validation, support tools and account linking.
Inspect the account flow for assumptions about relay addresses. Write synthetic cases for both supported domains and record which validation paths you checked. Treat acceptance of an address and delivery of a message as separate checks.
Put it to work 20 minutes
A two-domain account-compatibility checklist
In 20 minutes, map one account flow and write a two-domain validation checklist. Record observed results or mark them untested. Do not send mail to invented addresses.
See a worked example
Illustrative test plan. These synthetic address examples are for local validation only; no delivery test or production result is implied.
- Where the address goes
- Apple sign-in callback → account creation validator → stored contact address → support account lookup.
- The two cases
- [email protected] — accepted by address validation; untested. [email protected] — accepted by address validation; untested.
- Remaining checks
- Account linking and mail delivery remain unverified. Ask the account-flow owner to run a separate check with an authorized real test account.
Your turn
List the account and support paths that read or validate the email.
Use synthetic values in a local test. Keep delivery checks separate.
Name what is still unknown and the person who can verify it.
Your draft stays in this browser. No account needed.
Your validation may already accept both domains. Confirm that before adding special-case logic or changing stored addresses.
Apple’s notice explicitly describes the domains and requested compatibility checks. It does not establish whether your application already handles them.
Do both address domains pass the account checks, and which separate delivery checks remain?
Watch: Validation test results · Account-linking checks · Authorized delivery-test results