Unable to Send Emails to Private Relay Service

We have registered the full email addresses on the developer portal and they have green ticks next to them but are unable to send emails from them still, they just bounce back. We have also published a spf record for our domain, does anyone else have this problem? How can we fix it?

Answered by DTS Engineer in 635638022
In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. Please ensure the source emails and domains are properly registered for your developer account, and that you have Private Email Relay notification enabled to detect misconfigurations and receive periodic emails of failed deliveries.

All outbound emails sent through the Private Email Relay service must be authenticated with the Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM) protocol. This is to prevent spam and ensure that messages sent to your users only come from your registered source email addresses and email domains. We recommend authenticating outbound emails using both SPF and DKIM, if possible.

For additional information, please see Developer Account Help: Sign in with Apple - Configure Private Email Relay Service > Authenticating Your Domains—

Using SPF Authentication
The domain in the envelope sender (also known as the MAIL FROM, bounce, or Return-Path address) must be registered in the Domains section of Certificates, Identifiers & Profiles. This domain must pass SPF validation, and the registered domain and envelope sender domain must match exactly to pass the private relay service SPF check.

Using DKIM Authentication
If you use an email service provider that uses their domain in the envelope sender of your outbound emails, you must sign your emails with DKIM to meet the private relay’s email authentication requirements.
The DKIM domain (the d= value in your DKIM signature) will be matched against the domain used in your email’s From: address (aka the header From: address) that is registered in the Domains section Certificates, Identifiers & Profiles. To pass the private relay’s DKIM check, the DKIM signature must pass verification, the DKIM signature must include the From: address, and the DKIM domain and the domain in the From: address must match exactly.

Registering Valid Source Domains and/or Emails
After the private relay authenticates inbound emails with either SPF or DKIM, it will also match the source email or domain against your registered email domains or email addresses.

You must register and validate every source email domain or subdomain you intend to use. If you do not own a domain configured for email, you can register individual source email addresses. For example, if you want to send emails from “john@example.com” and “john@sales.example.com” you must choose to register source email domains as “example.com” and “sales.example.com” or you may choose to register individual source email addresses as “john@example.com” and ”john@sales.example.com”.

If you want to send email addresses from any other source (for example, “john@help.example.com”) you must also register “help.example.com” or “john@help.example.com” as a separate source.

If you do not register all the source domains or emails that you use, email sent to the private relay service will result in a bounce message.

Configuring Your Email Service Provider (ESP) Account
If you send outbound emails with email service providers such as Amazon SES, Mailchimp, or SendGrid, the SPF record you publish for your email sending domain should look similar to examples below. The “include” mechanism in the SPF record authorizes your email service provider’s mail servers to send on behalf of your domain.
  • SPF TXT Record for example.com to support using SendGrid example.com. IN TXT "v=spf1 include:sendgrid.net ~all"

  • SPF TXT Record for example.com to support using Amazon SES example.com. IN TXT "v=spf1 include:amazonses.com ~all"

  • SPF TXT Record for example.com to support using Mailchimpexample.com. IN TXT "v=spf1 include:servers.mcsv.net ~all"

Accepted Answer

Please make sure that you're actually sending your emails from the domains you have registered.

If you use a third-party mail service (like AmazonSES, SendGrid, or MailChimp), it does not work yet.


Also, if you have an example <anonymousUserId>@privaterelay.appleid.com, we can try looking in the logs.

Can we expect SendGrid to work eventually? We rely on them to communicate with customers...

Ah we use Amazon SES, is there an estimate for when this will be live?

Is https://mandrillapp.com supported? We are using Mandrill to send our emails and I can confirm that emails from Mandrill are using the registered domain and SPF record are in place.


Is there any estimate on when these third party service will be able to send emails?


Is google supoprted?


I'll appreciate if you can share some extra information, one of the emails that we tested with is c64a24ubht@privaterelay.appleid.com

All I can say is that we are "investigating" support for third-party email services.

Right now, running your own MTA and doing the SPF registrations are the only supported mechanism for getting through privaterelay.appleid.com.

