What benefit would DKIM provide if SPF is already used?
If a domain has SPF configured the receiving mail server can check if the claimed sender of the mail according to the SMTP dialog (i.e. MAIL FROM) is allowed to send mail from this IP address. This helps against sender spoofing only a bit since only the sender based on the SMTP dialog is checked but not the From header of the mail. But mail clients usually care only about the latter one.
With DKIM the outgoing mail server signs a mail and this signature can also be checked by the sender, i.e. not only by the receiving SMTP server. This signature might include the whole body but might also be include only part of the body. And while the From header is part of this signature it does not mean that the From header must be from the signers domain which means spoofing is still possible.
Spoofing of From is only addressed by configuring a DMARC policy which requires that the domain in the From header is either protected by SPF or DKIM and which specifies a policy when the requirement is not met.
Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?
E-mails don't claim to be from a specific server but from a specific domain. And like I said both SPF and DKIM alone don't protect against spoofing the From header. And DKIM only protects part of the mail against modification: usually it protects the full body but might be configured to allow extending the body. And it only protects some headers but not all.
If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?
Mail is delivered hop by hop and even if it is encrypted with TLS this only is relevant between the hops. So there are many parties involved which have access to the unprotected mail and could modify it.
Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?
If the attacker can spoof DNS MX records which specify how a mail gets delivered or if the attacker can intercept the mail on unprotected transport or at one of the hops the attacker can modify it. But the attacker cannot simply put a server on the internet and declare it to be the responsible server for the domain, he must other parties convince that they send the mail through this server (i.e. spoofing DNS MX record).
If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?
The messages travels encrypted from your mail client to the mail server of your provider, is decrypted there, modified (Received header added, maybe DKIM header) and the re-encrypted again to transport it to the next hop which might be google already or might be another upstream mail server.
Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?
While the attacker can add a Received-SPF header to the mail and thus claim the it did check for SPF a mail server (MTA) on the edge between internet and intranet receiving this mail might check again from which IP address the mail really comes, i.e. it will not trust the Received-SPF header. This header is mainly used by spam checkers which want to incorporate the result of the SPF test into their reputation check but don't run at the mail server and thus don't have access to the original IP of the sender.