6 checks before Sign in with Apple's private.icloud.com switch breaks your signups

Summary. On 15 June 2026 Apple told developers it will issue Sign in with Apple and iCloud+ Hide My Email addresses on one shared domain, private.icloud.com, replacing the two domains those features used before: privaterelay.appleid.com for Sign in with Apple and icloud.com for Hide My Email. Apple's wording was "later this summer", so any signup built after 2019 that hard-codes the old relay domain can start rejecting real users at any point in Q3 2026. Existing addresses on the 2 legacy domains keep forwarding without interruption. The work is small and unglamorous: 6 checks across signup validation, the identity token, account dedupe, Apple's email source registry (capped at 32 sources for individual accounts and 100 for organisations), your email service provider's suppression lists, and your fraud policy. Hide My Email ships with every paid iCloud+ tier, which starts at ₹75/month in India and $0.99/month in the United States for 50 GB, so the population generating these addresses is large and growing. The failure mode is quiet. Nobody files a bug that says "your regex rejected me"; they just leave.

What Apple actually changed

Apple's developer note is short. New addresses for both features move to private.icloud.com, and the old ones keep working:

Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.

That single sentence is why this is easy to ignore and expensive to miss. Nothing breaks for your existing users. It breaks for the next cohort of new signups, on a date Apple did not pin down, in code most teams wrote once and never touched again.

Domain	What issues addresses on it	Status after the 2026 change
privaterelay.appleid.com	Sign in with Apple (legacy)	No new addresses; existing ones keep forwarding
icloud.com	iCloud+ Hide My Email (legacy) and normal iCloud mailboxes	No new relay addresses; still a live consumer mail domain
private.icloud.com	Sign in with Apple and Hide My Email (new)	Receives all newly generated addresses
Custom Email Domain (iCloud+)	User-owned domain routed through iCloud Mail	Unchanged
Real Apple Account address	Users who choose "Share My Email"	Unchanged

Two details in that table matter more than the rest. First, icloud.com was doing double duty: it carried both ordinary consumer mailboxes and Hide My Email aliases, which made relay addresses indistinguishable from a person's everyday inbox. Second, the new domain is a subdomain, which makes a naive endsWith("icloud.com") check pass for private.icloud.com and a naive equality check fail. Whether your code survives depends on which of those two shapes you happened to write.

John Gruber, who writes and publishes Daring Fireball, put the commercial question plainly on 18 June 2026:

The only reason not to accept private.icloud.com email addresses is if you want to do something invasive with users' actual email addresses.

Help Net Security reported the same week that users on Reddit were already worried "that websites could block registrations using Hide My Email addresses issued on the new domain". Some services will. That is a product decision, and check 6 below is about making it deliberately rather than by accident, through a validation rule nobody remembers writing.

Check 1: stop identifying relay addresses by their domain

The domain string is the worst signal available, and it is the one most codebases use. Apple already tells you whether the address is a proxy, in the identity token itself.

The is_private_email claim in the ID token returned by Sign in with Apple carries this. So does email_verified. Both have an implementation quirk that has tripped up backends for years: Apple returns them as either a JSON boolean or a quoted string, so "true" and true are both valid on the wire. A strict boolean parse throws on half the traffic. Apple's developer forums also carry reports that when a user shares a real address rather than a relay one, is_private_email may not be present in the token at all, so treat a missing claim as false rather than as an error.

def is_relay_address(claims: dict) -> bool:
    """Read Apple's claim, not the domain. Handles str/bool and absence."""
    raw = claims.get("is_private_email", False)
    if isinstance(raw, str):
        return raw.strip().lower() == "true"
    return bool(raw)

def is_verified(claims: dict) -> bool:
    raw = claims.get("email_verified", False)
    if isinstance(raw, str):
        return raw.strip().lower() == "true"
    return bool(raw)

Write it once, put it behind a function name, and delete every domain comparison that was standing in for it. Domain lists rot. Apple has now changed the relay domain once, which tells you the odds it changes again are not zero.

Check 2: fix email validation, allowlists and blocklists

Apple's instruction to developers is specific: account systems, email validation logic and allowlists should accept private.icloud.com alongside privaterelay.appleid.com and icloud.com. That means three separate places in most stacks, and they rarely live near each other.

