Sign in with Apple Signup Enrichment: Handling Private Relay Emails

Sign in with Apple is designed to give you less

Every other OAuth provider in a signup flow is, at minimum, trying to tell you something true about the user. Google hands you a Workspace domain if one exists. GitHub hands you a public profile and an org list. Even Discord, which has no reason to know anything about your company, hands you a verified email address tied to a real inbox.

Sign in with Apple is built around the opposite goal. Apple's entire pitch to users is that the company signing them up doesn't need to see their real email address, doesn't need a stable cross-app identifier, and doesn't need to know anything beyond "this is a real person, verified once, forever." That's a reasonable privacy stance. It also means a chunk of your Apple signups will arrive with an email address engineered specifically to resist the kind of resolution your enrichment pipeline normally does.

If you've already built OAuth enrichment paths for Google, GitHub, or Discord, Apple is the one that breaks the assumptions all three of those share: that an email address, verified or not, points to something resolvable.

What the identity token actually gives you

When a user completes Sign in with Apple, your backend receives a signed JWT (the identity token) plus, on the very first authorization only, a separate authorization payload. Between the two, you get:

• sub: a stable, app-specific user identifier. Not an email, not reusable across your other apps, but consistent for this user and this app forever.
• email: present if you requested the email scope. Either the user's real address or a generated relay address, depending on what they chose at the consent screen.
• email_verified: Apple's confirmation that the address is real and owned by the account, returned as a string rather than a boolean in the raw claim.
• is_private_email: a string flag telling you whether the email field is a relay address rather than the user's real inbox.
• real_user_status: an integer (0 unsupported, 1 unknown, 2 likely real) meant for bot and fraud detection, not identity resolution.
• name: first and last name, included only in the authorization response on the user's first authorization with your app. Apple never sends it again.

That last point catches more engineering teams than it should. If your signup handler doesn't persist the name block the first time it shows up, there's no second chance. The user's name simply stops arriving on every subsequent login.

The private relay breaks domain-based resolution

This is the part that actually changes your enrichment architecture. When is_private_email is true, the address you receive looks like a1b2c3d4e5@privaterelay.appleinc.com. It's a real, working, per-app forwarding address, mail sent to it genuinely reaches the user's inbox, but the domain tells you nothing about the person. It's not a free consumer provider like Gmail, and it's not a company domain. It's Apple's domain, generated for exactly one purpose: routing mail without exposing an identity.

Every other OAuth or email/password signup your product handles eventually sorts into one of two buckets: a company domain you can resolve through firmographic lookup, or a personal domain you run through personal email enrichment. A private relay address is neither. Running it through your normal domain-resolution waterfall wastes an API call confirming that privaterelay.appleinc.com isn't a company, something you can just hardcode as a known non-resolvable domain and skip entirely.

Real user status is a fraud signal, not an identity signal

real_user_status is tempting to treat as a quality score, but Apple's own documentation is explicit that it reflects a point-in-time assessment and isn't guaranteed to stay accurate. Use it the way it's intended: as one input into bot and trial-abuse detection, alongside whatever other signals feed your trial abuse checks, not as a stand-in for company fit or seniority.

Building an enrichment path for Apple signups

The branch you need looks similar to the Google OAuth hd check, but the decision point is different: instead of asking "is this a work domain," you're asking "is this address even real."

1. Branch on is_private_email before anything else

if (profile.is_private_email === "true") {
  // Relay address: skip domain resolution entirely,
  // route straight to behavioral/in-product signals
} else {
  // Real address: run the same path you'd use for any
  // other OAuth or email/password signup
}

A non-relay Apple email still needs the standard split: a company domain goes to firmographic enrichment and teammate discovery, a personal domain goes through your personal email resolution waterfall. Apple doesn't give you a Workspace-style domain hint the way Google does, so even real Apple-provided addresses need the full personal-email treatment unless the domain obviously belongs to a company.

