Document Incoming emails headers

doc/administration/incoming_email.md

@@ -66,6 +66,24 @@ This solution is relatively simple to set up: you just need to create an email
 address dedicated to receive your users' replies to GitLab notifications. However,
 this method only supports replies, and not the other features of [incoming email](#incoming-email).
 
+## Accepted headers
+
+Email is processed correctly when a configured email address is present in one of the following headers:
+
+- `To`
+- `Delivered-To`
+- `Envelope-To` or `X-Envelope-To`
+
+In GitLab 14.6 and later, [Service Desk](../user/project/service_desk.md)
+also checks these additional headers.
+
+Usually, the "To" field contains the email address of the primary receiver.
+However, it might not include the configured GitLab email address if:
+
+- The address is in the "CC" field.
+- The address was included when using "Reply all".
+- The email was forwarded.
+
 ## Set it up
 
 If you want to use Gmail / Google Apps for incoming email, make sure you have

doc/user/project/service_desk.md

@@ -289,6 +289,8 @@ In these issues, you can also see our friendly neighborhood [Support Bot](#suppo
 
 ### As an end user (issue creator)
 
+> Support for additional email headers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346600) in GitLab 14.6.
+> In earlier versions, the Service Desk email address had to be in the "To" field.
 To create a Service Desk issue, an end user does not need to know anything about
 the GitLab instance. They just send an email to the address they are given, and
 receive an email back confirming receipt:
@@ -304,6 +306,9 @@ are sent as emails:
 
 Any responses they send via email are displayed in the issue itself.
 
+For information about headers used for treating email, see
+[the incoming email documentation](../../administration/incoming_email.md#accepted-headers).
+
 ### As a responder to the issue
 
 For responders to the issue, everything works just like other GitLab issues.