Reply by email

{{< details >}}

• Tier: Free, Premium, Ultimate
• Offering: GitLab Self-Managed

{{< /details >}}

GitLab can be set up to allow users to comment on issues and merge requests by replying to notification emails.

Prerequisite

Make sure incoming email is set up.

How replying by email works

Replying by email happens in three steps:

1. GitLab sends a notification email.
2. You reply to the notification email.
3. GitLab receives your reply to the notification email.

GitLab sends a notification email

When GitLab sends a notification email:

• The Reply-To header is set to your configured email address.
• If the address contains a %{key} placeholder, it's replaced with a specific reply key.
• The reply key is added to the References header.

You reply to the notification email

When you reply to the notification email, your email client:

• Sends the email to the Reply-To address it got from the notification email.
• Sets the In-Reply-To header to the value of the Message-ID header from the notification email.
• Sets the References header to the value of the Message-ID plus the value of the notification email's References header.

GitLab receives your reply to the notification email

When GitLab receives your reply, it looks for the reply key in the list of accepted headers.

If a reply key is found, your response appears as a comment on the relevant issue, merge request, commit, or other item that triggered the notification.

For more information about the Message-ID, In-Reply-To, and References headers, see RFC 5322.

Retention policy for notifications

Some incoming email features require GitLab to store metadata about sent email notifications. We retain these records for two years. If an email notification is older than two years, you cannot reply by email to that notification. This includes replying by email to issue and merge request threads.