SPF: you're right, the vendor would need to change the envelope from address to align to your organizational domain. Some will do this very easily, others are difficult, and some won't change the envelope from at all. One important thing to remember when you're having a third-party change their envelope-from is that, in most cases, the change would blind them to bounces - the third party needs bounces for list hygiene etc - which is a problem. In order to avoid this, have them use a subdomain of your organizational domain and set up an MX there. For example, if you are companyname.com and your third party is vendorname.com, having them use an envelope-from of vendor-bounces.companyname.com and then setting up an MX record back to vendorname.com for vendor-bounces.companyname.com will solve the problem in an aligned fashion.
DKIM: DKIM itself checks neither address. If you look at a DKIM signature, you'll see a d equate such as d=gmail.com. This domain is what is used to retrieve the public key to verify the message. DKIM itself has no such requirement, but DMARC requires the d= domain in the DKIM signature to match the organizational domain in the from header. This is identifier alignment, as described in Section 3.1 of RFC 7489. (https://www.rfc-editor.org/rfc/rfc7489#section-3.1) At a practical level, you must publish the public key in your DNS namespace, and the signing third party must use the attendant private key to sign a message. By publishing the pubkey in a particular DNS namespace, say as selector._domainkey.companyname.com, you are authorizing any holder of the private key, like vendorname.com, to send DMARC-authenticated email for companyname.com.
One note: DMARC itself always uses the from header, i.e. what the user sees, as the domain of record. Identifier alignment then requires what is authenticated by individual authentication protocols like SPF or DKIM - envelope from and d= domain respectively - to align with (basically match) the domain in the from header.
Does that help?
