Skip to main content

Apple Private Email Relay

When someone signs in to your app or website with Sign in with Apple and chooses Hide My Email, Apple gives you a random forwarding address instead of their real one - for example [email protected]. Apple's Private Email Relay service forwards mail sent to that address to the person's real inbox, but only from senders you have registered with Apple. Mail from anyone else is bounced by the relay and never reaches the person.

This page explains what has to be registered, by whom, and how to check it works for the way your workspace sends email.

New relay domain

Apple announced in August 2026 that new Sign in with Apple addresses will be issued on private.icloud.com instead of privaterelay.appleid.com, starting later in the year. Existing privaterelay.appleid.com addresses keep working. Both domains are relay addresses and everything on this page applies to both. Joryio accepts addresses on either domain like any other email address.

Why mail to relay addresses fails silently​

The relay is not a normal mailbox. For every message it receives, Apple checks two things:

  1. Is the message authenticated? It must pass SPF or DKIM in the specific way Apple requires (see What Apple checks).
  2. Is the sender registered? The sending domain or address must be on the list of email sources registered for your Apple Developer team.

If either check fails, the relay returns a bounce. Nothing breaks in your campaign: the send is accepted by your email provider, the bounce comes back later, and the contact simply never gets the message. Because relay addresses are often a small share of a list, the problem can go unnoticed for a long time.

Who has to do this​

The registration is done in the Apple Developer account that owns the app or website using Sign in with Apple - that is your account, not Joryio's. Joryio cannot register domains with Apple on your behalf.

  • Apple requires the Account Holder or an Admin role on that developer account.
  • Relay addresses belong to a developer team: the same person gets the same relay address in every app of one team, and a different one in an app from another team. Register your sending domains in the team whose apps collect the addresses. If your apps are spread across several teams, register in each of them.
  • Apple allows up to 32 email sources for an individual enrollment and up to 100 for an organization. Each domain, subdomain or single address counts as one source.

What Apple checks​

Apple accepts a message if it passes either of these checks, and recommends setting up both where you can:

CheckWhat has to matchPasses when
SPFThe envelope sender domain (also called MAIL FROM, Return-Path or bounce address - not the From address people see)That exact domain is registered with Apple and passes SPF
DKIMThe d= domain in the DKIM signatureThe signature verifies, it covers the From header, and the d= domain is exactly the domain of the From address, which is registered with Apple

After authentication, Apple also matches the From domain or address against your registered sources. So whichever check you rely on, the domain of every From address you send from must be registered.

Matching is exact. Registering acme.com does not cover news.acme.com: every subdomain you send from is a separate source and must be registered on its own (or you register the individual addresses instead).

Many email providers use their own domain as the envelope sender unless you give them a custom bounce domain (also called a custom MAIL FROM or return-path domain) on your own domain. Without one, only the DKIM check can pass. With one, both SPF and DKIM can pass on your own domains, which is what Apple recommends - so set up a custom bounce domain wherever your provider offers it.

Which domains to register​

Email in Joryio is sent in one of two ways, set up for your organization by Joryio: through Joryio's managed email (Amazon SES operated by Joryio), or through your organization's own provider account (Amazon SES, SendGrid, Mailgun or Bird). If you are not sure which one your workspace uses, ask Joryio support.

