Custom Email Sender Configuration for GitLab.com SaaS Customers

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

## Problem to solve GitLab.com SaaS customers cannot currently configure custom email senders for notifications. When GitLab.com sends email notifications on behalf of the customer's domain (e.g., notifications@customerdomain.com), these emails are flagged as spoofed by enterprise security gateways like Symantec due to SPF/DMARC policy violations. This occurs because the emails originate from GitLab's Mailgun service (mg.gitlab.com) but appear to be from the customer's domain. This situation has created significant challenges for enterprise customers with strict email security policies, as they cannot: 1. Configure their own SMTP servers for GitLab.com notifications (this option exists only for self-managed) 2. Use their own email domains without triggering anti-spoofing alerts 3. Whitelist GitLab.com's IPs, as these IPs are shared across multiple customers and not dedicated

## Proposed solution Implement a feature that allows GitLab.com SaaS customers (especially Ultimate tier) to:

Option 1: Custom Email Sender Configuration**** - Allow customers to configure a custom "From" address that doesn't trigger anti-spoofing alerts - Enable configuration of a custom "Reply-To" address that maintains the workflow while respecting security policies - Provide the ability to send as no-reply@gitlab.com (or similar) while maintaining customer context in the email body - Add ability to customize email templates for SaaS customers

## Business value This feature would:

  1. Improve GitLab.com adoption among security-conscious enterprise customers
  2. Reduce support cases related to email delivery issues on GitLab.com
  3. Increase customer satisfaction by allowing them to maintain their security posture while using SaaS
  4. Enhance GitLab's competitiveness against other DevOps SaaS platforms that offer this capability
  5. Potentially increase conversion rates for Premium/Ultimate subscriptions
  6. Reduce pressure to move to self-managed installations solely for email configuration flexibility

## User experience When a GitLab.com customer encounters email spoofing alerts, they should be able to:

  1. Navigate to their organization settings in GitLab.com
  2. Access a new "Email Configuration" section (available to administrators)
  3. Select an option to use GitLab-branded email addresses instead of customer domain addresses
  4. Configure custom Reply-To addresses to maintain workflow functionality

## Technical implementation considerations - Integration with existing GitLab.com email delivery infrastructure (Mailgun) - Proper handling of Reply-To headers for maintaining workflows - Domain configuration and validation - Clear documentation on how to configure security gateways for GitLab.com emails - Resource allocation for dedicated IP addresses for SaaS customers - Managing IP reputation for dedicated sending IPs

Edited by 🤖 GitLab Bot 🤖