Search your repositories for the literal strings, not the concept. In a typical Node and Python codebase the hits land in a signup validator, a marketing-consent form, an internal admin tool, a WAF or bot rule, and at least one SQL view that somebody wrote for a churn dashboard.

# Run this across every repo, including infra and analytics
rg -n --hidden -g '!node_modules' \
  'privaterelay\.appleid\.com|icloud\.com|appleid' .

Then classify each hit. A validator that adds the new domain is a one-line change. A dashboard that counts "Apple relay users" by domain is quietly wrong from the switch date onward, and will report a cliff in Apple signups that never happened. That second class causes more damage, because someone will act on the chart.

Two rules keep the fix stable. Match on a suffix boundary (.icloud.com with the dot, or an exact equality list), never a bare substring, or notprivate.icloud.com.attacker.example sails through. And keep the legacy domains in the accept list permanently, because Apple confirmed old addresses keep forwarding, which means those users are not going anywhere.

Check 3: make account dedupe key on the subject, not the email

This is where the change turns into support tickets rather than validation errors.

Apple's stable user identifier is the sub claim in the identity token. The email address is not stable, and never was: users can turn off email forwarding, generate a new Hide My Email alias, or move between sharing a real address and a relay one. If your users table treats email as the primary identity key, a user who returns after the domain switch can land in a second account with an empty order history.

The pattern that holds up: store Apple's sub on the user record, index it, and match on it first at every login. Use email only as a secondary hint, and only when the address is verified. When a relay address changes, update it in place against the existing sub instead of creating a row. Server-to-server notifications from Apple carry account changes, including consent revocation and account deletion, and they are the correct source of truth for those events rather than a nightly reconciliation job.

If you already have duplicate rows from years of email-keyed logic, the domain switch is a good forcing function to write the merge tool. It will be needed either way.

Check 4: register every sending source with Apple, or your mail bounces

To reach a user through the relay, your outbound mail has to pass Apple's checks. Apple's account help is explicit that unregistered sources bounce: "If you don't register all the source domains or emails that you use, email sent to the private relay service will result in a bounce message."

Registration lives in Certificates, Identifiers & Profiles, under Services, in the Configure panel for Sign in with Apple for Email Communication. The caps are 32 email sources for an individual enrolment and 100 for an organisation enrolment. Both numbers sound generous until a growth team spins up a fourth subdomain for lifecycle mail.

Authentication path	What has to match exactly	Failure mode if it does not
SPF	Envelope sender (Return-Path) domain matches a registered domain and passes SPF	Relay rejects, message bounces
DKIM	The d= domain in the signature matches the header From: domain, and that domain is registered	Relay rejects even though the mail is signed
ESP-owned envelope sender	You must use DKIM, because the envelope domain belongs to the provider	Silent bounce loop from a working ESP
Unregistered subdomain	help.example.com needs its own registration; example.com does not cover it	New lifecycle stream bounces on day one
Individual source addresses	Each address registered separately when you do not control a mail domain	Transactional mail from a new alias bounces

Apple recommends both SPF and DKIM where possible. If you send through Amazon SES, SendGrid or Mailchimp, the include mechanism in your SPF record authorises their servers:

; SPF for a domain sending through Amazon SES
example.com.  IN TXT  "v=spf1 include:amazonses.com ~all"

; SPF for a domain sending through SendGrid
example.com.  IN TXT  "v=spf1 include:sendgrid.net ~all"

One operational detail worth switching on before the migration rather than after: Apple periodically notifies the Account Holder and team admins when mail from your account fails to deliver through the relay. That notification is disabled by some teams during development and never re-enabled. It is the cheapest bounce alarm you will get.

Check 5: patch suppression lists, routing rules and filters

Apple's note names email service providers directly, asking them to update domain-based filtering, suppression lists and routing rules that enumerate relay domains so that private.icloud.com is included.

Read that as an instruction to your own marketing stack too, because most teams have hand-rolled at least one of these:

• A suppression list that blanket-suppresses privaterelay.appleid.com because someone once decided relay users hurt open rates.
• A routing rule that sends Apple relay traffic through a separate IP pool or a lower-priority stream.
• A deliverability dashboard that segments by recipient domain and will now show a new domain with no history and, briefly, ugly-looking metrics.
• A CRM enrichment step that skips relay addresses, which will start running against addresses it used to skip, or stop skipping ones it should.