2. Capture the name block on first authorization, permanently

Write given_name and family_name to your database the moment they arrive, before any async enrichment job runs. If your signup flow queues enrichment and only persists the name after that job completes, a slow queue can lose the name entirely if the user's session ends before the write happens. Treat this as a synchronous write in the OAuth callback, not a side effect of a background job.

3. Treat relay addresses as permanently unresolvable by domain, not temporarily unresolved

Don't queue a relay address for a later retry through your domain-resolution pipeline. It will never resolve differently; the domain is fixed and uninformative by design. Score these signups on behavior instead: product usage, in-app actions, time to first value, anything your onboarding personalization already tracks. A relay-email account that activates fast and invites a teammate is a better lead than a real-domain account that never opens the product, regardless of what either email address says.

4. Watch for relay addresses that stop working

Users can disable forwarding for a specific app from their Apple ID settings without telling you. When that happens, mail to the relay address hard-bounces. If your product sends onboarding emails, trial-ending notices, or billing receipts, treat hard bounces from privaterelay.appleinc.com addresses as a signal to prompt an in-app email update, not as a dead lead. The account is still active. The mail path just closed.

5. Feed everything into one scoring model with a resolution-method field

A relay-email signup, a real-Apple-email signup, and a Google Workspace signup should all land in the same ICP scoring pipeline. Keep a field that records how each record was resolved (domain match, personal-email match, behavioral-only) so a sales rep looking at a score of 70 can tell the difference between "confirmed enterprise domain" and "unresolvable email, scored on usage alone." Those are different conversations.

Where this breaks in practice

Don't request more scopes than you need. Apple's consent screen already feels restrictive to users; asking for anything beyond email and name at signup increases the chance they decline the whole login, not just the extra scope.

Don't key any record on email for Apple users. Use sub as the stable identifier. A user can request Apple generate a new relay address at any time, which changes the email on file without changing who they are. If your account lookup relies on matching email strings, a regenerated relay address silently creates a duplicate account instead of updating the existing one.

Don't assume mobile-only. Sign in with Apple also works through a web-based REST flow (Sign in with Apple JS), so a desktop signup on your marketing site can produce the same relay-email pattern as an iOS app signup. Build the branch once, in your shared signup handler, not twice.

Don't skip this because volume looks low. Apple requires Sign in with Apple as an option on any iOS app offering third-party login, which means some products collect relay-email signups purely from App Store compliance rather than user preference. Low volume doesn't mean low value if those signups skew toward exactly the privacy-conscious, security-minded buyers B2B SaaS tools often want.

A rollout checklist

• Branch on is_private_email before running any domain-resolution lookup
• Hardcode privaterelay.appleinc.com as a known non-resolvable domain rather than querying it
• Persist given_name/family_name synchronously in the OAuth callback, since Apple sends them only once
• Use sub as the stable account key, never the email string
• Route relay-email accounts into behavioral and usage-based scoring instead of firmographic scoring
• Treat real_user_status as a fraud-detection input only, not an identity or fit signal
• Monitor hard bounces from relay addresses as a prompt to collect an updated contact method, not as churn
• Feed every resolution path (domain match, personal-email match, behavioral-only) into one ICP scoring model with a resolution-method field attached

Where this fits in a broader signup enrichment stack

Apple signups are a small but structurally different case inside the same PLG signup enrichment system that handles your Google, GitHub, and email/password users. The difference isn't the plumbing, it's the fallback: when the email itself carries no usable signal, behavior and product usage have to carry the weight that domain resolution usually does.

Groful's enrichment engine applies this branch automatically, recognizing private relay domains, persisting one-time profile data where it belongs, and falling back to behavioral and product-led sales signals when email-based resolution has nothing to offer. Compare the approach against Clearbit if you're weighing options, or get in touch if your signup funnel includes Sign in with Apple and you want those accounts scored on something more useful than a domain that was never meant to resolve.