Sign in with Apple's New Relay Domain: Backend Risk

Apple is changing the domain used for Sign in with Apple's email relay addresses: later this year, newly created addresses will start being issued under `private.icloud.com` instead of privaterelay.appleid.com, while existing addresses on privaterelay.appleid.com will keep working without interruption. If your backend has a hard-coded single-domain check, regex, or allowlist — a signup form, an email-validation filter, a spam-blocking list — this change can start silently rejecting new users. This post covers what changed, which announcement landed on which date, and how to make your backend unbreakable.

💡 Pro Tip: Design the domain check as a list of suffixes instead of a single string comparison — when Apple adds a new relay domain (which is exactly what it just announced), you add a list entry, not a line of code.

Table of Contents

• What changed, and when it was announced
• The silent-breakage scenario: allowlists, regex, and email validation
• Single-domain validation in the signup form
• Spam/relay blocking rules
• Suppression lists / routing rules on the ESP side
• Validation code that accepts both domains
• Backend: domain list + regex (TypeScript)
• Matching both in a single regex
• On the Swift side: tagging incoming email by source
• A reminder about sending email to relay addresses and sender registration
• The same-user, different-domain account-merging trap
• Sandbox and real-device test plan
• Migration checklist
• FAQ
• What is Sign in with Apple's new relay domain?
• How should email validation/allowlist code be updated?
• Do old relay addresses keep working?
• Is Hide My Email also moving to private.icloud.com?
• When will the transition be complete?
• Conclusion
• Sources

What changed, and when it was announced

Apple made two separate announcements on this, and the difference between them is the most critical point in this article.

June 15, 2026 — In the first announcement published on Apple Developer News, the plan was this: the email domains used for Sign in with Apple and iCloud+ Hide My Email would be merged into one shared domain (private.icloud.com). The same day, MacRumors and 9to5Mac both covered the news.

This announcement quickly drew community pushback. According to MacRumors' report dated June 17, 2026, X user @vxdb pointed out that a single shared domain created a privacy risk: platforms could now block just this new subdomain (i.e., Hide My Email aliases) wholesale, without affecting all iCloud users.

August 24, 2026 — Apple revised the plan based on this feedback. The new decision: only Sign in with Apple addresses will move to private.icloud.com; iCloud+ Hide My Email addresses will stay on `icloud.com`. A notice has since been added to June's original announcement page: "Note: This announcement contains outdated information."

There are two official sources here with different scope, and you need to know both. Apple's Sign in with Apple documentation states that relay addresses end in @private.icloud.com, @privaterelay.appleid.com, or @icloud.com. The August 24, 2026 migration guidance, on the other hand, names only private.icloud.com and privaterelay.appleid.com; Hide My Email addresses stay on icloud.com. In other words, the work you're asked to do for the migration is defined across two domains, but you need to measure — not assume — whether icloud.com shows up as a relay address in your own data.

Apple hasn't given an exact date for the transition yet — the announcement text says "later this year." As of September 8, 2026, when this post was published, official sources have no confirmed activation date or go-live confirmation. So prepare now and keep watching Apple Developer News for the actual start.

The silent-breakage scenario: allowlists, regex, and email validation

Apple's official call is clear: "Developers ... should ensure that their account systems, email validation logic, and allowlists accept addresses on the new private.icloud.com domain in addition to the existing privaterelay.appleid.com domain." So the task is to add the new domain, not to replace the existing one.

There are typically three ways this breakage shows up silently:

Single-domain validation in the signup form

A common pattern in filters like "we only accept corporate email" or "valid email domain" is to whitelist specific suffixes. If the new relay addresses ([email protected]) aren't on that list, the form silently rejects the user — the error message says "invalid email," but the real cause is a forgotten domain update.

Spam/relay blocking rules

The community warning MacRumors covered belonged to the June plan: if Hide My Email had also moved to the same subdomain, platforms could have blocked iCloud aliases wholesale by blocking just that subdomain. After the August 24 revision, only Sign in with Apple addresses live under private.icloud.com. Today's risk: if your backend lumps relay domains into a generic "suspicious email" category, it may misclassify these addresses since it doesn't recognize private.icloud.com.

Suppression lists / routing rules on the ESP side

In the June 15 announcement, Apple also spoke directly to email service providers: anywhere domain-based filtering, suppression lists, or routing rules enumerated domains, the new domain needed adding there too. This paragraph wasn't repeated in the August 24 update. The call wasn't addressed only to your backend — your ESP's (Postmark, SendGrid, Resend, etc.) configuration was on the list too.

Here's a table summarizing which feature each domain belongs to and how you should treat it in your backend:

Validation code that accepts both domains

The rule is simple: bind the domain check to a list or a regex alternation, not a single string equality. Below are examples at three different layers (backend regex, TypeScript allowlist, Swift client-side).

Backend: domain list + regex (TypeScript)