How your workspace sendsRegister with AppleCheck that passesNotes
Joryio managed emailEvery From domain your senders use, exactly as attached (for example mail.acme.com), and its bounce domain e.<sending domain> (for example e.mail.acme.com)DKIM - Joryio signs with your attached domain; SPF too once the bounce-domain records below are in your DNSEach attached domain gets a bounce (MAIL FROM) domain e.<sending domain>. Add its two DNS records and SPF passes on your own domain. Without them mail still sends, but the envelope sender falls back to Amazon SES's own domain and only DKIM can pass.
Your own Amazon SES accountEvery From domainDKIM, when the From domain itself is a verified SES identity with Easy DKIMIf only the parent domain is verified in SES, SES signs subdomain mail with the parent domain and Apple's exact match fails - verify the subdomain as its own identity. Set up a custom MAIL FROM domain on the identity in SES and register that domain with Apple too, so SPF passes as well.
Your own SendGrid accountEvery From domain; optionally the return-path subdomain SendGrid created (for example em1234.acme.com)DKIM after SendGrid domain authentication; SPF too if you register the return-path subdomainWithout domain authentication SendGrid signs with its own domain and both checks fail. Domain authentication also sets up the custom return-path subdomain - keep it on.
Your own Mailgun accountEvery From domain and the Mailgun sending domain configured for your organization (for example mg.acme.com)SPF on the Mailgun sending domain; DKIM only when the From domain is the Mailgun domain itselfMailgun uses its sending domain as the envelope sender and normally signs DKIM with it. If your From address is on a different domain (for example acme.com), DKIM does not match exactly, so the SPF route through the registered Mailgun domain is the one that passes. Make sure the Mailgun domain's own SPF and MX records are in place.
Your own Bird accountEvery From domainDKIM, when Bird signs with your From domainCheck which domain Bird signs with and which envelope domain it uses (see Test before you rely on it). If Bird offers a custom return-path (bounce) domain, set it up on your own domain and register it too, so SPF passes as well.

Every From domain means every domain your workspace actually sends from: your default sender, every saved sender under Settings → Email Configuration, and any Custom From used in a campaign or journey. The sending domain filter on Analytics → Deliverability lists the domains you really sent from in a date range, which is a quick way to find one you forgot.

DNS records for managed email​

On managed email, every attached sending domain has a bounce domain (the envelope sender, or MAIL FROM) at e.<sending domain> - for mail.acme.com it is e.mail.acme.com. It needs two DNS records, which Joryio sends you together with the three DKIM CNAME records and the DMARC record when your domain is attached:

TypeNameValuePriority
MXe.<sending domain>feedback-smtp.<region>.amazonses.com (for example feedback-smtp.eu-central-1.amazonses.com)10
TXTe.<sending domain>v=spf1 include:amazonses.com ~all-

Use the exact values from the records Joryio sends you; the region in the MX value is the one your mail is sent from.

  • With these records, the envelope sender is on your own domain, so SPF passes and aligns there, and DKIM passes through the Easy DKIM CNAME records. Both of Apple's checks can pass. For Apple to count the SPF check, register e.<sending domain> as an email source as well as the sending domain.
  • Without them, mail still sends: the envelope sender falls back to Amazon SES's default domain (amazonses.com). DKIM still passes, but SPF is not on your domain.

If your domain was attached before these records existed, ask Joryio support for the two new records.

Apple's Email Sources table shows an SPF result for each registered domain. The bounce domain passes once its TXT record is published. If the table also shows a failed SPF check on the sending domain itself (managed email puts no SPF record there), you can add the same v=spf1 include:amazonses.com ~all TXT on the sending domain. A domain can have only one SPF record: if it already has one (common when you send from your root domain), add include:amazonses.com to the existing record instead of creating a second one.

Register your domains with Apple​

Do this in the Apple Developer account that owns your Sign in with Apple app, signed in as the Account Holder or an Admin.

  1. Go to Certificates, Identifiers & Profiles.
  2. Click Services in the sidebar.
  3. Under Sign in with Apple for Email Communication, click Configure.
  4. In the Email Sources section, click the add button (+).
  5. Enter your domains and subdomains as a comma-separated list - for example acme.com, mail.acme.com - and click Next.
  6. Check the list and click Register.
  7. The table shows each source and whether it passed Apple's SPF check.

Apple does not ask you to upload a file to your server to register a domain.

Registering single addresses instead​

If you do not control the DNS of a domain you send from, you can register individual From addresses instead of the whole domain. Follow the same steps, and in step 5 enter the addresses (for example [email protected], [email protected]). Each address counts as one email source, so with many senders registering the domain uses fewer of your 32 or 100 sources.

The message must still pass SPF or DKIM as described in What Apple checks.

Check authentication in Joryio​