None of these throw errors. They change who gets your mail. Give the list an owner and a date, the same way you would treat a certificate rotation.

Check 6: decide your policy on relay addresses on purpose

The uncomfortable part of this change is that private.icloud.com is a clean, unambiguous signal. Before it, a Hide My Email alias on icloud.com looked exactly like a normal iCloud mailbox. Now a merchant can tell them apart with one comparison. That cuts both ways, and it is a decision for the business, not for whoever owns the signup form.

The case for accepting them is straightforward. Sign in with Apple is a first-class login path on iOS, and guideline 4.8 of the App Store Review Guidelines requires an equivalent privacy-preserving login option wherever you offer third-party or social login, with the specific requirement that users can keep their email address private during account setup. Since January 2024 that option does not have to be Apple's own service, but the privacy properties are non-negotiable. Blocking the relay domain in an app that offers Sign in with Apple is close to blocking a login you are obliged to support properly.

The case people actually make for blocking is fraud and abuse: disposable addresses are used for repeat trial signups and promo abuse. That is a real cost, and it deserves a real control rather than a domain block. Device or payment-instrument checks, velocity limits per sub, and one-account-per-payment-method rules all target the behaviour. A domain block targets a privacy preference, and it fails the moment an abuser switches to any other mailbox.

Signal you might use	What it actually measures	Recommended use
Recipient domain string	The user's mail provider preference	Never for abuse; accept-list only
is_private_email claim	Whether Apple is proxying the address	Analytics and support messaging
Apple sub claim	The durable account identity	Dedupe, rate limits, abuse velocity
Payment instrument reuse	Repeat trial abuse	Trial and promo controls
Device and IP velocity	Automated signup pressure	Bot and abuse defence

Whichever way you land, write the decision down. The worst outcome is a block that exists because a regex from 2021 never got a second look.

The 30-minute audit

Run these in order. Most teams find between two and five hits.

1. Grep every repo, plus infrastructure and analytics code, for privaterelay.appleid.com, icloud.com and appleid.
2. Replace domain-based relay detection with the is_private_email claim, handling both string and boolean forms.
3. Confirm the users table has an indexed column for Apple's sub and that login matches on it before email.
4. Open Certificates, Identifiers & Profiles and reconcile the registered email sources against every domain and subdomain your systems actually send from.
5. Confirm SPF or DKIM alignment for each of those sources, and re-enable Apple's private relay delivery notifications.
6. Search your ESP for suppression, routing and segmentation rules that name a relay domain, and add the new one.
7. Add private.icloud.com to your signup test fixtures so a regression cannot reintroduce the block.

Step 7 is the one that keeps the fix alive. Everything else is a point-in-time change that the next refactor can undo.

India-specific considerations

Hide My Email is bundled with every paid iCloud+ tier, and India is among the cheaper storefronts: ₹75/month for 50 GB, ₹219/month for 200 GB and ₹749/month for 2 TB, against $0.99, $2.99 and $9.99 in the United States as published by Apple on 7 April 2026. iCloud gives 5 GB free, so the upgrade to a relay-capable plan costs less than a coffee. For consumer apps with large iPhone user bases in metros, the share of signups arriving on a relay address is not a rounding error.

Two India-specific points follow. First, the Digital Personal Data Protection Act 2023 makes an email address personal data whether or not it is a proxy, so a relay address sits inside the same notice, purpose-limitation and erasure obligations as any other contact field. A relay address is not an anonymisation strategy and should not be treated as one in your records of processing. Teams building this properly usually do it alongside the rest of their consent plumbing, which we cover in the DPDP engineering playbook for Indian startups.

Second, deliverability. Indian teams frequently send transactional mail from one provider and marketing mail from another, often with a separate subdomain for each, and sometimes with a third stack for WhatsApp and SMS fallbacks. Every one of those mail subdomains needs its own registration with Apple. The 32-source cap on individual developer enrolments is easy to hit in that setup, which is a practical argument for enrolling as an organisation.

What this change does not do

It does not deprecate anything. It does not require an app update, an SDK bump or a resubmission. It does not affect Sign in with Apple on the web differently from native apps. It does not change the relay's authentication rules, which have required registered sources with SPF or DKIM since the service launched. And it does not migrate anyone: existing addresses stay on their old domains and keep forwarding.

