Sign in with Apple: Hide My Email Forwarder Setup

When a user picks Hide My Email during Sign in with Apple, Apple hands your app a per-app relay address that ends in @privaterelay.appleid.com and quietly forwards it to the person’s real inbox. The setup that makes your email actually arrive is one step people skip: register your sending domains and From addresses in the Apple Developer portal’s private email relay configuration and pass SPF, because until you do, 100% of the messages you send to those relay addresses bounce. The relay registration is a portal and DNS task, while the app-side pieces, the Sign in with Apple button and the account screen that shows the hidden address, are quickest to build from a free VP0 design with Claude Code or Cursor.

What Hide My Email actually does

It gives each app a unique, random relay address and forwards mail from it to the user’s real address. The user never shares their actual email; they see a per-app address like [email protected], and Apple relays anything sent to it. Because the address is specific to your app, it doubles as a clean way for the user to cut you off later: disabling forwarding in their Apple ID settings stops your mail without exposing anything.

The relay address stays consistent for that user and app across repeated sign-ins, so it is safe to store as the account’s stable email key. The exception is revocation: if a user removes your app under Sign in with Apple in their Apple ID settings, Apple stops forwarding, and a later fresh sign-in can issue a new identifier. Designing for that, rather than assuming the address is permanent, keeps account recovery sane.

Two consequences shape your whole email strategy. First, you do not have the user’s real address and should not try to obtain it; the relay address is the address of record for that account. Second, forwarding only works while it is allowed, so transactional mail (receipts, password resets, security alerts) is fine, but you cannot assume a marketing blast will land if the user has turned forwarding off. The Sign in with Apple overview treats the relay address as a first-class identifier, and your account model should too.

Why your emails to privaterelay.appleid.com bounce

They bounce because Apple’s relay only accepts mail from sources you have registered and that pass SPF. The relay is a closed forwarder, not an open one: if a message arrives from a domain or From address that is not on your app’s registered list, Apple rejects it rather than forwarding it. That is the entire reason a brand-new Sign in with Apple integration sends a welcome email into a void on day one.

The fix is to register every domain and From address you send from, then make sure the envelope passes SPF for that domain. Apple documents this in communicating using the private email relay service, and the practical version is below. The bounce is not a code bug, so no amount of retry logic fixes it; it is a configuration that has to exist before the first send.

Setting up the forwarder in the Apple Developer portal

The registration lives under Certificates, Identifiers and Profiles, in the Sign in with Apple for Email Communication settings. Open the Apple Developer portal, go to that section, choose Configure, and add the domains you send from along with the individual From addresses you use, such as [email protected] and [email protected]. Apple’s private email relay help page walks through the same screen.

Each domain has to be verified, and the verification is an SPF check, so the domain’s DNS needs an SPF record that authorizes whatever service actually sends your mail. If you send through an email service provider, the domain you register must match the domain in your From header and that provider has to be included in the SPF record. Once a domain shows as verified and the From address is on the list, mail to the relay starts forwarding within the normal propagation time. Add new From addresses here whenever you introduce one, because an address that is not registered fails the same way an unregistered domain does.

SPF, DKIM, and the From address that has to match

The single most common failure is a From address that does not match a registered, SPF-passing domain. Apple’s relay checks that the message genuinely comes from a sender you have claimed, so three things have to agree: the domain in your From header, a domain you registered in the relay configuration, and an SPF record that authorizes the sending server for that domain. If any of the three is off, the message is refused.

DKIM and DMARC are not strictly required for the relay to accept mail, but they are worth adding because they improve deliverability everywhere else and reduce the chance of your domain being treated as spoofed. A reasonable baseline is SPF to satisfy the relay, DKIM signing on your sending domain, and a DMARC policy that starts at monitoring. Sending from a shared provider subdomain that you never registered is the quiet version of this mistake: the mail looks fine in your dashboard and still never reaches Apple users.

Testing the forwarder before you launch

Test the path end to end with a real Apple ID before you ship, because the bounce is invisible until a user hits it. Sign in to your own app with a personal Apple ID and choose Hide My Email at the consent screen, which gives you a genuine relay address forwarding to your inbox. Then trigger each transactional email your app sends, the welcome, a password reset, a receipt, and confirm every one arrives, not just the first.

Two checks catch most problems. Send from each distinct From address you use in production, since registration is per address and a working receipts@ does not prove security@ is registered. And watch for any message your sending dashboard marks as delivered that never lands, which is the signature of an SPF or registration gap rather than a spam-folder issue. Running this once for every From address turns a silent launch-day failure into a five-minute check, and it is worth repeating whenever you add a new sending address or change email providers.

Designing the app side: the Apple button and the hidden-email account screen

