Handling Apple "Hide My Email" in Your Login System: Best Practices

Apple’s Hide My Email feature allows users to create randomized relay email addresses (like abcd@privaterelay.appleid.com) when signing up for apps. These relay addresses forward to the user’s real inbox, keeping their primary email private.

While great for privacy, this creates a challenge for app developers:
👉 Should relay emails map to the original account, or should they create entirely new accounts?

Let’s explore the scenarios and best practices.

---

🔹 The Core Problem

When a user interacts with your platform, they might:

1. Sign up with their normal email (e.g., user@gmail.com)

2. Later sign in using Apple’s relay email (e.g., abcd@privaterelay.appleid.com)

3. Or vice versa — start with the relay email and later try logging in with their normal email.

If your system only treats email as the identity key, this results in duplicate accounts, lost history, and poor user experience.

---

🔹 Key to the Solution: Apple’s Unique Identifier (sub)

Apple provides a stable, unique identifier (sub) for each Apple ID.

• This ID remains the same regardless of whether Apple returns a real or relay email.

• You should rely on this sub for identity management, not just the email string.

By mapping accounts to sub, you can unify multiple emails (real + relay) under a single user profile.

---

🔹 Login Scenarios & Best Practices

Case 1: First login with normal email, then login with relay email

• User signs up with user@gmail.com.

• Later logs in with Apple → abcd@privaterelay.appleid.com appears.

• ✅ Since Apple returns the same sub, map relay email to the existing account.

---

Case 2: First login with relay email, then login with normal email

• User signs up with Apple → relay email stored.

• Later tries to log in with user@gmail.com.

Two sub-cases:

1. If login is via Apple OAuth → Apple returns the same sub, so map relay + normal email to the same account.

2. If login is plain email/password → system won’t recognize the link.

   • Solution: Allow account linking via verification.

   • Example: Prompt the user to confirm if they want to merge their Apple account with their normal email account.

---

Case 3: Multiple Relay Emails

Sometimes Apple issues a new relay email for the same Apple ID.

• ✅ Always use the Apple sub as the master identity.

• Treat relay emails as aliases, not new identities.

---

🔹 Recommended Strategy

1. Primary Identity = Apple sub (not email).

2. Support Aliases = Store both real and relay emails under one account.

3. Account Linking Flow = If the user signs in with different methods (relay vs normal email/password), provide a simple merge option.

4. Prevent Duplicates = Avoid creating new accounts just because the email string is different.

---

✅ Conclusion

Apple’s Hide My Email is a win for user privacy, but it requires careful handling on your platform.

By anchoring accounts to Apple’s sub identifier and allowing multiple verified emails per account, you’ll:

• Prevent duplicate accounts

• Provide a seamless login experience

• Reduce customer support overhead

In short: Relay emails should map to the original account, not create new ones.

---

👉 Do you want me to also add a visual flow diagram to this blog so it’s clearer for readers?