The app reports “sent,” but a Sign in with Apple private relay address never receives the message.

Fastest fix: verify the registered sender source and its SPF or DKIM authentication first; then check the test address’s forwarding status and the destination inbox. A send log or relay failure notice is evidence about one part of the route, not proof that the person’s mailbox received the message.

This guide is for developers maintaining Sign in with Apple email flows for their own products or authorized test accounts.
QA engineers can use it to distinguish a relay address’s status from evidence of actual receipt.
Mail administrators can use it to check the sender registration and authentication requirements.

Last updated November 8, 2026. We checked Apple’s private email relay configuration documentation, its Sign in with Apple environment configuration, and its announcement about the private relay domain update.

“Sent” can mean several different things

A successful response from your application or email provider does not establish that Apple processed a message for a private relay address, or that the destination mailbox accepted it. Treat the route as separate checkpoints:

  • Application: Did the product create the intended message for the correct account and event?
  • Sending system: Did your mail infrastructure accept the request and attempt delivery?
  • Apple relay: Was the sending source eligible, and did the relay process the message?
  • Destination mailbox: Did the person’s chosen address accept the forwarded message, and where did it place it?

This distinction matters during registration, password recovery, and notification testing. A backend can successfully enqueue a password-reset email while the relay rejects or cannot forward it. A relay can process a message while the destination provider filters it. Those outcomes call for different fixes.

Why can’t the Apple private email relay forward a developer’s message? Start with the source identity and authentication—not the visible relay address alone. Apple’s documentation says developers must register the sending sources used for messages to users who chose to hide their email, and that messages must meet its SPF and/or DKIM requirements. Check Apple’s relay configuration requirements against the actual mail path before attributing the failure to a particular cause.

Sender registration must match the real sending path

A common gap appears when the address shown in application code differs from the source that sends the message. For example, a team may register its primary sending domain but later send from a subdomain, a separate address, or a third-party mail service. Do not assume that registering one source automatically covers every source used by the product.

Inspect the message and your provider configuration to identify the actual sender details. Compare those with the sources registered in the Apple Developer configuration for the relevant account. Check the sending domain and any separately used source, including a subdomain or dedicated sending address. Then verify that the production and test environments do not silently use different sender identities.

Apple’s Sign in with Apple environment configuration describes the configuration context. The practical rule is to compare the configured source with the message your system actually sends. If the source is missing or differs, correct the registration or make the sending configuration consistent, then retest. Do not infer a specific error message or failure behavior from a mismatch; the documentation does not justify predicting one universal symptom.

How do you confirm that a sending domain is registered and meets Apple relay requirements? Review the configured sources in the Apple Developer account, then compare them with the sender and authentication details observed in the delivered-message headers or sending provider’s records. A dashboard setting by itself does not prove that a particular test message used that source or passed authentication.

SPF and DKIM need to match the mail that actually leaves

A source can be registered while the message still fails an authentication check. SPF and DKIM are not interchangeable labels to tick in a project checklist: each is evaluated in relation to the message and the sending setup. Apple’s published requirement is SPF and/or DKIM, so consult its current configuration instructions rather than assuming that a particular combination, record value, or provider preset is universally sufficient.

For a third-party sending service, check the infrastructure that actually transmitted the test message. The domain displayed in your application’s “From” field may not, on its own, explain the SPF or DKIM result. Inspect the received message headers when available and compare the authenticated domains and results with the sender settings. If you cannot see a received copy, use the sending provider’s event records to determine what it attempted, but do not treat those records as proof of Apple relay processing.

A useful debugging sequence is to change one variable at a time. First confirm the message’s actual sending source. Then compare that source with the registered source. Next review SPF and DKIM for the real sending route, including any provider-specific configuration. After making a change, send a new message through the same path. This avoids confusing a corrected DNS or provider setting with a message that was already in flight.

The new private.icloud.com domain is part of Apple’s published Sign in with Apple update. Apple’s developer announcement explains the domain update; it does not establish that every existing address has migrated or that a particular test address has received a message. When testing, record the address domain you actually used and check the applicable configuration. Do not treat the domain change alone as a delivery diagnosis.

A relay notice is a clue, not a receipt

Apple documents notifications about undelivered messages in its private relay setup guidance. Such a notice can help show that the relay encountered a delivery issue. It does not prove that the destination inbox received the message, and its absence does not establish successful receipt. Keep the notice, sender logs, and destination mailbox evidence as separate observations.

Does an Apple forwarding failure notice prove delivery to the personal inbox? No. It is a relay-related clue, not a receipt confirmation from the person’s destination mailbox. Use it to narrow the investigation, then check the forwarding configuration and destination-side filtering.

