diff --git a/specification/modules/end_to_end_encryption.rst b/specification/modules/end_to_end_encryption.rst
index 628c1a60a..e6048c288 100644
--- a/specification/modules/end_to_end_encryption.rst
+++ b/specification/modules/end_to_end_encryption.rst
@@ -550,31 +550,6 @@ Example:
         ]
     }
 
-
-Recovering from undecryptable messages
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Occasionally messages may be undecryptable by clients due to a variety of reasons.
-When this happens to an Olm-encrypted message, the client should assume that the Olm
-session has become corrupted and create a new one to replace it.
-
-.. Note::
-   Megolm-encrypted messages generally do not have the same problem. Usually the key
-   for an undecryptable Megolm-encrypted message will come later, allowing the client
-   to decrypt it successfully. Olm does not have a way to recover from the failure,
-   making this session replacement process required.
-
-To establish a new session, the client sends a `m.dummy <#m-dummy>`_ to-device event
-to the other party to notify them of the new session details.
-
-Clients should rate-limit the number of sessions it creates per device that it receives
-a message from. Clients should not create a new session with another device if it has
-already created one for that given device in the past 1 hour.
-
-Clients should attempt to mitigate loss of the undecryptable messages. For example,
-Megolm sessions that were sent using the old session would have been lost. The client
-can attempt to retrieve the lost sessions through ``m.room_key_request`` messages.
-
 Messaging Algorithms
 --------------------
 
@@ -692,6 +667,31 @@ that it will maintain for each device, and expiring sessions on a Least Recently
 Used basis.  The maximum number of olm sessions maintained per device should
 be at least 4.
 
+Recovering from undecryptable messages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Occasionally messages may be undecryptable by clients due to a variety of reasons.
+When this happens to an Olm-encrypted message, the client should assume that the Olm
+session has become corrupted and create a new one to replace it.
+
+.. Note::
+   Megolm-encrypted messages generally do not have the same problem. Usually the key
+   for an undecryptable Megolm-encrypted message will come later, allowing the client
+   to decrypt it successfully. Olm does not have a way to recover from the failure,
+   making this session replacement process required.
+
+To establish a new session, the client sends a `m.dummy <#m-dummy>`_ to-device event
+to the other party to notify them of the new session details.
+
+Clients should rate-limit the number of sessions it creates per device that it receives
+a message from. Clients should not create a new session with another device if it has
+already created one for that given device in the past 1 hour.
+
+Clients should attempt to mitigate loss of the undecryptable messages. For example,
+Megolm sessions that were sent using the old session would have been lost. The client
+can attempt to retrieve the lost sessions through ``m.room_key_request`` messages.
+
+
 ``m.megolm.v1.aes-sha2``
 ~~~~~~~~~~~~~~~~~~~~~~~~