Like entrop-x says, a valid MAC proves that the sender (or, more specifically, whoever computed the MAC) knows the secret MAC key. That can be sufficient to prove the sender's identity, e.g. if the only people who are supposed to know the key are you and whoever claims to have sent the message, and you know you didn't send it yourself.
That said, there are several edge cases that one should be aware of:
For example, there might be several people who all know the key. If the identity of the sender is included as metadata alongside the message, but is not fed into the MAC calculation, then an attacker may change the metadata without invalidating the MAC.
So if Alice, Bob and Charlie all know the key, an attacker might be able to convince Alice that a message sent to her came from Bob, when it was actually sent by Charlie. Or the attacker might even be able to divert the message to Bob instead, and convince him that it was sent by Alice.
In some cases, even if there are only two parties who know the key, an attacker might be able to take a message sent by Alice to Bob and resend it back to Alice, claiming that it's from Bob.
Even if the sender's (and the intended recipient's) identity is included in the MAC input, this doesn't necessarily verify when the message was sent. So an attacker might be able to record a legitimate message to Alice from Bob and send it again to Alice seconds or days or years later.
The first two attacks can be prevented by ensuring that all relevant message metadata, including the sender's and the receiver's IDs, is included as input to the MAC calculation. In authenticated encryption terminology, such metadata is called "associated data". Note that the metadata does not always need to be actually transmitted with the message, if it can be inferred from context (e.g. the receiver likely knows what their own ID should be), but it should still be included when computing the MAC.
The third attack cannot be prevented by MACs alone, but requires some kind of a unique message number and/or a timestamp to let the receiver detect and reject duplicate or excessively delayed messages. Of course, the message number and the timestamp should also be considered associated data, and included in the MAC input, to prevent an attacker from modifying them.
The general rule to keep in mind is that a MAC only proves one thing: that whoever computed the MAC knew the key and all the inputs to it, and that they thought it was a good idea to feed those inputs to the MAC. It does not prove when or why they thought that, or what they intended to do with data after MACing it — unless, of course, that information is somehow encoded by the MACed data itself.
