When people talk about scaling GLPI, they usually mention MySQL, Redis, PHP-FPM, or server performance. But in practice, one of the first bottlenecks often turns out to be something else entirely—email.

GLPI actively uses email for almost every event in the system:

  • ticket creation;
  • assigning technicians;
  • adding a comment or solution (Follow-up);
  • status updates and approvals (Validation);
  • SLA alerts and automatic rules;
  • ticket closure notifications.

In a small company, this might translate to dozens of notifications per day. In a large enterprise deployment, it quickly scales to tens of thousands of emails monthly.

This is exactly the problem I faced several years ago.

My Mail Volume

In my GLPI setup, we register about 6,000–7,000 new tickets every month. However, this does not mean 6,000–7,000 emails. Each ticket generates at least five notifications over its lifecycle:

  • creation confirmation sent to the requester;
  • assignment notification sent to the technician and support group;
  • notifications sent to assigned observers;
  • resolution notification sent to the requester;
  • resolution notification sent to the observer.

And that is just the baseline scenario. If follow-ups are added, statuses change, files are attached, or escalation rules trigger, the email count increases several fold.

Consequently, GLPI easily generates tens of thousands of transactional emails every single month.

Why Standard SMTP Fails

Initially, most setups rely on a standard corporate mail server SMTP or a web hosting mail server. This works fine until you hit typical SMTP limitations:

  • strict hourly or daily sending limits;
  • poor IP address reputation due to bad neighbors on shared hosting;
  • temporary blocks from recipient mail services;
  • connection concurrency limits.

If GLPI serves as a critical corporate Service Desk, these limitations eventually manifest as delayed communications, affecting operations.

Why I Don't Use My Own SMTP

My infrastructure hosts a dedicated Mailcow server. So my choice isn't about being unable to run a mail server. On the contrary, managing Mailcow taught me that corporate communication and transactional email delivery are two entirely different workloads.

A self-hosted mail server is perfect for corporate correspondence. It provides absolute control, custom security policies, and independence from external services. But for large-scale automated alerts, different criteria matter:

  • highly consistent deliverability;
  • spotless IP address reputation;
  • automated bounce and complaint handling;
  • elastic scalability without stressing CPU/disk resources;
  • minimal maintenance overhead.

That is why I route GLPI transactional email through AWS Simple Email Service (SES).

Why AWS SES

I have used AWS SES for over three years. During this time, the service has delivered hundreds of thousands of messages. Over this entire period:

  • there have been zero deliverability issues to external domains;
  • the IP addresses were never blacklisted;
  • no configuration changes or mail queue cleanups were needed;
  • not a single incident required my manual intervention.

Once a month, I open the AWS Console, check the core metrics (Delivery Rate, Bounce Rate, Complaint Rate, Reject Rate), and close the tab. I have never had to manually inspect a jammed mail queue. For me, that is the ultimate metric of a good engineering solution.

Pricing

People often claim AWS is expensive. For SES, my experience is the opposite. With 6,000–7,000 new tickets monthly, the bill amounts to about $5–$6 USD per month. That is significantly cheaper than spending my own billable hours debugging mail server blacklists.

Production Access — The Sandbox Hurdle

By default, new Amazon SES accounts start in Sandbox mode. In this mode, you can only send emails to verified addresses, and sending limits are extremely low. Running production operations is impossible.

To exit the Sandbox, you must submit a production access request. AWS Support takes spam prevention very seriously and requests a detailed description of your use case. In my case, they wanted to know:

  • expected sending frequency and volume;
  • who the recipients are;
  • how recipient addresses are gathered and if opt-in is configured;
  • how bounce and complaint notifications are handled;
  • examples of typical emails sent.

I highly recommend providing comprehensive answers. Vague responses only prolong the review process.

What Helped Pass the Review

Here are a few tips based on my experience:

  • Clearly state that you are sending TRANSACTIONAL emails, not marketing campaigns or unsolicited bulk mail.
  • Explain that messages are triggered by a Service Desk system and only sent to registered employees or customers who actively interact with tickets.
  • Include an email sample. I recommend providing a plain text sample instead of complex HTML—it looks cleaner and raises fewer red flags for the reviewers.

Appendix: Production Access Request Sample

Below is a sample request that successfully passed AWS moderation. Make sure to adapt it to your specific infrastructure and use case:

Production access request
Service: SES Sending Limits
Region: eu-north-1

Please enable production access.

Use case:
Transactional email notifications generated by GLPI Service Desk.

Mail Type:
TRANSACTIONAL

Website:
https://example.com

Our service desk sends notifications to registered employees, contractors and customers based on ticket lifecycle events.

Typical events include:
- new ticket created;
- engineer assigned;
- observer assigned;
- ticket status changed;
- ticket resolved.

Recipient addresses belong only to users registered in our service desk according to existing contracts and internal processes.

We process bounce and complaint notifications and monitor Amazon SES reputation metrics.

Attached is a sample transactional message generated by our service desk.

Post-Production Setup

Once approved, AWS increases your limits. In my case, they granted 50,000 emails per day at a rate of 14 messages per second. This is more than enough for most GLPI instances.

You then receive SMTP Endpoint and SMTP Credentials, which you plug into GLPI's mail configuration. From GLPI's perspective, this is identical to connecting to any standard mail server.

Don't Skip Monitoring

After moving to production, configure these immediately:

  • AWS Budget: to monitor costs and trigger alerts if the budget threshold is crossed;
  • CloudWatch Alarms: to alert if Bounce Rate goes above 2-5% or Complaint Rate exceeds 0.1%.

This allows you to catch loops (e.g., ticket loop notifications caused by bad GLPI rules) long before AWS suspends your sending capabilities due to reputation drop.

DNS Records Matter

Before sending, configure SPF, DKIM, and DMARC records for your domain pointing to AWS SES. This is critical to ensure your notifications bypass spam folders in Gmail, Outlook, or corporate filters.

Conclusion

I don't view AWS SES as a silver bullet for everything. But for GLPI instances triggering tens of thousands of alerts, it became one of the lowest-maintenance components. A few hours of initial configuration, about $5–$6 per month, and over three years of stable operation without a single issue. It is a prime example of engineering that chooses a solution that is simple to run not just today, but years down the line.

In Conclusion

In this article, I deliberately focused only on the scenario of using AWS SES as an SMTP service for GLPI transactional messages.

In reality, the capabilities of Amazon SES are much broader. The service supports an API for sending mail, bounce and complaint processing via Amazon SNS, Configuration Sets, Virtual Deliverability Manager, inbound mail processing, suppression lists, dedicated IPs, and many other features for building scalable email solutions.

If you are already using AWS or planning to expand your own infrastructure, I recommend at least browsing the official documentation. Even if today you only need SMTP for GLPI, other features of the service may come in handy over time.

Useful Links