This guide explains how to deploy Messages in production, focusing on Messages-specific configuration and architecture.
Messages is designed to be self-hosted. See Architecture for component details.
- Domain name(s) for your email service
- SSL certificates for your domains
- Server resources: Minimum 4GB RAM
Messages supports multiple deployment strategies depending on your infrastructure and expertise level:
Best for: Small to medium deployments, single-server setups, quick prototyping
Requirements:
- Docker and Docker Compose installed
- Single server or VM with sufficient resources
- Basic Docker knowledge
Process:
- Start from the
compose.yamlin the repository - Create production environment files (
env.d/production/*.defaults) - Deploy to any environment where Docker Compose runs
- Configure DNS and SSL certificates
Advantages:
- Simplest setup and maintenance
- Easy to understand and modify
- Quick deployment and updates
- Good for development and testing
Best for: Multi-server deployments, infrastructure automation, production environments
Requirements:
- Ansible knowledge
- Target servers with Docker support
- Infrastructure automation experience
Process:
- Use our ST Ansible repository as a base
- Customize playbooks for your infrastructure
- Deploy across multiple servers with automation
- Configure monitoring and backup strategies
Advantages:
- Infrastructure as code
- Automated deployment and updates
- Multi-server support
- Production-ready with monitoring
Best for: Large-scale deployments, cloud-native environments, enterprise setups
Requirements:
- Kubernetes cluster
- Helm knowledge (when charts become available)
- Container orchestration experience
Process:
- Wait for Helm charts (coming in future releases)
- Deploy to Kubernetes cluster
- Configure ingress controllers and load balancers
- Set up monitoring with Prometheus/Grafana
Advantages:
- High availability and scalability
- Advanced orchestration features
- Cloud-native deployment patterns
- Enterprise-grade monitoring and logging
Note: Kubernetes deployment might be supported in future releases with official Helm charts.
Messages uses a technical domain concept for DNS infrastructure:
# Set your technical domain
MESSAGES_TECHNICAL_DOMAIN=mail.yourdomain.comTechnical Domain DNS Records:
mx1.mail.yourdomain.com. A YOUR_SERVER_IP
mx2.mail.yourdomain.com. A YOUR_SERVER_IP
_spf.mail.yourdomain.com. TXT "v=spf1 ip4:YOUR_SERVER_IP -all"
Customer Domain DNS Records:
@ MX 10 mx1.customer-domain.com.
@ MX 20 mx2.customer-domain.com.
@ TXT "v=spf1 include:_spf.mail.yourdomain.com -all"
_dmarc TXT "v=DMARC1; p=reject; adkim=s; aspf=s;"
The DNS records for each customer domains are available either via API at http://localhost:8901/api/v1.0/maildomains/{maildomain-uuid}/ or in the admin interface at http://localhost:8900/domain
Messages uses environment variables as the primary configuration method:
Environment File Structure:
env.d/production/backend.defaults- Main Django application settingsenv.d/production/frontend.defaults- Frontend configurationenv.d/production/mta-in.defaults- Inbound mail server settingsenv.d/production/mta-out.defaults- Outbound mail server settingsenv.d/production/postgresql.defaults- Database configurationenv.d/production/keycloak.defaults- Identity provider settings
For detailed environment variable documentation, see Environment Variables.
- Configured via
env.d/production/mta-in.defaults - Uses custom milter for synchronous delivery during SMTP sessions
- Validates recipients via REST API before accepting messages
- Configured via
env.d/production/mta-out.defaults - Supports relay configuration for external SMTP providers
- Requires TLS certificates for production
Messages includes automated DNS management:
# Check DNS records for a customer domain
python manage.py dns_check --domain example.com
# Provision DNS records automatically
python manage.py dns_provision --domain example.com --provider scaleway
# Simulate provisioning without making changes
python manage.py dns_provision --domain example.com --pretendSupported DNS Providers:
- Scaleway DNS (full automation support)
# Via Django admin at /admin/
# Via API endpoints
# Via management commands
python manage.py shell
>>> from core.models import MailDomain
>>> MailDomain.objects.create(name='customer-domain.com')- Manual creation through admin interface
- Automatic creation via OIDC integration
- Programmatic creation via API
Messages uses OpenID Connect (OIDC) for user authentication. This is the only authentication method supported.
OIDC Configuration Options:
-
Bundled Keycloak (Recommended for most deployments)
- Keycloak is included in the default Docker Compose setup
- Pre-configured with Messages realm and users
- Suitable for organizations wanting a self-hosted identity provider
- Configure via
env.d/production/keycloak.defaults
-
External OIDC Provider
- Use any OIDC-compliant identity provider
- Examples: Auth0, Okta, Azure AD, Google Workspace
- Configure via
env.d/production/backend.defaults - Requires proper OIDC endpoint configuration
User Management:
- Users are created automatically when they first log in via OIDC
- Mailboxes can be created automatically based on OIDC email addresses
For production deployment, create your own Docker Compose configuration based on compose.yaml:
Key Considerations:
- Use production environment files (
env.d/production/*.defaults) - Configure SSL/TLS certificates
- Set up persistent volumes for databases
- Implement proper restart policies
- Configure reverse proxy (Caddy) for SSL termination
- MDA API Secret: Use strong, unique
MDA_API_SECRET - OIDC Configuration: Properly configure Keycloak endpoints
- Technical Domain: Secure DNS records for your technical domain
- Environment Files: Never commit production secrets
Monitoring:
- Check your server's IP reputation at MXToolbox
- Monitor key blacklists: Spamhaus, Barracuda, SORBS
Recovery from Blacklisting:
- Stop all outgoing email immediately
- Check server logs for abuse indicators
- Follow blacklist's delisting procedure
- Implement stricter authentication and rate limiting
-
MTA-in not receiving emails
- Check firewall settings for port 25
- Verify DNS MX records point to your technical domain
- Check MTA-in logs for API connection issues
-
MTA-out not sending emails
- Verify SMTP credentials in environment files
- Check relay host configuration
- Review MTA-out logs for authentication errors
-
DNS issues
- Use
dns_checkcommand to verify records - Ensure technical domain A records are correct
- Check DNS propagation with
dig
- Use
-
Authentication problems
- Verify Keycloak configuration in environment files
- Check OIDC endpoint URLs
- Review backend logs for authentication errors
After setting up your production environment:
- Test thoroughly with a small group of users
- Monitor performance and adjust resources as needed
- Set up automated backups and monitoring
- Plan for scaling as your user base grows
For additional help, join the Matrix community!