We are aware that lots of devs use things like AmazonSES, MailChimp, SendGrid, etc. The list is large.

Stay tuned.

Looks like the email came from @mandrillapp.com, and this was the result: error=R5S84P9G98 is not allowed to send to recipient.


You're in the same boat as gemmaPerigee, third-party mail services are not yet supported.


We hope to have something to say about this soon, but I can't make committments yet.

what about Office365? My company's using office365 as email service provider, I've added several full emails in 'Individual Email Addresses' with green marks shown, but still failed with "5.1.0 - Unknown address error 550-'5.1.1 bad mailbox name'".

The email address is memm9f2qh4@privaterelay.appleid.com

Are you able to specify what aspect of third-party mail services prevents their use? We have DKIM and SPF set up for our whitelisted SIWA domain, but don't have a reverse DNS record set up for the IP we're using (a dedicated IP used primarily with a different domain), and are getting "550 5.1.1 bad mailbox name" responses. It seems like a third-party mail service with a dedicated IP and rDNS would be indistinguishable - from privaterelay.appleid.com's point of view - from running our own MTA.


We can certainly set up rDNS if that's a requirement, but otherwise this is a pretty big blocking restriction for SIWA.

We are experiencing a similar issue.


Sending to a relay email address from an email address whitelisted under the "Individual Email Addresses" section of https://developer.apple.com/account/resources/services/configure, and with a 3rd party email sending service, bounces with a "500 / 5.1.1 bad mailbox name" error.

Can you shed light on how/why 3rd party systems are not supported? If the SPF record we set for our customers are valid and point to the IP addresses (rather than a CNAME) would that work?

What you said is actually incorrect. We use Sendgrid and are able to send to your email relay service. What you meant to likely say, is that if you used a shared network on one of these providers, the relay-service does not work because it can not verify the SPF and hosted file for that domain correctly.


Other than that, all clients who use a dedicated IP address and have some knowledge about DNS can set this up to work correctly.

Are there any updates to share on a timeline for a potential solution to this issue?


It's unfortunate that new apps are potentially required to support this feature, yet this critical gap in functionality remains.

Any updates for supporting 3rd party eails ervices?

Waiting also for an update!

Likewise, we are blocked on rolling out our completed Sign in with Apple integration, due to this third-party email broker situation. Can these common email providers not just be whitelisted for this feature? There's probably a handful of reputable domains to account for the majority of use cases.

Update:

We are not blocked anymore. 🙂

This seems to be incorrect.


Following the instructions here https://sendgrid.com/docs/ui/account-and-settings/configuring-sign-in-with-apple/ we were able to get our sendgrid emails work properly with the relay service.


We also have send emails through a third party service using SalesForce. And we were able to send emails through the relay after registering and verifying our sending domain with Apple.

We are using Mailgun and are also not able to send to Apple Id users who use the email relay. We receive an error message as follows:


Failed: postmaster@mg.pettingclub.com → xxxxxxx@privaterelay.appleid.com ...... Server response: 550 5.1.1 Relay not allowed for <xxxxxxxx@privaterelay.appleid.com> from domain: <mg.pettingclub.com>


Can someone from Apple please respond whether Mailgun is supposed to work with apple relay?

Instead of certifying a domain - can we certify specific email addressed ? The setting does not seem to work for that.


We are using a DNS setting to send emails from Mailgun that appear as "mg.pettingclub.com" . However we cannot load the txt signature file to that domain because obviously the mail server is at Mailgun.


So we tried instead to set the "Individual Email Addresses" settings, but any address we added to it - does not seem to work. Not info@pettingclub.com , nor any gmail address we tried. For example:

550 5.1.1 Relay not allowed for <xxxxxxxxxx@privaterelay.appleid.com> from domain: <gmail.com>


Is there a problem with setting up individual email addresses?

what made it possible to send?

We currently use MailChimp and AmazonSES email services and this is a significant issue for us, has this changed since September 2019?

What service are you using?

Any update on the timeline for this? Still waiting to implement

Hi,


Is there any update on supporting third party services for the private relay service?


Thanks,

Mehdi

.