diff --git a/changelogs/server_server/newsfragments/2081.clarification b/changelogs/server_server/newsfragments/2081.clarification
new file mode 100644
index 00000000..fd291273
--- /dev/null
+++ b/changelogs/server_server/newsfragments/2081.clarification
@@ -0,0 +1 @@
+Clarify which servers are supposed to sign events.
diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst
index b765e36a..7acc71e4 100644
--- a/specification/server_server_api.rst
+++ b/specification/server_server_api.rst
@@ -421,9 +421,8 @@ must ensure that the event:
 Further details of these checks, and how to handle failures, are described
 below.
 
-.. TODO:
-  Flesh this out a bit more, and probably change the doc to group the various
-  checks in one place, rather than have them spread out.
+The `Signing Events <#signing-events>`_ section has more information on which hashes
+and signatures are expected on events, and how to calculate them.
 
 
 Definitions
@@ -1099,6 +1098,15 @@ originating server, following the algorithm described in `Checking for a signatu
 Note that this step should succeed whether we have been sent the full event or
 a redacted copy.
 
+The signatures expected on an event are:
+
+* The ``sender``'s server, unless the invite was created as a result of 3rd party invite.
+  The sender must already match the 3rd party invite, and the server which actually
+  sends the event may be a different server.
+* For room versions 1 and 2, the server which created the ``event_id``. Other room
+  versions do not track the ``event_id`` over federation and therefore do not need
+  a signature from those servers.
+
 If the signature is found to be valid, the expected content hash is calculated
 as described below. The content hash in the ``hashes`` property of the received
 event is base64-decoded, and the two are compared for equality.