1const appleSignInRelayDomains = [
2  "privaterelay.appleid.com",
3  "private.icloud.com",
4] as const;
5 
6function isAppleSignInRelayEmail(email: string): boolean {
7  const domain = email.split("@")[1]?.toLowerCase();
8  if (!domain) return false;
9  return appleSignInRelayDomains.includes(
10    domain as (typeof appleSignInRelayDomains)[number],
11  );
12}
13 
14// Signup form validation: don't reject the relay address, just tag it.
15function classifyEmailSource(email: string): "apple_relay" | "direct" {
16  return isAppleSignInRelayEmail(email) ? "apple_relay" : "direct";
17}

Note: the August 24 guidance does not require you to add icloud.com to this list; the migration is defined only in terms of the two Sign in with Apple domains. However, Apple's relay documentation does count @icloud.com as one of the relay address suffixes — so before excluding it from the list, verify in your own signup data whether Sign in with Apple addresses with this suffix exist.

Matching both in a single regex

In some systems (log scanning, ESP rules, WAF filters), a regex can be more practical than a list:

1# An alternation that catches both relay domains
2grep -E "@(privaterelay\.appleid\.com|private\.icloud\.com)$" access.log

On the Swift side: tagging incoming email by source

1enum EmailRelaySource {
2    case appleSignIn
3    case hideMyEmail
4    case direct
5}
6 
7func classifyRelaySource(email: String) -> EmailRelaySource {
8    let domain = email.split(separator: "@").last?.lowercased() ?? ""
9    let signInDomains: Set<Substring> = [
10        "privaterelay.appleid.com",
11        "private.icloud.com",
12    ]
13    if signInDomains.contains(Substring(domain)) {
14        return .appleSignIn
15    }
16    // Note: icloud.com can be both Hide My Email and — per Apple's relay
17    // docs — a Sign in with Apple relay suffix; verify in your own data.
18    if domain == "icloud.com" {
19        return .hideMyEmail
20    }
21    return .direct
22}

What's common across all three examples is the same idea: the domain check is an expandable set, not a single fixed value. If Apple adds a third domain tomorrow (which is theoretically possible during this transition), all you need to do is add one line to the set.

A reminder about sending email to relay addresses and sender registration

Independent of the domain change, two long-standing rules still apply, and forgetting them also causes breakage:

• Sender registration is mandatory: according to Apple's official documentation, to send email to a relay address you need to register your outbound emails or email domains and verify them with SPF (Sender Policy Framework). This step doesn't change with the domain — without registration, the email never reaches the user.
• Daily limit of 100 emails: each private relay address has a daily limit of 100 emails, counting both what the developer sends and the user's replies. Systems that send bulk notifications (password resets, campaign emails) can easily overlook this limit in test scenarios.

A detail that's often confused: the [email protected] → sales_at_example_com_<something>@icloud.com example in Apple's documentation shows the human-readable form of your sender address, not the user's relay address. This example isn't about the Sign in with Apple relay domain migration at all; the <something> in it is a placeholder, not a value to copy verbatim.

The same-user, different-domain account-merging trap

Apple's relay identity architecture has one fixed rule: the same user's relay address stays identical across every app written by a single developer team, while different developer teams' apps get different addresses. This logic is unaffected by the domain change.

But there's a real risk here: Apple's guarantee is that "existing addresses will keep working without interruption" — meaning an existing relay address doesn't change domain. Only newly generated addresses' domain changes. The problem arises when a backend maps a user to a primary key by the exact string of the email address: with two relay domains living in parallel, using email as the identity key structurally risks seeing the same person as two separate records.

The correct approach: store, as the primary identity, not the email itself but the user identifier Apple provides in the Sign in with Apple flow. Apple's documentation describes the user field on ASAuthorizationAppleIDCredential as "an identifier for the authenticated user." The client passes this value to your backend, which maps the user by it. Email should be kept only as a contact channel, not as the identity key.

1type AppleUser = {
2  appleUserId: string;
3  appleEmail: string;
4};
5 
6interface UserRepository {
7  findByAppleEmail(email: string): Promise<AppleUser | null>;
8  findByAppleUserId(appleUserId: string): Promise<AppleUser | null>;
9  updateEmail(appleUserId: string, appleEmail: string): Promise<void>;
10}
11 
12// Wrong: if the email domain changes, user matching breaks
13export async function findUserByAppleEmail(
14  repo: UserRepository,
15  email: string,
16) {
17  return repo.findByAppleEmail(email);
18}
19 
20// Right: Apple's user identifier is the primary key
21export async function findUserByAppleUserId(
22  repo: UserRepository,
23  appleUserId: string,
24) {
25  return repo.findByAppleUserId(appleUserId);
26}
27 
28// Email is kept in sync only as the current contact channel
29export async function syncAppleContactEmail(
30  repo: UserRepository,
31  appleUserId: string,
32  currentEmail: string,
33) {
34  await repo.updateEmail(appleUserId, currentEmail);
35}