Your sending domains and their DNS status are on Analytics → Deliverability, in the Domain Health section: SPF, DKIM, DMARC and, on managed email, the bounce domain's MX (Bounce MX) for each attached domain, with Check Now to refresh. See DNS Authentication.

Two things to keep in mind:

  • Joryio checks DNS records; Apple checks each message. A green DKIM status in Joryio means your DKIM records are published. Apple additionally requires the signature's d= domain to equal the From domain exactly, which depends on how your provider signs. The test below confirms it.
  • On managed email, SPF shows "handled by Amazon SES". Domain Health reads SPF on the sending domain itself, while SPF for managed email lives on the bounce domain e.<sending domain>. Domain Health checks that bounce domain's MX (Bounce MX) but not its SPF TXT. To confirm the SPF, look up the bounce domain's TXT record in DNS, or check smtp.mailfrom in a test message (see below).

Test before you rely on it​

  1. Get a relay address you control. On an iPhone, sign in to your own app with Sign in with Apple and choose Hide My Email. The address is shown in your Apple Account settings (on iPhone: Settings → your name → iCloud → Hide My Email, then the app). Apple's support article Manage your apps with Sign in with Apple describes where to find it.
  2. Send a test email to it from the campaign or journey email editor (Send Test), using the sender you want to check. See Email Testing.
  3. Confirm it arrives in the real inbox the Apple Account forwards to.
  4. If it does not arrive, read the headers of a normal copy. Send the same test to a regular mailbox (Gmail's Show original, for example) and look at:
    • DKIM-Signature: ... d= - must be exactly your From domain for the DKIM route.
    • Authentication-Results: ... smtp.mailfrom= - the envelope domain; it must be registered with Apple and pass SPF for the SPF route.
    • From: - its domain must be registered with Apple.

Repeat the test for every From domain, and again whenever you add a sender on a new domain or subdomain.

How Joryio treats relay addresses​

  • They are ordinary email addresses. Joryio does not detect, rewrite or filter privaterelay.appleid.com or private.icloud.com addresses. They are stored, validated, segmented and sent to like any other address.
  • A relay address is not the person's real address. If the same person also gives you their real email somewhere else, the two addresses do not match. Identify people by your own user ID rather than by email address so both end up on one profile.
  • In the mailbox-provider breakdown on Analytics → Deliverability, relay addresses are counted under Other domains, not under Apple iCloud, because they are grouped by the recipient's domain.
  • Bounces from the relay are handled like any bounce. If your provider reports a relay bounce as permanent (hard), Joryio marks the address invalid and stops mailing it, workspace-wide. See Bounce handling.

Common problems​

Mail reaches everyone except relay addresses. The From domain is not registered with Apple, or the message passes neither of Apple's checks. Compare the From, d= and smtp.mailfrom domains of a test message with your registered sources.

It worked, then stopped for one campaign. That campaign probably uses a sender on a domain or subdomain you have not registered - for example a Custom From on promo.acme.com. Register it.

Apple's table shows the SPF check failed on a managed-email domain. For the bounce domain e.<sending domain>: its MX and TXT records are missing - add the DNS records for managed email. For the sending domain itself: managed email puts no SPF record there; DKIM still passes, and you can add the TXT record described in the same section.

DKIM passes everywhere, but the relay still bounces. The d= domain is close but not equal to the From domain - typically the parent domain (acme.com) signing mail from a subdomain (mail.acme.com), or the provider's own domain. Set up DKIM on the exact From domain in your provider.

After fixing the registration, some relay addresses are still not mailed. Messages that bounced before the fix may have marked those addresses invalid, and Joryio does not lift a hard bounce on its own. Clear it on the contact: open the profile under Users, click Edit on the Subscriptions card, tick Clear bounce status and mark email as valid and save. You can do the same through the API with the clear-bounce endpoint. Test sends are refused for these addresses until the bounce is cleared.

One person never receives mail, everyone else does. The person may have turned off forwarding for your app in their Apple Account, or changed the address it forwards to. That is their choice and cannot be changed from your side.

You run out of email sources. Register domains instead of single addresses, and remove sources you no longer send from.

Sources​