diff --git a/akka-docs/rst/java/lambda-persistence.rst b/akka-docs/rst/java/lambda-persistence.rst
index 0620a90f72..a2003ba439 100644
--- a/akka-docs/rst/java/lambda-persistence.rst
+++ b/akka-docs/rst/java/lambda-persistence.rst
@@ -172,6 +172,11 @@ By default, a persistent actor is automatically recovered on start and on restar
 New messages sent to a persistent actor during recovery do not interfere with replayed messages. New messages will
 only be received by a persistent actor after recovery completes.
 
+.. note::
+  Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
+  as the original sender is presumed to be long gone. If you indeed have to notify an actor during
+  recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
+
 Recovery customization
 ^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/akka-docs/rst/java/persistence.rst b/akka-docs/rst/java/persistence.rst
index 8db46b9b52..b8470651e4 100644
--- a/akka-docs/rst/java/persistence.rst
+++ b/akka-docs/rst/java/persistence.rst
@@ -174,6 +174,11 @@ By default, a persistent actor is automatically recovered on start and on restar
 New messages sent to a persistent actor during recovery do not interfere with replayed messages. 
 They are cached and received by a persistent actor after recovery phase completes.
 
+.. note::
+  Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
+  as the original sender is presumed to be long gone. If you indeed have to notify an actor during
+  recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
+
 Recovery customization
 ^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst b/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst
index 30ea3516f6..22052a368a 100644
--- a/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst
+++ b/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst
@@ -353,6 +353,19 @@ as reference::
       // ...
     }
 
+Sender reference of replayed events is deadLetters
+--------------------------------------------------
+While undocumented, previously the ``sender()`` of the replayed messages would be the same sender that originally had
+sent the message. Since sender is an ``ActorRef`` and those events are often replayed in different incarnations of
+actor systems and during the entire lifetime of the app, relying on the existence of this reference is most likely
+not going to succeed. In order to avoid bugs in the style of "it worked last week", the ``sender()`` reference is now not
+stored, in order to avoid potential bugs which this could have provoked.
+
+The previous behaviour was never documented explicitly (nor was it a design goal), so it is unlikely that applications
+have explicitly relied on this behaviour, however if you find yourself with an application that did exploit this you
+should rewrite it to explicitly store the ``ActorPath`` of where such replies during replay may have to be sent to,
+instead of relying on the sender reference during replay.
+
 Persistence Plugin APIs
 =======================
 
diff --git a/akka-docs/rst/scala/persistence.rst b/akka-docs/rst/scala/persistence.rst
index 02cc4a14be..0eaad129fd 100644
--- a/akka-docs/rst/scala/persistence.rst
+++ b/akka-docs/rst/scala/persistence.rst
@@ -158,6 +158,11 @@ By default, a persistent actor is automatically recovered on start and on restar
 New messages sent to a persistent actor during recovery do not interfere with replayed messages. 
 They are cached and received by a persistent actor after recovery phase completes.
 
+.. note::
+  Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
+  as the original sender is presumed to be long gone. If you indeed have to notify an actor during
+  recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
+
 Recovery customization
 ^^^^^^^^^^^^^^^^^^^^^^