From an ethics standpoint, I propose that the question can be boiled down to a simple test:
If the recipient of the email presented a copy of the email to your user, would the user be surprised at either the contents of the email or that an email had been sent on their behalf?
While you may be doing nothing wrong per se, if the answer to any part of the question is “yes, the user would be surprised,” you may be falling short of ethical behavior.
From an email deliverability standpoint, using a From address with a domain that you do not control, has implications on a number of standards that have the potential to prevent delivery of your email: DKIM, Sender ID, and SPF. I will address each separately.
The From address actually has no direct bearing on whether the SPF check passes or not. Most MTAs and framework APIs, however, use the From address to determine the SMTP Envelope Sender or “MAIL FROM” address. The Envelope Sender is what is actually used for the SPF check. Consequently, for SPF to pass, you need to override the Envelope Sender to contain your email address (at a domain you control and publish the correct SPF record for).
For example, sendmail(1) offers the “-f” option to override the Envelope Sender. Specific instructions for accomplishing this with different technologies is (I believe) beyond the scope of this site; you might try asking on Stack Overflow or Server Fault (depending on the exact approach used).
In addition, the Envelope Sender address is used by the receiving MTA to determine the Return-Path address. The Return-Path address is where any bounce messages are sent, which is another reason why it is important to override the Envelope Sender so that bounce messages go to you and not to your user.
There are two separate mechanisms offered by Sender ID: spf2.0/mfrom and spf2.0/pra. The former functions the same as the SPF check, and shares the same implications.
The latter does not look at the Envelope Sender, instead it looks at the Purported Responsible Address (PRA). For this to pass, all you have to do is specify a Sender address in the header that contains your email address (at a domain you control and publish the correct Sender ID record for).
Specifying a Sender address can also make it clearer to the recipient that the email was sent by you on behalf of the user (of course, it all depends on the mail client / MUA that the recipient uses).
DKIM / DKIM-ADSP / Domain Keys
There is nothing to stop you from attaching a perfectly valid DKIM or Domain Keys signature to the email, however, you would have to set the "d=" parameter to your domain—not the From address domain. It is unclear to me whether or not this is a good idea, since the standards leave it completely open as to whether the "d=" domain should or shouldn’t match the From address, the Sender address, the Envelope Sender, or anything else; and I do not have specific knowledge of how people are filtering in practice.
The DKIM-ADSP standard, on the other hand, makes it quite clear that the “d=” domain is to be compared solely to the domain of the From address(es). Domains that publish the ADSP policy,
dkim=discardable, (e.g. paypal.com), will outright prevent you from sending on behalf of users on that domain, at least when the recipient mail server is configured to filter according to the ADSP policy.
Many other email deliverability concerns, such as iprev/FCrDNS, HELO/EHLO checks, etc. are neutral to the From address, so the standard advice applies. If the new DMARC standard ever gains traction, it may pose issues just as severe as DKIM-ADSP does, due to the aligned identifiers requirement.
Other than the limitations I have specified, you will in theory have no problem altering the From address, so long as you follow all my advice above. In practice, of course, there will always be issues, because email is a little like the wild west where everyone is free to implement the standards according to their personal interpretations.