Sandbox and real-device test plan

The transition isn't live yet — the announcement says "later this year," and as of September 8, 2026 there's no activation confirmation in official sources. So right now it's not possible to test in the sandbox or on a real device whether a private.icloud.com address gets generated.

Instead, prepare your code with a domain-agnostic design rather than a speculative test step: apply the list/regex approach above today, run existing tests with both privaterelay.appleid.com and private.icloud.com sample addresses (simulating the second in your own test fixtures rather than obtaining it from Apple), and keep watching Apple Developer News to run real verification once the date is confirmed.

Migration checklist

The list below is compiled from Apple's official recommendations and the risks covered in this article:

• Update your allowlist/regex: add private.icloud.com, never remove privaterelay.appleid.com — Apple says existing addresses will keep working without interruption, so the two will coexist.
• Preserve the feature separation: don't mix Hide My Email (icloud.com) and Sign in with Apple relay domains in the same allowlist logic anymore; they now have different fates.
• Review your ESP rules: make the domain enumerations in suppression lists, spam filters, and routing rules domain-agnostic.
• Verify SPF/sender registration: if you send email to relay addresses, outbound domain registration and SPF verification are still mandatory; include the daily 100-email limit in your test scenarios.
• Fix your user-matching logic: use Apple's provided user identifier (user) as the primary key instead of email.
• Keep watching Apple Developer News: follow the id=1ptvdtcm page until the exact transition date is confirmed; this article will get an update once activation is confirmed.

Here's a table summarizing who should act with what urgency, in priority order:

FAQ

What is Sign in with Apple's new relay domain?

According to Apple's official announcement dated August 24, 2026, newly created Sign in with Apple email addresses will be issued later this year under `private.icloud.com` instead of privaterelay.appleid.com. This is a revised, narrower version of a broader plan announced in June 2026 that had also proposed moving Hide My Email to the same domain.

How should email validation/allowlist code be updated?

Apple's official recommendation is that account systems, email validation logic, and allowlists be updated to accept both the old (privaterelay.appleid.com) and new (private.icloud.com) domains. In practice, this means turning a hard-coded single-domain comparison into a suffix list or regex alternation; on the ESP side, the call to update domain-based filtering and suppression-list rules was made in the June 15 announcement.

Do old relay addresses keep working?

Yes. Apple states explicitly that existing addresses on privaterelay.appleid.com will keep working and forwarding email without interruption. The change only affects newly created addresses; there is no retroactive domain cancellation or forced migration.

Is Hide My Email also moving to private.icloud.com?

No. Apple walked this part back in the August 24, 2026 update: iCloud+ Hide My Email addresses will stay on the icloud.com domain. Only newly generated Sign in with Apple relay addresses are moving to private.icloud.com. If you read the original June announcement, you need to update this distinction.

When will the transition be complete?

Apple hasn't given an exact date yet; the announcement text says "later this year." As of September 8, 2026, there's no confirmed activation date or go-live confirmation in official sources. You're advised to keep watching the Apple Developer News page for updates.

Conclusion

What's technically required for this transition is simple: expand the domain check from a single fixed value to a list. The real risk is conflating the scope difference between Apple's two announcements (June's broad plan vs. August's narrowed version) and attaching the wrong domain to the wrong feature. If you make your backend domain-agnostic now, it won't matter when the exact transition date gets confirmed — it won't be a surprise for you.

If you want to review other security surfaces of your Sign in with Apple integration, check out the iOS Keychain Security guide, the iOS Security Best Practices post for general authentication hardening, and iOS Network Security Advanced for network-layer security. On user tracking and privacy compliance, iOS Privacy Compliance ATT and iOS Privacy Manifests are complementary reads.

Sources

• Apple Developer News — Update: New domain for Sign in with Apple — official update dated August 24, 2026; announces that the new domain is private.icloud.com and that Hide My Email will stay on icloud.com.
• Apple Developer News — New domain for Sign in with Apple and iCloud+ Hide My Email — the original announcement dated June 15, 2026 (now marked "outdated").
• Apple Developer Documentation — Communicating using the private email relay service — details on SPF, sender registration, and the daily 100-email limit.
• Apple Developer Documentation — ASAuthorizationAppleIDCredential.user — the identifier field provided for the authenticated user.
• MacRumors — Apple to Unify Sign in With Apple and Hide My Email on One Domain — June 15, 2026 report.
• 9to5Mac — Sign in with Apple and Hide My Email are getting a new shared email domain — June 15, 2026 report.
• MacRumors — Apple's New Hide My Email Domain Makes It Easier to Block iCloud Aliases — June 17, 2026; covers @vxdb's blocking warning.
• AppleInsider — Hide My Email no longer changing domains, will keep iCloud.com — August 24, 2026, details of the revision.
• Daring Fireball — Apple Rethinks Plan to Merge 'Hide My Email' Domain Name With 'Sign In With Apple' — August 24, 2026 commentary.