Help! All mail to privaterelay.appleid.com users is bouncing!
URL Copied
Here's the scenario. You've got "privaterelay.appleid.com" email addresses on your list. They signed up for your email. But when you try to email them, that email bounces back. What's going wrong? Allow me to explain.
Normally, Apple email subscribers on your list would show up with an email address at one of Apple's three consumer email domains: mac.com, me.com and icloud.com. But in this case, when you see subscriber addresses in the privaterelay.appleid.com domain, that means that you've got subscribers on your list who signed up for your emails using the "Sign in with Apple" functionality. When using this functionality, Apple subscribers are able to hide their true email address, having Apple transmit a unique, dedicated forwarding email address to list owners and application developers. You, as a list owner, don't get access to the subscriber's real email address. You receive only the special address at the privaterelay.appleid.com domain. You will send your email message to it, and then Apple deposits that message into the subscriber's actual Apple-hosted email inbox.
This might be new to you, but those subscribers just didn't appear in your database from out of nowhere. To get those addresses on your list, your company very likely has a website or mobile app with Apple's "Sign in with Apple" functionality explicitly enabled. Various online guides (like this one) explain how it's done. Since your company likely already has this set up, but you didn't handle the registration, you will want to go hunt down and coordinate with the developer in your organization who initially set this up.
Because, to fix it -- to make the email delivery attempts stop bouncing and allow messages to start being delivered -- you need to register your sending domains with Apple[*], via their developer portal, the one that your developer colleague likely already has access to.
Here's a guide that explains in more detail. Note that you must have SPF (Sender Policy Framework) authentication in place, which should be easy enough to accomplish. If you're a savvy sender, you've already got this in place. Also note that you'll be registering the RETURN PATH[**] domain, not the visible from domain. For some email platforms, the from header and return path header will use the same domain name, but that is not true of every platform. If you're not sure, ask your ESP's support folks for help to determine what your return path (or bounce) domain is.
After you register the domain, and assuming you have SPF email authentication properly implemented, you should be all set. Mail should (mostly) no longer bounce. Do keep in mind: though you're now sending email successfully, individual users can revoke your access to their individual inboxes at any time. If they do so, email to those addresses will bounce. Keep in mind that some bounces may still occur. One hundred percent email delivery (or even inbox delivery) is not guaranteed.
One assumes that Apple may choose to block some senders from sending to the privaterelay.appleid.com domain, even if properly registered. Reputation rules likely still apply, so don't be a spammer.
* A response from this support discussion suggests that it may not be possible to send mail to the privaterelay.appleid.com domain using an email service provider. That isn't correct. I am reliably informed that you can implement this process when sending via an ESP. When that support response was written, everything was still quite new and in beta (I think), and it's likely that support's understanding of the process was not finalized at that time.
** Return Path domain does not mean anything to do with the deliverability monitoring tools from a company of that name. It refers to a specific type of email header. (The deliverability monitoring company was named after this header.)
Here's the scenario. You've got "privaterelay.appleid.com" email addresses on your list. They signed up for your email. But when you try to email them, that email bounces back. What's going wrong? Allow me to explain.
Normally, Apple email subscribers on your list would show up with an email address at one of Apple's three consumer email domains: mac.com, me.com and icloud.com. But in this case, when you see subscriber addresses in the privaterelay.appleid.com domain, that means that you've got subscribers on your list who signed up for your emails using the "Sign in with Apple" functionality. When using this functionality, Apple subscribers are able to hide their true email address, having Apple transmit a unique, dedicated forwarding email address to list owners and application developers. You, as a list owner, don't get access to the subscriber's real email address. You receive only the special address at the privaterelay.appleid.com domain. You will send your email message to it, and then Apple deposits that message into the subscriber's actual Apple-hosted email inbox.
This might be new to you, but those subscribers just didn't appear in your database from out of nowhere. To get those addresses on your list, your company very likely has a website or mobile app with Apple's "Sign in with Apple" functionality explicitly enabled. Various online guides (like this one) explain how it's done. Since your company likely already has this set up, but you didn't handle the registration, you will want to go hunt down and coordinate with the developer in your organization who initially set this up.
Because, to fix it -- to make the email delivery attempts stop bouncing and allow messages to start being delivered -- you need to register your sending domains with Apple[*], via their developer portal, the one that your developer colleague likely already has access to.
Here's a guide that explains in more detail. Note that you must have SPF (Sender Policy Framework) authentication in place, which should be easy enough to accomplish. If you're a savvy sender, you've already got this in place. Also note that you'll be registering the RETURN PATH[**] domain, not the visible from domain. For some email platforms, the from header and return path header will use the same domain name, but that is not true of every platform. If you're not sure, ask your ESP's support folks for help to determine what your return path (or bounce) domain is.
After you register the domain, and assuming you have SPF email authentication properly implemented, you should be all set. Mail should (mostly) no longer bounce. Do keep in mind: though you're now sending email successfully, individual users can revoke your access to their individual inboxes at any time. If they do so, email to those addresses will bounce. Keep in mind that some bounces may still occur. One hundred percent email delivery (or even inbox delivery) is not guaranteed.
Apple has this page with an overview of how it all works, including how they deal with reply forwarding. And then there's this page which details configuration information for senders, where you will find more information about the sender registration process and authentication requirements.
One assumes that Apple may choose to block some senders from sending to the privaterelay.appleid.com domain, even if properly registered. Reputation rules likely still apply, so don't be a spammer.
Need more help with sending email messages to Apple iCloud mail subscribers? Check out: ISP Deliverability Guide: Apple's iCloud Mail.
* A response from this support discussion suggests that it may not be possible to send mail to the privaterelay.appleid.com domain using an email service provider. That isn't correct. I am reliably informed that you can implement this process when sending via an ESP. When that support response was written, everything was still quite new and in beta (I think), and it's likely that support's understanding of the process was not finalized at that time.
** Return Path domain does not mean anything to do with the deliverability monitoring tools from a company of that name. It refers to a specific type of email header. (The deliverability monitoring company was named after this header.)
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.