diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index 69c97d59b5f16d7781ed3778d7252ac5b5db0647..47469aac68de1299c1d0859c5c41e6fd1732ffe4 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -161,6 +161,9 @@ If the sender's address is spoofed, the reject notice is delivered to the spoofe
 `FROM` address, which can cause the mail server's IP or domain to appear on a block
 list.
 
+WARNING:
+Users can use the incoming email features without having to use two-factor authentication (2FA) to authenticate themselves first. This applies even if you have [enforced two-factor authentication](../security/two_factor_authentication.md) for your instance.
+
 ### Linux package installations
 
 1. Find the `incoming_email` section in `/etc/gitlab/gitlab.rb`, enable the feature
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 4fd43bde6a58ce022819381d34b72b50f2650f5b..6c9b724781f110d825e6d5f3ff4b4016e70f695f 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -107,6 +107,8 @@ Enforcement affects all [direct and inherited members](../user/project/members/i
 Access tokens are not required to provide a second factor for authentication because
 they are API-based. Tokens generated before 2FA is enforced remain valid.
 
+The GitLab [incoming email](../administration/incoming_email.md) feature does not follow 2FA enforcement. Users can use incoming email features such as creating issues or commenting on merge requests without having to authenticate themselves using 2FA first. This applies even if 2FA is enforced.
+
 ### 2FA in subgroups
 
 You can enable and enforce 2FA for individual subgroups in the same way as a top