IN A WORD: Maybe.
It’s important to bear in mind that Apple SSO (and other similar offerings from Google and Facebook) are credential management systems, full stop. They are really not intended to be used as an e-mail subscription mechanism, so when they ARE used in that way by senders, problems can arise.
Every Apple ID (Google ID, Facebook ID, etc.) has an e-mail account associated with it. That e-mail account may or may not be the actual e-mail account that recipients prefer to use (or use at all!) to send and receive e-mail. In many instances, a new Apple | Google | other e-mail address is created on the fly or automatically for the purposes of establishing the credentials, never to be used again by its nominal owner. In an unmeasurable number of instances, SSO users might be using the mechanism as a way of actually avoiding your e-mail.
Where I see senders rely on SSO or a mobile device default installation account for e-mail addresses, over time a growing cohort of those addresses are bouncing because they are over quota – full to overflowing because the recipient doesn’t read or delete mail to that inbox.
Those soft bounces inflate the denominator of any engagement metric that is expressed as a percentage of messages attempted to send (so pretty much all of them). That means that they’ll have some immediate, negative effect of on the reported metrics.
Over time, persistent attempts to send to those inactive/abandoned/full inboxes will have an effect on real reputation, particularly where the sender is not doing a very good job of suppressing unengaged recipients.
The solution, then, is not to rely on or assume that the address associated with the SSO ID or the default device installation address is the same mailbox that the user wants to receive e-mail. Instead, senders should ask recipients explicitly what e-mail address the recipient wants to subscribe with (and then confirm the address with a closed-loop confirmation message), whether or not the address is the one associated with the SSO credential.