There's no way in OpenPGP to MAC a message. You can sign it, but that's it.
We could have a lively debate about the legal ramifications of a digital signature, and I'll take the side that it means less than you've been told it has. Like everything, context matters. I could give you a use case where there'd be an approximately 100% likelyhood that a digital signature would be "legal" and another where there'd be about zero. In the latter case, it could in contrast be evidence that the keyholder was hacked.
However, there is a feature of OpenPGP that might give you something like what you want. That is the Modification Detection Code. MDCs are on by default for any encrypted message these days.
The MDC is a subtle thing. When we (the working group) did it, we wanted a way to know that a message was intact, but not have to sign it. That is, the message is repudiable, but reliable (to some extent).
The problem arises from the fact that CFB encryption can be tail-truncated with impunity. In other words, if you get an unsigned OpenPGP message, you can never know that something wasn't removed from the end. (CBC mode has a related feature that it can be head-truncated with impunity.)
The MDC code puts a hash of the message at the end and encrypts it as usual. There are a few things to note about this:
We did it before there was a lot of theory about where a MAC ought to be placed. Present accepted practice is that you MAC the ciphertext, not the plaintext.
There are known "attacks" against this. Most notably, you can create an "existential forgery" of a message. This is really important with something like IPsec or TLS, but for OpenPGP is mostly a yawn, as it's a higher level concept. Spam is an existential forgery, for example.
The lack of reliability is a feature, given what the working group wanted. Remember, if you want a message to be intact, you can sign it. Heck, you can create a one-time signing key and sign it with that, if you're worried about legal etc. ramifications. Keys are cheap. What we wanted was a repudiable message that the receiver had a good chance to know arrived intact. It meets this goal. It fails to meet things that weren't goals for the feature, and frankly, my opinion is that you should just sign the message. As I said before, create a new signing key if you don't want tracking.
I think this is very close to what you want. It's not a MAC, it's less strong than a MAC. But it provides a reasonable level of assurance that the obvious CFB flaw hasn't happened.