diff --git a/proposals/4261-do-not-encrypt-for-device-flag.md b/proposals/4261-do-not-encrypt-for-device-flag.md
new file mode 100644
index 00000000000..86da051e021
--- /dev/null
+++ b/proposals/4261-do-not-encrypt-for-device-flag.md
@@ -0,0 +1,51 @@
+# MSC4261: "Do not encrypt for device" flag
+
+Some devices (such as bots and application service puppets) may not need to
+receive encrypted messages.  For example, an application service may have
+multiple puppeted users in a room, but only needs to receive room keys once to
+decrypt a message; sending the room keys to all of the application service's
+puppeted users is redundant.  Another example is bots that only need to send
+messages, but not receive messages.
+
+We propose adding a flag to the device keys to indicate that encrypted messages
+should not be sent to certain devices.
+
+## Proposal
+
+A new optional `do_not_encrypt` property is added to the `DeviceKeys` structure
+that the client uploads to the server via the `POST /keys/upload` endpoint, or
+downloads via the `POST /keys/query` endpoint.  This property is a boolean that
+defaults to `false`.
+
+Clients MUST NOT send room keys to devices that have this property set to `true`.
+
+## Potential issues
+
+Since this is a device-level flag, application services must ensure that at
+least one device that is able to receive room keys is present in each room where
+it needs to receive encrypted messages.  This can be done, for example, by
+having a single application service user that is in all bridged rooms.
+
+## Alternatives
+
+Rather than including a flag in the device keys, a flag could be put in room
+state, such as the user's `m.room.member` state event.  However, by putting the
+flag in the device keys, the flag is signed so that it cannot be forged.  In
+addition, the `m.room.member` state may not work well as the server generates
+these events in response to profile changes, and may overwrite the flag.
+Creating a new state event for this seems unnecessary if using the device keys
+works.
+
+## Security considerations
+
+This proposal decreases the number of devices that will receive room keys, so
+does not pose any risk for leaking messages.
+
+## Unstable prefix
+
+Until this is proposal is accepted, implementations should use the property name
+`org.matrix.msc4261.do_not_encrypt` rather than `do_not_encrypt`.
+
+## Dependencies
+
+None