Yes, they're originated by PayPal, but collected by a different original recipient and from there sent on to the victim. The envelope-recipient is not part of the material signed by DKIM, so the signature remains valid.
The To: header _is_ part of the signed material so will list the original recipient not the victim — but the attacker sets the recipient name/address to something misleading like “Order Received” to obscure this, and sets the store name to some long text that will be misleading when templated into the PayPal invoice request mail text.
PayPal have long had a problem with failing to make untrusted supplied text clear in their communications, but this is an unusually convincing attack.
I don't know why they always use (compromised?) onmicrosoft subdomains in particular. In the samples I've seen they're getting an SPF softfail so it doesn't seem MS's relays are passing SPF for paypal (sendgrid's might...)