Check the test account’s relay and forwarding status in the relevant account settings. Then ask the authorized tester to inspect the destination inbox, spam folder, and mail rules or filters. Search using the sender and subject used in the test, and confirm that the message was not archived, routed to another folder, or blocked by a local rule. Avoid asking testers to share personal mailbox contents; they can report the specific test result without exposing unrelated messages.

If a notice identifies an undelivered message, correlate it with the time and message identifier in your own sending records where available. This can help distinguish a message that was never sent from one that reached a later stage and then failed. Do not guess at the underlying rejection reason when the notice and logs do not identify it.

Retest with evidence from each checkpoint

Use an authorized account that has opted into Sign in with Apple private email relay. Keep the test focused on your own app or website; do not use this process to automate signups on third-party services. Record the relay address used for the test without exposing it in shared logs or tickets.

For a reliable regression, capture the event that triggered the message, the sender identity, the sending system’s result, and the tester’s receipt status. If the app updates account state after sending, record that separately. A green status in the product may mean “message queued,” not “message received.” Make the status label and test report precise enough that another engineer can tell which event actually passed.

Use this checklist during each retest:

  • [ ] Confirm that the test account is authorized and has a Sign in with Apple private relay address.
  • [ ] Trigger the email flow in the intended environment and record the account state that caused it.
  • [ ] Capture the sender address and sending domain used by the actual message.
  • [ ] Compare the source with the sender sources registered for the Apple private email relay configuration.
  • [ ] Check SPF and/or DKIM for the real sending path, using message headers or provider records where available.
  • [ ] Review sending-system events and any Apple undelivered notice without treating either as proof of inbox receipt.
  • [ ] Confirm the test address’s forwarding status and ask the tester to check the destination inbox, spam folder, and relevant filters.
  • [ ] Retest after a configuration change and record new evidence rather than reusing an earlier send result.

A controlled inbox can help verify other parts of your product’s email workflow, such as whether a message template renders or whether a test event triggers a send. It cannot substitute for testing delivery to an actual Apple private relay address. A successful receipt at a separate test inbox says nothing conclusive about relay acceptance or forwarding.

If a test involves the privaterelay.appleid.com domain, treat the address as a test input, not a diagnosis. Confirm the account’s relay status and the sender configuration that applies to the message. If the observed address uses private.icloud.com, record that fact and verify the current Apple configuration rather than assuming all addresses or accounts have the same state. Apple’s account-change guidance is also relevant when account changes affect your application’s stored Sign in with Apple data.

Compare what each piece of evidence proves

The table below is a way to avoid closing an incident on the strength of a single “success” indicator. Each source answers a different question; combine them before calling the delivery path healthy.

Evidence What it can establish What it cannot establish
Application event or status Your product reached its own message-generation or workflow state That the sending system transmitted the message
Sending-provider record The sending system recorded an attempt or result for its part of the route That Apple processed the message or that a person received it
Sender registration and SPF/DKIM review Whether the configured source and authentication setup appear aligned with Apple’s published requirements That a specific message was accepted or forwarded
Apple undelivered notice A relay-related delivery problem was reported That the destination inbox received the message, or the precise cause unless documented
Authorized tester’s destination-inbox confirmation Whether the tester found the message in the destination mailbox or its folders That all accounts, sources, or future messages will behave the same way

Choose the right test inbox for the question

The best test address depends on what you are trying to prove. A private relay address is necessary when the question is whether your Sign in with Apple flow works through Apple’s relay. A separate controlled inbox can be useful for testing your own message generation and other email paths, but it does not prove Apple relay delivery. A long-term account is preferable when you need persistent recovery messages or ongoing correspondence.

The trade-offs are practical:

  • Apple private relay address: tests the relay path itself, but requires checking sender eligibility and destination receipt separately.
  • Controlled test inbox: useful for inspecting messages in a repeatable test workflow, but cannot stand in for a private relay address.
  • Long-term mailbox: appropriate for important accounts that need future recovery or replies, but can expose a personal or work address to test data and repeated notifications.

For test data hygiene, use authorized accounts and avoid putting real personal information into demo records, application logs, screenshots, or bug reports. A relay address does not make all surrounding test data anonymous: account identifiers, event payloads, message subjects, and logs can still reveal personal information. Temp88’s privacy guidance for test email workflows can help your team think through what to keep out of test records. For related delivery checks outside Apple relay acceptance, see our guide to using email aliases to test delivery.

If the remaining task is to test a non-Apple message flow, Temp88 may be one option for temporary receiving. Use it only where that receiving setup fits your own product test; it cannot verify Apple’s private relay, guarantee delivery, or replace an authorized Sign in with Apple retest. For a temporary test message, you can review Temp88 and keep the production relay check separate.

Further reading

What kind of task are you doing now?

For a single message, open a disposable inbox. For ongoing public contact, open the forwarding dashboard and create a dedicated alias.

Create a disposable address