Customer.io

Authenticating for Apple private email relay

If your app or website utilizes the Sign In with Apple login service, then your customers have the optional setting to receive emails from you through the Apple Private Email Relay service. This lets customers hide their email addresses as an added layer of privacy when signing up and logging into your app.

When a customer enables the Hide My Email option, Apple generates a unique and randomized email address that you can associate with that customer. In the past, Sign in with Apple addresses used the @privaterelay.appleid.com domain. Apple is rolling out a new domain, @private.icloud.com, and new Sign in with Apple addresses are issued on it. Existing @privaterelay.appleid.com addresses continue to work and forward mail to your customers without interruption, but you might see relay addresses on either domain.

Accept both relay domains

Make sure your account systems and email validation logic accept relay addresses on both @private.icloud.com and @privaterelay.appleid.com domains. iCloud+ Hide My Email addresses remain on @icloud.com. See Apple: Update: New domain for Sign in with Apple for details.

After you pass these addresses into your Customer.io workspace, you need to do a few more things to ensure that your messages are delivered to the Apple Private Email Relay. To start, you need to log into your Apple Developer Portal and go to Certificates, Identifiers & Profiles > More > Sign in with Apple for Email Communication > Configure.

From there you can:

Apple has multiple Hide My Email services

As of iOS 15, Apple has two distinct services called Hide My Email, which are available through both Sign in with Apple and iCloud+.

You only need to follow this guide for apps and websites that use the Sign in with Apple option, which generates a unique email for the purposes of signing up for a service and logging in.

See Apple: What is Hide My Email? for more information.

Register your Sending Domains

Apple requires that you add the domains that you plan to send emails from when you send messages to their service. In addition, you need to add your “return-path” domain if it is different from the sending domain.

If you use Customer.io’s built-in delivery services, the return-path domain for your emails is different, as it utilizes a subdomain. This is the subdomain that you see for the MX and SPF records in your workspace’s Domain settings, which uses the format cio#####.yourdomain.com. Be sure to add both the domain and subdomain as Apple Email Sources.

If you use a SMTP provider with Customer.io, be sure to locate the return-path that service uses in your settings so that you can add it in your Apple Developer Portal.

Register your Communication Emails

In addition to your Sending Domains, Apple requires you to register all of the email addresses that you plan to send from at those domains.

In Customer.io you can see all of your From Addresses listed under your workspace’s Email settings. Apple lets you add these addresses individually or by entering a comma-delimited list. If you have other email sources that you may use to send emails to Private Relay addresses outside of Customer.io, be sure to add those too.

Lastly, Apple also requires you to add your domain’s feedback address. This address is used by our email server to receive bounce feedback from the email services you send to. Your domain’s feedback address is “postmaster” at the return-path domain. It looks like: postmaster@cio#####.yourdomain.com.

Authenticate your Sending Domains

If you use Customer.io’s built-in delivery services and your domain is shown as Verified, then you have already completed this step! If you haven’t verified your domain yet, you can find documentation on how to do that here.

By default, Customer.io and our sending partner require that all domains be authenticated with both SPF and DKIM to send email from your account. By meeting these requirements, your sending domain also meets Apple’s authentication requirement as well.

If you use a SMTP service with Customer.io, check your provider’s settings and documentation to ensure that your sending domain is authenticated to send from their servers.

Add an SPF record to your From domain

Apple checks SPF against the domain in your From address. Inbox providers like Gmail and Yahoo check the return-path. For Customer.io’s built-in delivery service, your return-path is the cio#####.yourdomain.com subdomain; for custom SMTP, it’s a bounce subdomain your provider owns. Either way, your SPF record lives on that subdomain, and your From domain can end up without an SPF record of its own.

When that happens, Apple’s check fails even though your mail authenticates correctly everywhere else. The Apple Developer Portal shows a failed SPF check on the From domain; third-party checkers report “No SPF Record found”; and Apple can reject the mail you send to relay addresses. With the built-in delivery service, you see this even when Customer.io shows your domain as Verified.

To pass Apple’s check, make sure the From domain itself publishes an SPF record that authorizes your sender. A hostname can hold only one SPF record, so what you add depends on what’s already there:

  • If the From domain does not have an SPF record and you use Customer.io’s delivery service, add this TXT record to it:

    TXT
    v=spf1 include:mailgun.org ~all

  • If the From domain already publishes an SPF record, because it also sends through Google Workspace, Zendesk, or another provider, merge the include:mailgun.org mechanism into that record. Don’t publish a second TXT record alongside it. A domain that also sends through Google Workspace would end up with a single record like v=spf1 include:_spf.google.com include:mailgun.org ~all.

  • If you use a custom SMTP server, get the include mechanism from your SMTP provider and use it in place of include:mailgun.org. Most providers cover this in their own authentication instructions.

The record you add sits alongside the SPF record on your return-path subdomain and doesn’t change how inbox providers authenticate your mail at send time. Repeat this check for each sending domain you register with Apple.

Troubleshooting

You may occasionally see some of your emails bounce back from a relay address (@privaterelay.appleid.com or @private.icloud.com). While the bounce reasons may not contain a lot of detail, here are a few common reasons we’ve seen for these bounces:

  • The customer has deleted the Hide My Email address from their Apple settings.
  • The customer reached their limit of 100 emails per day to and from their Hide My Email address.
  • You may need to go back and check your configurations to ensure that all of your Sending Domains and From Addresses are authenticated and registered with Apple.
  • Your From domain doesn’t have an SPF record of its own. Apple checks SPF on the From domain, not on the return-path subdomain where your SPF record normally lives. See Add an SPF record to your From domain.

In addition to monitoring your delivery logs in Customer.io, Apple can notify the Apple Developer account owner and admins when emails aren’t delivered to the relay. You can configure this setting in the Apple Developer Portal.

Conclusion

After you have completed all 3 of these steps, you should be ready to send emails to your customers who are using Hide My Email addresses through the Apple Private Email Relay.

For further reference on Apple Private Email Relay and its configuration settings, see Apple’s documentation:

Have more questions? Email our support team at win@customer.io

Updated September 16, 2026