Sending to Apple private relay addresses: why mail bounces
Mail to a privaterelay.appleid.com address bounces unless the sending domain is registered with Apple and passes SPF or DKIM. How to register and test it.
On this page(8 sections)
- What is an Apple private relay address?
- Why does mail to a private relay address bounce?
- How do the SPF and DKIM checks work?
- How do you register your sending domains with Apple?
- Which domains do you actually need to register?
- What does this mean if you send with Koltrix?
- How do you test it before users hit the bug?
- How should your app handle a relay address that bounces?
- Bottom line
If your app offers "Sign in with Apple", some users will hand you an address that ends in @privaterelay.appleid.com instead of their real one. Mail to that address is forwarded by Apple to the person's actual inbox, but only if Apple recognizes who sent it. If you have not registered your sending domain in your Apple Developer account, the message bounces, and your welcome email, receipt or password reset never arrives.
This guide explains what the relay checks, how to register your sources, and how to test the result before a real user finds the gap for you.
What is an Apple private relay address?
A private relay address is a random-looking alias, in the form <random-string>@privaterelay.appleid.com, that Apple creates when a user chooses to hide their email while using Sign in with Apple. Apple forwards anything sent to it to the user's real address, and the user can switch it off at any time.
To your app it looks like any other email address. Your signup flow accepts it, your database stores it, and your sending system tries to deliver to it. The difference is that Apple, not the user's mailbox provider, is the first receiving server, and Apple applies its own sender rules.
Why does mail to a private relay address bounce?
It bounces because Apple only relays mail from sources the developer has registered. Apple's own documentation says it plainly: if you do not register all the source domains or emails you use, email sent to the private relay service will result in a bounce message. Apple describes the rules on its private email relay configuration page.
The check has two parts, and mail has to pass both:
- Authentication. The message must pass SPF or DKIM in the specific way described below.
- Registration. After authentication, Apple matches the sending domain or address against the sources registered in your developer account.
A typical failure is a message that is perfectly authenticated for Gmail or Outlook but comes from a subdomain nobody registered with Apple. Everything else about your deliverability looks fine, which is why this bug survives for weeks.
At the time of writing, SendGrid's documentation says unregistered or misconfigured sends return 550 5.1.1 bad mailbox name. Other providers may word the failure differently, so treat any permanent rejection from a privaterelay.appleid.com recipient as a prompt to check registration first. Because it is a permanent (5xx) failure, a sound sending system will treat it as a hard bounce and stop retrying; see hard vs soft bounces.
How do the SPF and DKIM checks work?
Apple accepts either SPF or DKIM and recommends having both. The rules are stricter than the usual "pass or fail" in one respect: the domains must match exactly, not just share an organizational domain.
| Check | What must be true | Watch out for |
|---|---|---|
| SPF | The envelope sender domain (MAIL FROM, bounce or Return-Path) is registered with Apple, passes SPF, and matches the registered domain exactly | Providers often use their own domain in the envelope sender, so this path fails for you |
| DKIM | The signature verifies, covers the From header, and its d= domain equals the domain in the From address exactly |
A signature from the provider's domain (d= is theirs) does not count |
Apple's page adds that if your email service provider uses its own domain in the envelope sender, you must sign with DKIM to meet the requirement. In practice, DKIM signed with your own domain is the path that most sending setups can satisfy.
If the terms are new, From, Reply-To, envelope sender and Return-Path explains which address is which.
How do you register your sending domains with Apple?
You register them in the Apple Developer portal, with the Account Holder or an Admin role. Per Apple's documentation:
- In Certificates, Identifiers & Profiles, open Services, then choose Configure under Sign in with Apple for Email Communication.
- In the Email Sources section, add the domains and subdomains you send from (comma-separated), or individual addresses.
- Confirm and register. The table then shows whether each source passed an SPF check.
Apple's stated limits are 32 email sources for an individual developer and 100 for an organization. You do not need to upload a file to your server to register domains and subdomains this way.
Which domains do you actually need to register?
Every one you send from, each separately. Apple's example: to send from [email protected] and [email protected], register both example.com and sales.example.com; mail from help.example.com needs its own registration too.
Make a short inventory before you open the portal:
- the domain on your welcome and password-reset email
- the domain on receipts and billing notices
- the domain on your support replies, if people reply to a no-reply or support address
- any subdomain used by a second product, a marketing tool or a different provider
What does this mean if you send with Koltrix?
Two things, both checkable in minutes. Koltrix signs each domain with its own DKIM key, with your domain in the d= field, and the API and SMTP relay only send from an active address on a verified domain in your workspace (see the sending guide). That gives the DKIM check what it needs: a passing signature whose domain is the domain in your From address.
What remains is registration, and that is on your side, in Apple's portal. Register the exact From domain you use with Koltrix. Then send a real test and look at the headers. In the raw message, confirm dkim=pass and that header.d= is the same domain as the From address, with no subdomain difference.
How do you test it before users hit the bug?
Do not rely on a DNS checker alone. A domain health tool can verify your SPF and DKIM records, but it cannot see inside your Apple Developer account.
- Create a test Apple ID, sign in to your own app with Sign in with Apple, and choose to hide your email. Your app now holds a real relay address.
- Trigger each message type you send: welcome, verification, receipt, reset.
- Check that each arrives in the test account's real inbox.
- For any that does not, look at the bounce in your logs, then compare the From domain against your Apple registration list.
- Repeat after any change of provider, subdomain or From address.
Apple also says it will periodically notify the Account Holder and team admins if it detects that mail from your account could not be delivered by the relay, so make sure that mailbox is one somebody reads. You can switch those notifications off under the same Configure screen, which is handy in development but easy to forget about.
How should your app handle a relay address that bounces?
Treat it as a normal hard bounce with one extra step: fix the cause rather than only suppressing the address. If the bounce came from a missing registration, suppressing the user hides the real problem and leaves every other relay user broken. Suppress the address as usual (see the bounce and complaint pipeline), fix the registration, and then show the user a way to resend or confirm another address.
Two more habits help:
- Do not reject
privaterelay.appleid.comat signup. Validating addresses at signup should check syntax and deliverability signals, not ban a legitimate Apple feature. - Let users change their address later, as described in handling users who change their email address, because a relay address the user deletes will stop working on their side.
Bottom line
- A
privaterelay.appleid.comaddress belongs to a Sign in with Apple user, and Apple forwards mail only from registered sources. - Unregistered sending domains bounce, even when the same mail reaches Gmail and Outlook fine.
- Authenticate with SPF or DKIM (both is better), using exact domain matches, and register every From domain or subdomain in the Apple Developer portal.
- Test with a real hidden-email sign-in for every message type, because DNS tools cannot see your Apple registration.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