What it does is remove a piece of accidental camouflage and expose which parts of your stack were relying on a hard-coded string. The real cost here is rarely the code change. It is finding all six places.

FAQ

What changed with Sign in with Apple email addresses in 2026?

Apple announced on 15 June 2026 that Sign in with Apple and iCloud+ Hide My Email will issue new addresses on one shared domain, private.icloud.com. Sign in with Apple previously used privaterelay.appleid.com and Hide My Email used icloud.com. Apple said the rollout happens later in the summer of 2026.

Do existing relay addresses stop working?

No. Apple stated that existing addresses on the legacy domains continue to work and forward mail to users without interruption. Only newly generated addresses use private.icloud.com. Keep privaterelay.appleid.com and icloud.com in your accept lists permanently, because the users holding those addresses remain active accounts.

How should my backend detect a relay address?

Read the is_private_email claim from the identity token rather than comparing the domain. Apple returns that claim, and email_verified, as either a JSON boolean or a quoted string, so parse both forms. Treat a missing is_private_email claim as false, which happens when a user shares their real address instead.

Why does my email to relay users bounce?

Apple's private email relay only accepts mail from registered sources. Every sending domain and subdomain must be registered in Certificates, Identifiers & Profiles and pass SPF or DKIM. Apple's documentation states that unregistered sources produce a bounce message, and a new lifecycle subdomain is the usual culprit.

How many email sources can I register with Apple?

Individual developer enrolments can register up to 32 email sources, and organisation enrolments up to 100, according to Apple's account help. A source can be a domain, a subdomain or an individual address. Subdomains are not covered by their parent domain and each needs registering separately.

Should we block private.icloud.com signups to stop abuse?

Domain blocking targets a privacy preference rather than abusive behaviour, and guideline 4.8 requires a login option that lets users keep their email private. Velocity limits on Apple's sub claim, payment-instrument reuse checks and device signals address trial and promo abuse without rejecting legitimate customers.

Does the change affect DPDP obligations in India?

A relay address is still personal data under the Digital Personal Data Protection Act 2023, so notice, purpose limitation and erasure duties apply exactly as they do to a normal address. Treating a proxy address as anonymised data in your records of processing is a mistake worth correcting early.

What should our account dedupe key be?

Apple's sub claim is the stable identifier and should be the indexed match key at every login. Email addresses change when users regenerate a Hide My Email alias or switch between sharing a real and a proxy address, so email-keyed logic creates duplicate accounts with empty order histories.

How eCorpIT can help

We build and repair identity, signup and lifecycle-messaging plumbing for iOS and web products, including Sign in with Apple integrations, account dedupe against durable identifiers, and email authentication across SPF and DKIM. Our senior engineering teams work through the audit above as a fixed-scope piece of work, alongside broader passkeys and CIAM identity implementation and iOS and Swift app development engagements. If you want the six checks run against your codebase and your Apple developer account before the switch reaches your users, contact us and we will scope it. For teams planning wider platform work, our enterprise mobile app development guide covers the surrounding decisions.

References

1. New domain for Sign in with Apple and iCloud+ Hide My Email — Apple Developer news, 15 June 2026.
2. Configure private email relay service — Apple Developer account help (source limits, SPF and DKIM rules).
3. Communicating using the private email relay service — Apple Developer documentation.
4. Apple is bringing Hide My Email and Sign in with Apple under one domain — Help Net Security, 17 June 2026.
5. New Domain for Sign In With Apple and iCloud+ Hide My Email — Daring Fireball, 18 June 2026.
6. iCloud+ plans and pricing — Apple Support (India), published 7 April 2026.
7. How to use Hide My Email with Sign in with Apple — Apple Support.
8. App Store Review Guidelines — Apple Developer (guideline 4.8, Login Services).
9. Apple (sort of) removes its requirement that apps offer Sign in with Apple support — 9to5Mac, January 2024.
10. Missing is_private_email claim in ID Token for Hide My Email users — Apple Developer Forums.
11. email_verified field in the id_token — Apple Developer Forums.
12. Authenticating for Apple Private Email Relay — Customer.io documentation.
13. Easy DKIM in Amazon SES — AWS documentation.
14. Set up custom domain authentication (DKIM and SPF) — Mailchimp help.

Last updated: 4 August 2026.