On the app side, the work is a correctly styled Sign in with Apple button and an account screen that handles the relay address gracefully, and both are faster to start from a finished design. Apple is strict about the button: it must follow the official styling and sit at least as prominently as other sign-in options, which is a frequent rejection point. The account screen then needs to show the hidden address as the address of record, explain that replies route through Apple, and avoid asking the user for a different email as if the relay one were not real.

The VP0 library is built for this handoff, since every design has a hidden source page an AI builder reads from a pasted link. Open an authentication or account layout, copy its link, and prompt your tool:

Build this as a SwiftUI account screen for Sign in with Apple.
Read the layout and tokens from this VP0 source page: <pasted VP0 link>.
Show the @privaterelay.appleid.com address as the account email and
add a Sign in with Apple button that follows Apple's button styling.

For the surrounding flow, the Sign in with Apple template for React Native covers the button and callback wiring, and the Sign in with Apple rejection checklist lists the review issues that sink these submissions. The honest division of labor: VP0 gives you the button and account interface, while the relay registration and DNS records are done in the Apple portal and your DNS host, which no template can do for you.

Common mistakes with Hide My Email

The mistakes cluster around assuming the relay behaves like a normal inbox. The biggest is never registering the sending domain at all, so the welcome email and every reset link bounce silently. Close behind is a From address that is not on the registered list, which fails even when the domain is correct. Sending through an email provider whose domain you did not register, or whose servers are missing from SPF, produces the same silent bounce while your sending dashboard reports success.

A few are about product behavior rather than configuration. Trying to capture or guess the user’s real email breaks trust and often the terms; the relay address is the one you keep. Treating a no-reply address carelessly matters too, because users can reply through the relay, and a black hole on the other end is a bad experience. And forgetting that a user can disable forwarding means you should design for mail that stops arriving, especially for anything non-essential. None of these need new code, only correct registration and an account model that respects the relay address.

Why unregistered mail silently bounces

The bounce is not a mystery once you read Apple’s setup requirement. Apple’s guide to communicating using the private email relay service states that you must register the outbound domains and the exact From addresses your app sends from, and pass SPF, before the relay will forward your mail to a user’s real inbox. Until that registration is in place, messages to the privaterelay.appleid.com address are rejected, which is the silent failure teams chase for hours. Treating the relay as a portal-and-DNS task you finish before launch, not an afterthought, is what makes Hide My Email actually deliver, and it is the half of the feature that lives outside your app code entirely.

Key takeaways: Hide My Email setup

The relay forwarder works once three things are true: your sending domain is registered in the Sign in with Apple email configuration, your From address is on that list, and the domain passes SPF. Get those right before your first send, add DKIM and DMARC for deliverability, and treat the @privaterelay.appleid.com address as the user’s real address of record rather than a placeholder to replace.

For the parts your app actually renders, the Apple button and the account screen, start from a free VP0 design and build it with Claude Code or Cursor, then spend your effort on the portal registration and DNS, which are the steps that decide whether the mail arrives.

Frequently asked questions

How do I set up the Hide My Email forwarder for Sign in with Apple?

Register your sending domains and From addresses in the Apple Developer portal under Sign in with Apple for Email Communication, then make sure each domain passes SPF in DNS. Until a domain and its From address are registered and verified, Apple’s relay rejects your mail, so this has to be done before the first send. The app-side button and account screen can be built from a free VP0 design with Claude Code or Cursor while you handle the registration in the portal.

Why are my emails to privaterelay.appleid.com bouncing?

Because the relay only forwards mail from senders you have registered and that pass SPF. A new From address, an unregistered domain, or a sending provider missing from your SPF record all cause a silent bounce even though your own dashboard reports the message as sent. Register the exact domain and From address you send from, fix the SPF record, and the forwarding starts working.

Can I get the user’s real email address instead of the relay address?

No, and you should not try. Hide My Email is designed so the per-app relay address is the only address you receive, and the user can disable forwarding at any time. Build your account model around the @privaterelay.appleid.com address as the address of record, and use it for receipts, resets, and security mail rather than asking the user for a different email.

Do I need DKIM and DMARC for the Apple relay to work?

SPF is the requirement the relay enforces, so that is the one you must have. DKIM and DMARC are not strictly required for Apple to accept the mail, but adding them improves deliverability across other providers and reduces spoofing risk, so a sensible setup is SPF for the relay, DKIM signing, and a DMARC policy that starts in monitoring mode.

Where can I get a free template for the Sign in with Apple screen?

VP0 is a free iOS design library where each screen has an AI-readable source page, so you can browse an authentication or account layout, copy its link, and have Claude Code or Cursor build it as a SwiftUI or React Native screen with a correctly styled Apple button and a relay-aware account view. The relay registration itself is done in the Apple Developer portal and your DNS, which the design does not replace.